From laura.liess.dt@googlemail.com Wed Aug 1 05:38: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 EA91911E8202 for ; Wed, 1 Aug 2012 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq3QGsoumtEy for ; Wed, 1 Aug 2012 05:38:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4311E8229 for ; Wed, 1 Aug 2012 05:38:07 -0700 (PDT) Received: by yhq56 with SMTP id 56so7800461yhq.31 for ; Wed, 01 Aug 2012 05:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yw8R8O4BQdkMqKmc3tJuZX2NLKU8KENH9QXubaEJZQM=; b=rRrYJbktz+bUUGdCuDDV1v6KkaJao9WWIJixUwr5HCmDeRL/OkpjuabnHfjmZVZ8hA zXviTPkxubL2YjtRa4mmPHnbNaJhVZ4m6PUJ3R9+htRchgfe9BKAk1fI6DzKuS4VC+oG SFMad/BOSl+7YU2QZzWvFYVrhT3xMzlBZxfXv+UToxXCwPeHHoprExw+8fgWoz7W7dDt qq2qjN4EcDJmIh3ZPfzPYVBzHHcrT3zqNC/Ie37rW7suRVPWY3d5gUDbhj+giuJdCR/U DUPxlNyp5GMTMQUqHOZfANBN5k+iOrIVNmCy65pRDDxbrmrmN4XIqJUz17NWimhLPbfx DTMA== MIME-Version: 1.0 Received: by 10.50.106.166 with SMTP id gv6mr5181774igb.46.1343824686933; Wed, 01 Aug 2012 05:38:06 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Wed, 1 Aug 2012 05:38:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2012 14:38:06 +0200 Message-ID: From: Laura Liess To: Marc Linsner Content-Type: text/plain; charset=ISO-8859-1 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Rough location vs. HELD extension for Germany and ETSI 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, 01 Aug 2012 12:38:09 -0000 Hi Mark, > I was thinking about the case where a UA from another country, like the > USA, roams into Germany and uses a VSP that is not part of the German > domain of VSPs? (not part of the German domain of VSPs = doesn't > understand the unique German procedure(s)) This is exactly the reason why we brought up this proposal, as a trial to achieve worldwide interoperability. But there is no regulatory requirement for worldwide emergency calls, it's just "nice to have". We have two alternatives for what happens in your use case, depending on how Ecrit deals with the new proposal: 1) The architecture proposal is accepted in ecrit as an alternative. HELD is extended to return the ESRP URI and the phonepcb is extended, too. So, the US VSPs support these architecture and HELD extenssion and the emergency calling would work for them in Germany/EU . 2) The architecture proposal and HELD extenssion are rejected in ecrit, they are valid just for Germany/ EU. In this case any VSP which have an SLA with a German VoIP carrier will have to support the German architecture and HELD extenssion per regulatory requirements. If the VSP does not support the German/EU procedure, the emergency calling will not work. As I said, nobody cares about it. Note: DT already submitted the proposal to TISPAN . We think some other EU carriers which have the same problem in their country, our and their SIP vendors and the German regulator will support this proposal. Maybe other countries without dedicated emergency calling infrastruchture and budget as US will follow this model because it minimizes the costs and implementation time. Thanks a lot Laura > > Thanks, > > -Marc- > > From brian.rosen@neustar.biz Thu Aug 9 08:42:33 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 7073121F87A4 for ; Thu, 9 Aug 2012 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.465 X-Spam-Level: X-Spam-Status: No, score=-5.465 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvtaxLA5KsoW for ; Thu, 9 Aug 2012 08:42:33 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id C02D421F8796 for ; Thu, 9 Aug 2012 08:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344526700; x=1659883027; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=+233u9UeNzrUST0+tQLh/ KQNafFtr2pHhT284QHyOH0=; b=MUldRao6vbU9bWhaNN6oPJjbeJeZ+Q82WZdAG YzPnCH15p9t8K1/4AmUul7OLnmZYqOllZ5ZcvVoE5jhK7NW2Q== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9688388; Thu, 09 Aug 2012 11:38:19 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 11:42:18 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Thu, 9 Aug 2012 11:42:18 -0400 Thread-Topic: comment field in additional-data Thread-Index: Ac12RY7C0IO6KNLlRLO+EhT1P4XGLw== Message-ID: 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: EVWI+L5BXxCXd/JimDtrRw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] comment field in additional-data 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, 09 Aug 2012 15:42:33 -0000 Would there be any objection to adding a field in the service provider info= block for a comment? I'm asking because we found a backwards compatibility issue in NENA, but I = think it's generally useful. There are always a couple of things it may be= helpful to tell the call taker (human). I'd put cautionary text in that s= uggests using an extension mechanism to pass actual data intended to be con= sumed by an automaton. This is just for free text to be displayed to a cal= l taker or other PSAP staff. From mserra@ravemobilesafety.com Thu Aug 9 14:28: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 210E021F86D7 for ; Thu, 9 Aug 2012 14:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9huS0u4btc+A for ; Thu, 9 Aug 2012 14:28:43 -0700 (PDT) Received: from server505.appriver.com (server505f.appriver.com [98.129.35.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9C52021F860F for ; Thu, 9 Aug 2012 14:28:43 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/9/2012 4:28:42 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G279 G280 G281 G282 G286 G287 G298 G389 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 309553915; Thu, 09 Aug 2012 16:28:41 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.137]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Thu, 9 Aug 2012 16:28:38 -0500 From: Matt Serra To: "Rosen, Brian" , "ecrit@ietf.org Org" Date: Thu, 9 Aug 2012 16:28:19 -0500 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac12YU/84raR9pH0QYOFGcKesiAmewAFCuaQ Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] comment field in additional-data 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, 09 Aug 2012 21:28:44 -0000 Brian -=20 No objection, but a question: We mentioned possibly putting this field into the PIDF instead. Did we arr= ive on putting this into the Add'l Call Data to keep the PIDF "clean" assum= ing it has no alternate use outside of 9-1-1? I suspect the driver is also based on whether the "Comment" is related to t= he address, or the provider/service as well. Thanks. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, August 09, 2012 11:42 AM To: ecrit@ietf.org Org Subject: [Ecrit] comment field in additional-data Would there be any objection to adding a field in the service provider info= block for a comment? I'm asking because we found a backwards compatibility issue in NENA, but I = think it's generally useful. There are always a couple of things it may be= helpful to tell the call taker (human). I'd put cautionary text in that s= uggests using an extension mechanism to pass actual data intended to be con= sumed by an automaton. This is just for free text to be displayed to a cal= l taker or other PSAP staff. From brian.rosen@neustar.biz Thu Aug 9 15:30:50 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 D6CA721F8609 for ; Thu, 9 Aug 2012 15:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KypvgTPrkTUv for ; Thu, 9 Aug 2012 15:30:50 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD621F8602 for ; Thu, 9 Aug 2012 15:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344551208; x=1659909986; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=qDCoJ3l+4jdIZbOxmyhm5 X0+3GrmCalEl36OQ3N8FaQ=; b=sJT0QIiaZEGiRjlEaWS6ZXbNOMsG7bMV8zxue +sMgnEfGKnWAVz3uq5jnaPkfRX+rlfkHCYdDthPTzbCwZxNfA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9700986; Thu, 09 Aug 2012 18:26:47 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 9 Aug 2012 18:30:46 -0400 From: "Rosen, Brian" To: Matt Serra Date: Thu, 9 Aug 2012 18:30:47 -0400 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac12fp6vgLed+3iHTEyscuLYP3c/BQ== Message-ID: References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> 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: 057oSJihJHT1Wx+8tsRSKA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] comment field in additional-data 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, 09 Aug 2012 22:30:51 -0000 Well, I think we want entities other than an access network to be able to u= se a comment, so the latter of your two answers is what I would say. If there is a comment in additional-data, I don't think we need another in = PIDF. Brian On Aug 9, 2012, at 5:28 PM, Matt Serra wrote: > Brian -=20 >=20 > No objection, but a question: >=20 > We mentioned possibly putting this field into the PIDF instead. Did we a= rrive on putting this into the Add'l Call Data to keep the PIDF "clean" ass= uming it has no alternate use outside of 9-1-1? >=20 > I suspect the driver is also based on whether the "Comment" is related to= the address, or the provider/service as well. >=20 > Thanks. >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Thursday, August 09, 2012 11:42 AM > To: ecrit@ietf.org Org > Subject: [Ecrit] comment field in additional-data >=20 > Would there be any objection to adding a field in the service provider in= fo block for a comment? > I'm asking because we found a backwards compatibility issue in NENA, but = I think it's generally useful. There are always a couple of things it may = be helpful to tell the call taker (human). I'd put cautionary text in that= suggests using an extension mechanism to pass actual data intended to be c= onsumed by an automaton. This is just for free text to be displayed to a c= all taker or other PSAP staff. >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Tue Aug 14 13:15:06 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 A151E21E8088 for ; Tue, 14 Aug 2012 13:15:06 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuA6l+rhkMAI for ; Tue, 14 Aug 2012 13:15:05 -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 6F5DF21F8702 for ; Tue, 14 Aug 2012 13:15:05 -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 q7EKEwWR003000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 14 Aug 2012 13:14:58 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.203]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 14 Aug 2012 13:14:58 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16WXl1aY8h8dRuRCSVyR9kOOlARw== Date: Tue, 14 Aug 2012 20:14:57 +0000 Message-ID: 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_FBD5AAFFD0978846BF6D3FAB4C892ACC0EB22CSEAEXMB2telecomsy_" MIME-Version: 1.0 Cc: "marc.linsner@cisco.com" Subject: [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, 14 Aug 2012 20:15:06 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC0EB22CSEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As an outcome of the Vancouver ECRIT meeting for the -psap-callback draft, = the group discussed the use of the Privacy header field value as something = that was meant to indicate a PSAP callback. Now we need to verify what the decisions were concerning that value, and it= s use - on the list: Resolve to use "emergency" as the Private header value, since any new (othe= r) value doesn't offer a real advantage. Does anyone disagree as to wg acceptance of this approach in the meeting? We need to move this draft forward for use in 3GPP. Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-04 Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ecrit -roger marshall. 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_FBD5AAFFD0978846BF6D3FAB4C892ACC0EB22CSEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As an outcome of the Vancouver ECRIT meeting for the= –psap-callback draft, the group discussed the use of the Privacy hea= der field value as something that was meant to indicate a PSAP callback.&nb= sp;

 

Now we need to verify what the decisions were concer= ning that value, and its use - on the list:

 

Resolve to use “emergency” as the Privat= e header value, since any new (other) value doesn’t offer a real adva= ntage.

 

Does anyone disagree as to wg acceptance of this app= roach in the meeting?

 

We need to move this draft forward for use in 3GPP.<= o:p>

 

Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-04=

Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ecrit<= /p>

 

 

-roger marshall.

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_FBD5AAFFD0978846BF6D3FAB4C892ACC0EB22CSEAEXMB2telecomsy_-- From pkyzivat@alum.mit.edu Tue Aug 14 13:31:18 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 7924B21F870F for ; Tue, 14 Aug 2012 13:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhr+QoHB1mA4 for ; Tue, 14 Aug 2012 13:31:18 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id B633321F8711 for ; Tue, 14 Aug 2012 13:31:17 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id mjPj1j0030cZkys5BkXLk5; Tue, 14 Aug 2012 20:31:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id mkXK1j0073ZTu2S3WkXKij; Tue, 14 Aug 2012 20:31:19 +0000 Message-ID: <502AB594.8000800@alum.mit.edu> Date: Tue, 14 Aug 2012 16:31:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 14 Aug 2012 20:31:18 -0000 I prefer using "emergency", and would be ok with using some new value. There was some concern expressed at the meeting that "emergency" might already be in use for some other, incompatible, situation. I'm inclined to think that unlikely, but it may be hard to determine. If I understood the discussion, it was that for emergency callback the presence of the indication should allow to call to complete even in the presence of call barring (e.g. service suspended for non-payment). And there was then desire to limit who could use the indicator. Presumably the SP could filter out "Priority:emergency" except when received from a PSAP. But that would mean that other uses of "Priority:emergency" might break. Perhaps the first question in this regard is whether those that would be doing this sort of filtering *currently* allow Priority:emergency or if they *already* filter it. (E.g. via an SBC.) For those that don't have the problem with call barring, I think this new usage and any existing usage could coexist. So this might just be a question for IMS implementers to investigate. Thanks, Paul On 8/14/12 4:14 PM, Roger Marshall wrote: > As an outcome of the Vancouver ECRIT meeting for the –psap-callback > draft, the group discussed the use of the Privacy header field value as > something that was meant to indicate a PSAP callback. > > Now we need to verify what the decisions were concerning that value, and > its use - on the list: > > Resolve to use “emergency” as the Private header value, since any new > (other) value doesn’t offer a real advantage. > > Does anyone disagree as to wg acceptance of this approach in the meeting? > > We need to move this draft forward for use in 3GPP. > > Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-04 > > Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ecrit > > -roger marshall. > > 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 christer.holmberg@ericsson.com Tue Aug 14 13:51:17 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 8D74121E80A4 for ; Tue, 14 Aug 2012 13:51:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EVizPJyad7o for ; Tue, 14 Aug 2012 13:51:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6174221E809D for ; Tue, 14 Aug 2012 13:51:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f236d000005cde-2c-502aba40a3d0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FA.B7.23774.04ABA205; Tue, 14 Aug 2012 22:51:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 14 Aug 2012 22:51:11 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Date: Tue, 14 Aug 2012 22:50:38 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16W8RVxdGmDeQURYWboLVODnX20QAArFoi Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> References: , <502AB594.8000800@alum.mit.edu> In-Reply-To: <502AB594.8000800@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-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra7DLq0Agy+TlSwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxoeMxc0GbZMXT1dfZGhiPiHQxcnJICJhI 3PvXxAhhi0lcuLeerYuRi0NI4BSjxM8VD6CcBYwSn07OBKri4GATsJDo/qcN0iAi4C3x5/c3 NhCbRUBVYknPBjBbWMBV4v7SqewQNW4Szx+eYoGwjSTWPlkIVsMrEC6x4swrZhBbSCBPYs3n bWA1nAI6EjsPTmEFsRmBDvp+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8/A+qXlTiTvt6 Roh6A4n35+YzQ9jaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkv N9JLLcpMLi7Oz9MrTt3ECIyRg1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoY2ezbrsgJrrKrn6KvM22FyJ2JfG8erjjdKnmwUzKYSXCe5rPEOcnrbley dzRGnP7yaeJXCeswd3unwnRepTajmJWqffcvR0hLz3/dH63ExPHHmSG/o+Wax5MvS4S2yimV aFR8n3FW4oa8G198SP5/oYS1gV8P202T3sQ3WWHl9fqu204cp+uUWIozEg21mIuKEwFf8UtC XwIAAA== 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, 14 Aug 2012 20:51:17 -0000 Hi, So, if there is potential problem with "emergency", why not define a new va= lue? As far as I remember, nobody objected to that. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@alum.mit.edu] Sent: Tuesday, August 14, 2012 11:31 PM To: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator I prefer using "emergency", and would be ok with using some new value. There was some concern expressed at the meeting that "emergency" might already be in use for some other, incompatible, situation. I'm inclined to think that unlikely, but it may be hard to determine. If I understood the discussion, it was that for emergency callback the presence of the indication should allow to call to complete even in the presence of call barring (e.g. service suspended for non-payment). And there was then desire to limit who could use the indicator. Presumably the SP could filter out "Priority:emergency" except when received from a PSAP. But that would mean that other uses of "Priority:emergency" might break. Perhaps the first question in this regard is whether those that would be doing this sort of filtering *currently* allow Priority:emergency or if they *already* filter it. (E.g. via an SBC.) For those that don't have the problem with call barring, I think this new usage and any existing usage could coexist. So this might just be a question for IMS implementers to investigate. Thanks, Paul On 8/14/12 4:14 PM, Roger Marshall wrote: > As an outcome of the Vancouver ECRIT meeting for the =96psap-callback > draft, the group discussed the use of the Privacy header field value as > something that was meant to indicate a PSAP callback. > > Now we need to verify what the decisions were concerning that value, and > its use - on the list: > > Resolve to use =93emergency=94 as the Private header value, since any new > (other) value doesn=92t offer a real advantage. > > Does anyone disagree as to wg acceptance of this approach in the meeting? > > We need to move this draft forward for use in 3GPP. > > Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-= 04 > > Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ec= rit > > -roger marshall. > > 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 pkyzivat@alum.mit.edu Tue Aug 14 14:20: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 4B1EB21F8672 for ; Tue, 14 Aug 2012 14:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttAv7ifMLJos for ; Tue, 14 Aug 2012 14:20:00 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8121F8683 for ; Tue, 14 Aug 2012 14:19:59 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id mbhC1j00816LCl055lL23h; Tue, 14 Aug 2012 21:20:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id mlKm1j00C3ZTu2S3SlKmZC; Tue, 14 Aug 2012 21:19:46 +0000 Message-ID: <502AC0FE.8040707@alum.mit.edu> Date: Tue, 14 Aug 2012 17:19:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: , <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 14 Aug 2012 21:20:01 -0000 On 8/14/12 4:50 PM, Christer Holmberg wrote: > Hi, > > So, if there is potential problem with "emergency", why not define a new value? As far as I remember, nobody objected to that. As I said, I'm *ok* with a new value. But it offends me to have to add a new value when we already have a value "emergency" and this *is* an emergency. It sets a precedent that nobody can use predefined values that weren't assigned for their own specific case. Its another example of a philosophy that we need to signal features or use cases rather than simply assemble basic primitives to accomplish features. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, August 14, 2012 11:31 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > I prefer using "emergency", and would be ok with using some new value. > > There was some concern expressed at the meeting that "emergency" might > already be in use for some other, incompatible, situation. I'm inclined > to think that unlikely, but it may be hard to determine. > > If I understood the discussion, it was that for emergency callback the > presence of the indication should allow to call to complete even in the > presence of call barring (e.g. service suspended for non-payment). And > there was then desire to limit who could use the indicator. Presumably > the SP could filter out "Priority:emergency" except when received from a > PSAP. But that would mean that other uses of "Priority:emergency" might > break. > > Perhaps the first question in this regard is whether those that would be > doing this sort of filtering *currently* allow Priority:emergency or if > they *already* filter it. (E.g. via an SBC.) > > For those that don't have the problem with call barring, I think this > new usage and any existing usage could coexist. So this might just be a > question for IMS implementers to investigate. > > Thanks, > Paul > > On 8/14/12 4:14 PM, Roger Marshall wrote: >> As an outcome of the Vancouver ECRIT meeting for the –psap-callback >> draft, the group discussed the use of the Privacy header field value as >> something that was meant to indicate a PSAP callback. >> >> Now we need to verify what the decisions were concerning that value, and >> its use - on the list: >> >> Resolve to use “emergency” as the Private header value, since any new >> (other) value doesn’t offer a real advantage. >> >> Does anyone disagree as to wg acceptance of this approach in the meeting? >> >> We need to move this draft forward for use in 3GPP. >> >> Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-04 >> >> Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ecrit >> >> -roger marshall. >> >> 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 keith.drage@alcatel-lucent.com Wed Aug 15 06:13:39 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 6E73C21F8834 for ; Wed, 15 Aug 2012 06:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.783 X-Spam-Level: X-Spam-Status: No, score=-109.783 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQajnV-fFf6f for ; Wed, 15 Aug 2012 06:13:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 534A721F8829 for ; Wed, 15 Aug 2012 06:13:38 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7FDDYVG010497 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Aug 2012 15:13:34 +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, 15 Aug 2012 15:13:34 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Paul Kyzivat , "ecrit@ietf.org" Date: Wed, 15 Aug 2012 15:13:32 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16W8RVxdGmDeQURYWboLVODnX20QAArFoiACI++BA= Message-ID: References: , <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 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, 15 Aug 2012 13:13:39 -0000 I would prefer a new value. This is essentially a new defined usage, and it is unlikely that current us= e is being made of any existing codepoints for this usage. Given that, I see no need to try and investigate whether we can reuse an ex= isting codepoint, which may well be used for all sorts of other purposes. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 14 August 2012 21:51 > To: Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > Hi, >=20 > So, if there is potential problem with "emergency", why not define a new > value? As far as I remember, nobody objected to that. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Paul > Kyzivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, August 14, 2012 11:31 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > I prefer using "emergency", and would be ok with using some new value. >=20 > There was some concern expressed at the meeting that "emergency" might > already be in use for some other, incompatible, situation. I'm inclined > to think that unlikely, but it may be hard to determine. >=20 > If I understood the discussion, it was that for emergency callback the > presence of the indication should allow to call to complete even in the > presence of call barring (e.g. service suspended for non-payment). And > there was then desire to limit who could use the indicator. Presumably > the SP could filter out "Priority:emergency" except when received from a > PSAP. But that would mean that other uses of "Priority:emergency" might > break. >=20 > Perhaps the first question in this regard is whether those that would be > doing this sort of filtering *currently* allow Priority:emergency or if > they *already* filter it. (E.g. via an SBC.) >=20 > For those that don't have the problem with call barring, I think this > new usage and any existing usage could coexist. So this might just be a > question for IMS implementers to investigate. >=20 > Thanks, > Paul >=20 > On 8/14/12 4:14 PM, Roger Marshall wrote: > > As an outcome of the Vancouver ECRIT meeting for the -psap-callback > > draft, the group discussed the use of the Privacy header field value as > > something that was meant to indicate a PSAP callback. > > > > Now we need to verify what the decisions were concerning that value, an= d > > its use - on the list: > > > > Resolve to use "emergency" as the Private header value, since any new > > (other) value doesn't offer a real advantage. > > > > Does anyone disagree as to wg acceptance of this approach in the > meeting? > > > > We need to move this draft forward for use in 3GPP. > > > > Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap- > callback-04 > > > > Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84- > ecrit > > > > -roger marshall. > > > > 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Wed Aug 15 09:36: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 1FCD621F85A8 for ; Wed, 15 Aug 2012 09:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.979 X-Spam-Level: X-Spam-Status: No, score=-3.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWEABrCqDBSd for ; Wed, 15 Aug 2012 09:36:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2B3221F8595 for ; Wed, 15 Aug 2012 09:36:12 -0700 (PDT) Received: by lahm15 with SMTP id m15so979869lah.31 for ; Wed, 15 Aug 2012 09:36: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=QPOduXQ9Nn+9ug9Yc25Qkcud8wnsFq0ctfIVO6dLfIc=; b=M1UT1hxkm+YdFrUSXXYkRSV23wsWHQT42hileJ0tz7tO5UCTu+VWOvOHvVCZHbHAx/ Tqpp7TaGeSEljc2ucx+iUa9v21rJvCg4q4uYG2M2WPa9yDqd498srXj5ZdIej7jpLCsG c4oI2xmK6IzIuFqbYzXadyNnDsIRs0gF9vnXLSYltOT2nFA+ovWoyknUyjNBF6oOTOx4 ay5AvQ/HQDRLdMS0yc0T8Hs6TQgwyFFQ6oY4DcJ7slAg7ge4MsLh18/0uT7KEcG+vNYt oVElen5EJ3Cm64IehY/xWJKwTKF3T/FS37xekD+tXC4BOBpqBMHPpoon97ofrgP2CKwV 8geQ== MIME-Version: 1.0 Received: by 10.112.17.195 with SMTP id q3mr10054107lbd.34.1345048571778; Wed, 15 Aug 2012 09:36:11 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Wed, 15 Aug 2012 09:36:11 -0700 (PDT) In-Reply-To: <502AC0FE.8040707@alum.mit.edu> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu> Date: Wed, 15 Aug 2012 09:36:11 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 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, 15 Aug 2012 16:36:14 -0000 On 14 August 2012 14:19, Paul Kyzivat wrote: > As I said, I'm *ok* with a new value. > But it offends me to have to add a new value when we already have a value > "emergency" and this *is* an emergency. It sets a precedent that nobody can > use predefined values that weren't assigned for their own specific case. Its > another example of a philosophy that we need to signal features or use cases > rather than simply assemble basic primitives to accomplish features. I'm with Paul on this one. These are just labels that have essentially arbitrary or context-specific semantics. This looks very much like a case where context is everything. "emergency" is the right word. The only concern is that it might have some other meaning. But those uses are specifically in some other context. This is a new context (probably based on identification of the PSAP, but that's simply an example). If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that. From christer.holmberg@ericsson.com Thu Aug 16 02:31:18 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 A370C21F8525 for ; Thu, 16 Aug 2012 02:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 JsyscsuNzEVu for ; Thu, 16 Aug 2012 02:31:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A478721F8608 for ; Thu, 16 Aug 2012 02:31:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-27-502cbde466c5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 72.95.01197.4EDBC205; Thu, 16 Aug 2012 11:31:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 16 Aug 2012 11:31:15 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Date: Thu, 16 Aug 2012 11:28:25 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac17BBS+NHeoRFy4TqSswuDBBk/FeQAjWfhb Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6TvToBBn1z9CwaFz1ltbh25h+j xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcz/d5G9oJm3ounLDOYG xt1cXYycHBICJhKPZ85jgbDFJC7cW8/WxcjFISRwilFi2/K3UM4CRolVk3azdjFycLAJWEh0 /9MGaRARCJVou7iPEcRmFlCVONf4mAWkhAXIvrRKCiQsLOAqcX/pVHaIcjeJ5w9PsUDYRhK7 T28Ga+UVCJdYunsC1KqlTBLLn+0AK+IUCJT42NfCBGIzAh33/dQaJohd4hK3nsxngjhaQGLJ nvPMELaoxMvH/1gh6kUl7rSvh7pNR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo9gsJGNnIWmZ haRlFpKWBYwsqxiFcxMzc9LLDfVSizKTi4vz8/SKUzcxAuPp4JbfujsYT50TOcQozcGiJM7L lbTfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjjDcb39dHzfrBq/xvu8j1cLvrDvPy0o8a bisyqUlonjz9zMlveysX/fn8/vAxzVuCHO2+x95P+5VyLCZMuoVx5dNvS5I59+x8phxQHJ2b 8Tz2aLWIyT7+9vf7Jtt7u624tHHpkoffNRUzX8cWWemJ3d9vWPzxv7nm+bT/ZV8lnQRavrhv mbZXQYmlOCPRUIu5qDgRAHN4MpJ1AgAA 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: Thu, 16 Aug 2012 09:31:18 -0000 Hi, It is true that some entity in the network needs to verify the context, and= that the call comes from a PSAP. But, once that is done, other entities wi= thin the same network (trust domain) do not need to do that.=20 So, for that reason I think a new value would be good. Regards, Christer ________________________________________ From: Martin Thomson [martin.thomson@gmail.com] Sent: Wednesday, August 15, 2012 7:36 PM To: Paul Kyzivat Cc: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator On 14 August 2012 14:19, Paul Kyzivat wrote: > As I said, I'm *ok* with a new value. > But it offends me to have to add a new value when we already have a value > "emergency" and this *is* an emergency. It sets a precedent that nobody c= an > use predefined values that weren't assigned for their own specific case. = Its > another example of a philosophy that we need to signal features or use ca= ses > rather than simply assemble basic primitives to accomplish features. I'm with Paul on this one. These are just labels that have essentially arbitrary or context-specific semantics. This looks very much like a case where context is everything. "emergency" is the right word. The only concern is that it might have some other meaning. But those uses are specifically in some other context. This is a new context (probably based on identification of the PSAP, but that's simply an example). If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that.= From prvs=3575fc1088=jbakker@rim.com Thu Aug 16 08:22: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 D1EF721F84F3 for ; Thu, 16 Aug 2012 08:22:51 -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 TTAiqZTrFlVf for ; Thu, 16 Aug 2012 08:22:51 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C18221F8494 for ; Thu, 16 Aug 2012 08:22:51 -0700 (PDT) X-AuditID: 0a41282f-b7f036d000004990-e2-502d1046b443 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 29.98.18832.6401D205; Thu, 16 Aug 2012 10:22:46 -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; Thu, 16 Aug 2012 10:22:45 -0500 From: John-Luc Bakker To: "ecrit@ietf.org" Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16WXl1aY8h8dRuRCSVyR9kOOlARwALDA8AAACtJwAAAQZDAAAoYWKAACNaEoAAAWu7QA== Date: Thu, 16 Aug 2012 15:22:45 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683686@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.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsXC5Zyvq+smoBtgcP4Yt0XjoqesDoweS5b8 ZApgjGpgtElKLCkLzkzP07ezSczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ugmdPBm7301mK7gtWrFj43KWBsbLgl2MHBwSAiYS7Z0qXYycQKaYxIV769m6 GLk4hARWMkp0vfrBCuFsZpRoP/KKDaSKTUBdYuuK7cwgtoiAqsSGMysZQWxhAVeJ+0unskPE 3SSePzzFAmGHScxc+h2slwWo/v7sWWA2L1DN0cV7obZ9Y5J4veIrWAOnQITE7sa3TCA2I9BJ 30+tAbOZBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj/+xQtiKEo9bulkg6nUkFuz+xAZha0ssW/ia GWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUTA3o9jAzCA5L1mvKDNXLy+1ZBMjKPod NfR3ML59b3GIUYCDUYmHN45FN0CINbGsuDL3EKMEB7OSCG8MK1CINyWxsiq1KD++qDQntfgQ owUwWCYyS3En5wMTU15JvLGBAQpHSZw3mU0zQEggHZhkslNTC1KLYFqZODhBRnNJiRQDU0Vq UWJpSUY8KKHFFwNTmlQD41yzi6eUWBcW7fr3Mm0Tr+VxqXoXntrTTukd4j4b9ituM2zq8nuy grPloUBmz/1n7/n2pfpqVSxM31GucFJtg8H0o1ap8z+oTNu0WaTEcQdvc3PQA/6Zn3wEcqbI L3R2kVUw9xVKktXU33Uj3vCduGr9wZkVe/avedJg97J02/3Iz2sTPgs2KLEUZyQaajEXFScC AP0dTQUyAwAA 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: Thu, 16 Aug 2012 15:22:51 -0000 Hi Christer, What you describe below is a trust domain applicable only to a particular he= ader field's value, right? Are you saying only if the new value is present, the UA can derive that the= header field value can be trusted as it must have been "subjected to verifi= cation" (any other value for that header field cannot be trusted)? I need to look deeper into trust domains, as I hadn't realized existing (leg= acy?) header fields could be subjected to trust domain, based on that header= field's value. I was so far leaning towards Martin's and Paul's position, where they claim= "emergency" is the right word. Regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Thursday, August 16, 2012 4:28 AM To: Martin Thomson; Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Hi, It is true that some entity in the network needs to verify the context, and= that the call comes from a PSAP. But, once that is done, other entities wit= hin the same network (trust domain) do not need to do that. So, for that reason I think a new value would be good. Regards, Christer ________________________________________ From: Martin Thomson [martin.thomson@gmail.com] Sent: Wednesday, August 15, 2012 7:36 PM To: Paul Kyzivat Cc: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator On 14 August 2012 14:19, Paul Kyzivat wrote: > As I said, I'm *ok* with a new value. > But it offends me to have to add a new value when we already have a > value "emergency" and this *is* an emergency. It sets a precedent that > nobody can use predefined values that weren't assigned for their own > specific case. Its another example of a philosophy that we need to > signal features or use cases rather than simply assemble basic primitives= to accomplish features. I'm with Paul on this one. These are just labels that have essentially arbi= trary or context-specific semantics. This looks very much like a case where= context is everything. "emergency" is the right word. The only concern is that it might have some= other meaning. But those uses are specifically in some other context. Thi= s is a new context (probably based on identification of the PSAP, but that's= simply an example). If context provides insufficient information to enable the sorts of decision= that we want to enable, then a new label isn't going to fix that. _______________________________________________ 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 Fri Aug 17 00:53:00 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 C025021F8592 for ; Fri, 17 Aug 2012 00:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 0MidNq3G1c5U for ; Fri, 17 Aug 2012 00:52:59 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 636C021F858E for ; Fri, 17 Aug 2012 00:52:59 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-9a-502df85950ba Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B6.3D.12641.958FD205; Fri, 17 Aug 2012 09:52:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 17 Aug 2012 09:52:57 +0200 From: Christer Holmberg To: John-Luc Bakker , "ecrit@ietf.org" Date: Fri, 17 Aug 2012 09:52:02 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16WXl1aY8h8dRuRCSVyR9kOOlARwALDA8AAACtJwAAAQZDAAAoYWKAACNaEoAAAWu7QAAjBwE2 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683691@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> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351D94C4@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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW7UD90AgzeTuCwaFz1ltfhzsJXF gcljyZKfTB4TvqxkCWCK4rJJSc3JLEst0rdL4Mo413qQraBDoWLhI98Gxo1SXYycHBICJhIP Jx9kgrDFJC7cW8/WxcjFISRwilGie9EkRghnAaPEruu7gBwODjYBC4nuf9ogDSICHhL/u26A NbMIqEr8XvqTBcQWFnCVuL90KjtEjZvE84enWCDsKIk9l26DxXkFwiVu7PkA1isksJFZYtqN NBCbU8Bd4s/UrWA1jEAHfT+1BqyGWUBc4taT+VCHCkgs2XOeGcIWlXj5+B8rRL2oxJ329YwQ 9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKJybmJmTXm6u l1qUmVxcnJ+nV5y6iREYIQe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGN02cD2elPzL5aZ3DINNplgwm+WfiOJmE1Z7mWdptWnmUjOPh0yMe5tvUeRu mKtWNsmE31Hk4azAZ/62p/ZXl2VHe4lMU+TrPO9n+HHGWs5vEowBf29F2bRw/rrbMsVGvUuw 0f8p64asHDYOrUdpgRvDdSY1GTa7LTVrare9fuhS/ZHra98osRRnJBpqMRcVJwIA3JDg4l4C AAA= 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, 17 Aug 2012 07:53:00 -0000 Hi, I am saying that if the value has been verified, other entities within the = trust domain don't need to perform the verification. And, using a new value= , those entities will also know that it is a PSAP callback. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of John-Luc= Bakker [jbakker@rim.com] Sent: Thursday, August 16, 2012 6:22 PM To: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Hi Christer, What you describe below is a trust domain applicable only to a particular h= eader field's value, right? Are you saying only if the new value is present, the UA can derive that the= header field value can be trusted as it must have been "subjected to verif= ication" (any other value for that header field cannot be trusted)? I need to look deeper into trust domains, as I hadn't realized existing (le= gacy?) header fields could be subjected to trust domain, based on that head= er field's value. I was so far leaning towards Martin's and Paul's position, where they claim= "emergency" is the right word. Regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Thursday, August 16, 2012 4:28 AM To: Martin Thomson; Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Hi, It is true that some entity in the network needs to verify the context, and= that the call comes from a PSAP. But, once that is done, other entities wi= thin the same network (trust domain) do not need to do that. So, for that reason I think a new value would be good. Regards, Christer ________________________________________ From: Martin Thomson [martin.thomson@gmail.com] Sent: Wednesday, August 15, 2012 7:36 PM To: Paul Kyzivat Cc: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator On 14 August 2012 14:19, Paul Kyzivat wrote: > As I said, I'm *ok* with a new value. > But it offends me to have to add a new value when we already have a > value "emergency" and this *is* an emergency. It sets a precedent that > nobody can use predefined values that weren't assigned for their own > specific case. Its another example of a philosophy that we need to > signal features or use cases rather than simply assemble basic primitives= to accomplish features. I'm with Paul on this one. These are just labels that have essentially arb= itrary or context-specific semantics. This looks very much like a case whe= re context is everything. "emergency" is the right word. The only concern is that it might have some= other meaning. But those uses are specifically in some other context. Th= is is a new context (probably based on identification of the PSAP, but that= 's simply an example). If context provides insufficient information to enable the sorts of decisio= n that we want to enable, then a new label isn't going to fix that. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended 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 Fri Aug 17 08:38: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 3569C11E80D5 for ; Fri, 17 Aug 2012 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] 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 4BLcWYmdIn7m for ; Fri, 17 Aug 2012 08:38:29 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4773211E80D1 for ; Fri, 17 Aug 2012 08:38:29 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta06.westchester.pa.mail.comcast.net with comcast id nrZe1j00216LCl056reYq0; Fri, 17 Aug 2012 15:38:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id nreF1j00L3ZTu2S3SreFpF; Fri, 17 Aug 2012 15:38:15 +0000 Message-ID: <502E6573.80107@alum.mit.edu> Date: Fri, 17 Aug 2012 11:38:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ecrit@ietf.org 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> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683691@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, 17 Aug 2012 15:38:30 -0000 On 8/17/12 3:52 AM, Christer Holmberg wrote: > Hi, > > I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PSAP callback. If you are working within a domain you can use whatever criteria you want to decide whether to preserve or remove this header when it comes across the boundary of the domain. If you want, the border elements can only permit it from PSAPs. One it is inside the trust domain, it is what it is. If it's Priority:emergency, then that's what it is. Something inside the trust domain could have put it in. Or something on the boundary of the domain might have a different policy to let it in from some class of users other than PSAPs. My point is that it is an emergency call, which might have a high probability of being an emergency callback from a PSAP. It isn't definitively an emergency callback. And then there needs to be a set of policies for how to handle emergency calls. That might include things like calling barred numbers that you don't want just anybody to be able to do. Of course this is just a philosophical difference from what you said. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of John-Luc Bakker [jbakker@rim.com] > Sent: Thursday, August 16, 2012 6:22 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > Hi Christer, > > What you describe below is a trust domain applicable only to a particular header field's value, right? > Are you saying only if the new value is present, the UA can derive that the header field value can be trusted as it must have been "subjected to verification" (any other value for that header field cannot be trusted)? > > I need to look deeper into trust domains, as I hadn't realized existing (legacy?) header fields could be subjected to trust domain, based on that header field's value. > > I was so far leaning towards Martin's and Paul's position, where they claim "emergency" is the right word. > > Regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, August 16, 2012 4:28 AM > To: Martin Thomson; Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > Hi, > > It is true that some entity in the network needs to verify the context, and that the call comes from a PSAP. But, once that is done, other entities within the same network (trust domain) do not need to do that. > > So, for that reason I think a new value would be good. > > Regards, > > Christer > > ________________________________________ > From: Martin Thomson [martin.thomson@gmail.com] > Sent: Wednesday, August 15, 2012 7:36 PM > To: Paul Kyzivat > Cc: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > On 14 August 2012 14:19, Paul Kyzivat wrote: >> As I said, I'm *ok* with a new value. >> But it offends me to have to add a new value when we already have a >> value "emergency" and this *is* an emergency. It sets a precedent that >> nobody can use predefined values that weren't assigned for their own >> specific case. Its another example of a philosophy that we need to >> signal features or use cases rather than simply assemble basic primitives to accomplish features. > > I'm with Paul on this one. These are just labels that have essentially arbitrary or context-specific semantics. This looks very much like a case where context is everything. > > "emergency" is the right word. The only concern is that it might have some other meaning. But those uses are specifically in some other context. This is a new context (probably based on identification of the PSAP, but that's simply an example). > > If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that. > _______________________________________________ > 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 prvs=35790e9430=jbakker@rim.com Mon Aug 20 12:38: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 681C721F861A for ; Mon, 20 Aug 2012 12:38:47 -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 8nPnhav3rqm1 for ; Mon, 20 Aug 2012 12:38:46 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5232121F85A0 for ; Mon, 20 Aug 2012 12:38:45 -0700 (PDT) X-AuditID: 0a412830-b7f996d000004398-cf-50329244fd67 Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 6A.C1.17304.54292305; Mon, 20 Aug 2012 19:38:45 +0000 (GMT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 14:38:44 -0500 From: John-Luc Bakker To: "ecrit@ietf.org" Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16WXl1aY8h8dRuRCSVyR9kOOlARwALDA8AAACtJwAAAQZDAAAoYWKAACNaEoAAAWu7QAAjBwE2ABrEOYAAlLVSUA== Date: Mon, 20 Aug 2012 19:38:43 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351DB027@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> In-Reply-To: <502E6573.80107@alum.mit.edu> 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+NgFprHKsWRmVeSWpSXmKPExsXC5Zyvp+s6ySjA4NkpbovGRU9ZHRg9liz5 yRTAGNXAaJOUWFIWnJmep29nk5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdBM6eTI2bVzIXnDDoOLeiZOsDYzX1bsYOTkkBEwkVs39xAJhi0lcuLeerYuR i0NIoJdJ4tC7I4wQzmZGiaW3t7OBVLEJqEtsXbGdGcQWEVCV2HBmJSOILSzgKnF/6VR2iLib xPOHp1gg7CyJdzOnsXYxcnCwANW/uQpWwgtU8un0GVYQW0hgEYvEiq2GIDangJbEnlOrwOKM QAd9P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSszYM58Vol5HYsHuT2wQtrbE soWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGAVzM4oNzAyT85L1ijJz9fJSSzYx gmLfUcNgB+P79xaHGAU4GJV4eCd6GgUIsSaWFVfmHmKU4GBWEuEVLAYK8aYkVlalFuXHF5Xm pBYfYrQABspEZinu5HxgWsoriTc2MEDhKInzMnkA9QmkA1NMdmpqQWoRTCsTByfIaC4pkWJg okgtSiwtyYgHpbP4YmBCk2pgXDTv8v2jIRtepBSuantsYS2oN3Vf5aRHanxvebz37JQJ39i3 LdVGXe/Ou02F4SebedaznP18qS3w/LdISf0ep6PJ7/0Tbtyr3co0+/kTS5sZMldUO2/uiFlw 8MT5rBI3zvtnf5Zr7ynK+XNP7RPvJuf4prCSNM9ysxNKGe39Zxd/OngidXV4rxJLcUaioRZz UXEiAD5L27AxAwAA 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, 20 Aug 2012 19:38:47 -0000 Folks, Going back to the original question: > Resolve to use "emergency" as the Private header value, since any new (oth= er) value doesn't offer a real advantage. > > Does anyone disagree as to wg acceptance of this approach in the meeting? I haven't understood the position against using "emergency". I am happy to u= se "emergency" as the Private header value. Kind regards, JL -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat Sent: Friday, August 17, 2012 10:38 AM To: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator On 8/17/12 3:52 AM, Christer Holmberg wrote: > Hi, > > I am saying that if the value has been verified, other entities within the= trust domain don't need to perform the verification. And, using a new value= , those entities will also know that it is a PSAP callback. If you are working within a domain you can use whatever criteria you want to= decide whether to preserve or remove this header when it comes across the b= oundary of the domain. If you want, the border elements can only permit it f= rom PSAPs. One it is inside the trust domain, it is what it is. If it's Priority:emerge= ncy, then that's what it is. Something inside the trust domain could have pu= t it in. Or something on the boundary of the domain might have a different p= olicy to let it in from some class of users other than PSAPs. My point is that it is an emergency call, which might have a high probabilit= y of being an emergency callback from a PSAP. It isn't definitively an emerg= ency callback. And then there needs to be a set of policies for how to handl= e emergency calls. That might include things like calling barred numbers tha= t you don't want just anybody to be able to do. Of course this is just a philosophical difference from what you said. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of > John-Luc Bakker [jbakker@rim.com] > Sent: Thursday, August 16, 2012 6:22 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > Hi Christer, > > What you describe below is a trust domain applicable only to a particular= header field's value, right? > Are you saying only if the new value is present, the UA can derive that th= e header field value can be trusted as it must have been "subjected to verif= ication" (any other value for that header field cannot be trusted)? > > I need to look deeper into trust domains, as I hadn't realized existing (l= egacy?) header fields could be subjected to trust domain, based on that head= er field's value. > > I was so far leaning towards Martin's and Paul's position, where they clai= m "emergency" is the right word. > > Regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Thursday, August 16, 2012 4:28 AM > To: Martin Thomson; Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > Hi, > > It is true that some entity in the network needs to verify the context, an= d that the call comes from a PSAP. But, once that is done, other entities wi= thin the same network (trust domain) do not need to do that. > > So, for that reason I think a new value would be good. > > Regards, > > Christer > > ________________________________________ > From: Martin Thomson [martin.thomson@gmail.com] > Sent: Wednesday, August 15, 2012 7:36 PM > To: Paul Kyzivat > Cc: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > On 14 August 2012 14:19, Paul Kyzivat wrote: >> As I said, I'm *ok* with a new value. >> But it offends me to have to add a new value when we already have a >> value "emergency" and this *is* an emergency. It sets a precedent >> that nobody can use predefined values that weren't assigned for their >> own specific case. Its another example of a philosophy that we need >> to signal features or use cases rather than simply assemble basic primiti= ves to accomplish features. > > I'm with Paul on this one. These are just labels that have essentially ar= bitrary or context-specific semantics. This looks very much like a case whe= re context is everything. > > "emergency" is the right word. The only concern is that it might have som= e other meaning. But those uses are specifically in some other context. Th= is is a new context (probably based on identification of the PSAP, but that'= s simply an example). > > If context provides insufficient information to enable the sorts of decisi= on that we want to enable, then a new label isn't going to fix that. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately 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. > _______________________________________________ > 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 --------------------------------------------------------------------- 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 Mon Aug 20 13:19: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 55B5E21F856C for ; Mon, 20 Aug 2012 13:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 ZQQz7+-TUQ6d for ; Mon, 20 Aug 2012 13:19:22 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3047221F8569 for ; Mon, 20 Aug 2012 13:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345494074; x=1660852461; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=3w8vA/Vu1vfMB4LqvIyS0 sWKvjybglEDKrL2yA6peoE=; b=E6Q0PDvmQYBht1L95+vICerONhvOr/uSXOTpu fFaoo+ijA5JMubvzOTayAlqrJKsaxL9LI2ltMaP2DkUR0asPw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12813579; Mon, 20 Aug 2012 16:21:13 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 20 Aug 2012 16:19:17 -0400 From: "Rosen, Brian" To: John-Luc Bakker Date: Mon, 20 Aug 2012 16:19:16 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/ERK7fYAXyuPMRw+ILu41pM9o3Q== Message-ID: <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@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> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351DB027@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: MJWZL42t9ZzAspWRjnUO/A== 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: Mon, 20 Aug 2012 20:19:23 -0000 I don't care much about this decision. I'd prefer a new one. My reason is that 3261 says: It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Call backs don't necessarily have that implication. They might, but it also= can be much less important. I think most implementors would view the emergency call as having priority = emergency, but not necessarily the call back. That's why I think it would = be better to create a new value. But, as I said, I don't care much. Brian On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: > Folks, >=20 > Going back to the original question: >=20 >> Resolve to use "emergency" as the Private header value, since any new (o= ther) value doesn't offer a real advantage. >>=20 >> Does anyone disagree as to wg acceptance of this approach in the meeting= ? >=20 > I haven't understood the position against using "emergency". I am happy t= o use "emergency" as the Private header value. >=20 > Kind regards, >=20 > JL >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Friday, August 17, 2012 10:38 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > On 8/17/12 3:52 AM, Christer Holmberg wrote: >> Hi, >>=20 >> I am saying that if the value has been verified, other entities within t= he trust domain don't need to perform the verification. And, using a new va= lue, those entities will also know that it is a PSAP callback. >=20 > If you are working within a domain you can use whatever criteria you want= to decide whether to preserve or remove this header when it comes across t= he boundary of the domain. If you want, the border elements can only permit= it from PSAPs. >=20 > One it is inside the trust domain, it is what it is. If it's Priority:eme= rgency, then that's what it is. Something inside the trust domain could hav= e put it in. Or something on the boundary of the domain might have a differ= ent policy to let it in from some class of users other than PSAPs. >=20 > My point is that it is an emergency call, which might have a high probabi= lity of being an emergency callback from a PSAP. It isn't definitively an e= mergency callback. And then there needs to be a set of policies for how to = handle emergency calls. That might include things like calling barred numbe= rs that you don't want just anybody to be able to do. >=20 > Of course this is just a philosophical difference from what you said. >=20 > Thanks, > Paul >=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of=20 >> John-Luc Bakker [jbakker@rim.com] >> Sent: Thursday, August 16, 2012 6:22 PM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> Hi Christer, >>=20 >> What you describe below is a trust domain applicable only to a particula= r header field's value, right? >> Are you saying only if the new value is present, the UA can derive that = the header field value can be trusted as it must have been "subjected to ve= rification" (any other value for that header field cannot be trusted)? >>=20 >> I need to look deeper into trust domains, as I hadn't realized existing = (legacy?) header fields could be subjected to trust domain, based on that h= eader field's value. >>=20 >> I was so far leaning towards Martin's and Paul's position, where they cl= aim "emergency" is the right word. >>=20 >> Regards, >>=20 >> John-Luc >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 >> Of Christer Holmberg >> Sent: Thursday, August 16, 2012 4:28 AM >> To: Martin Thomson; Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> Hi, >>=20 >> It is true that some entity in the network needs to verify the context, = and that the call comes from a PSAP. But, once that is done, other entities= within the same network (trust domain) do not need to do that. >>=20 >> So, for that reason I think a new value would be good. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: Martin Thomson [martin.thomson@gmail.com] >> Sent: Wednesday, August 15, 2012 7:36 PM >> To: Paul Kyzivat >> Cc: Christer Holmberg; ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> On 14 August 2012 14:19, Paul Kyzivat wrote: >>> As I said, I'm *ok* with a new value. >>> But it offends me to have to add a new value when we already have a=20 >>> value "emergency" and this *is* an emergency. It sets a precedent=20 >>> that nobody can use predefined values that weren't assigned for their=20 >>> own specific case. Its another example of a philosophy that we need=20 >>> to signal features or use cases rather than simply assemble basic primi= tives to accomplish features. >>=20 >> I'm with Paul on this one. These are just labels that have essentially = arbitrary or context-specific semantics. This looks very much like a case = where context is everything. >>=20 >> "emergency" is the right word. The only concern is that it might have s= ome other meaning. But those uses are specifically in some other context. = This is a new context (probably based on identification of the PSAP, but t= hat's simply an example). >>=20 >> If context provides insufficient information to enable the sorts of deci= sion that we want to enable, then a new label isn't going to fix that. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y 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 >>=20 >=20 >=20 > _______________________________________________ > 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 Mon Aug 20 14:44: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 2642021F8576 for ; Mon, 20 Aug 2012 14:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 Yl4djYBa-DeU for ; Mon, 20 Aug 2012 14:44:13 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 15AAA21F8566 for ; Mon, 20 Aug 2012 14:44:12 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id p4W61j0030bG4ec589kFjE; Mon, 20 Aug 2012 21:44:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id p9k81j00c3ZTu2S3P9k8Fy; Mon, 20 Aug 2012 21:44:09 +0000 Message-ID: <5032AFAB.4080300@alum.mit.edu> Date: Mon, 20 Aug 2012 17:44:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ecrit@ietf.org 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> In-Reply-To: <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> 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: Mon, 20 Aug 2012 21:44:14 -0000 On 8/20/12 4:19 PM, Rosen, Brian wrote: > I don't care much about this decision. > > I'd prefer a new one. My reason is that 3261 says: > It is RECOMMENDED > that the value of "emergency" only be used when life, limb, or > property are in imminent danger. > > Call backs don't necessarily have that implication. They might, but it also can be much less important. > > I think most implementors would view the emergency call as having priority emergency, but not necessarily the call back. That's why I think it would be better to create a new value. Well, if the callback is happening because the emergency call was inadvertently disconnected, then it is still as much an emergency as it had been. And I thought the psap could perform the "callback" without the priority if it isn't called for. And, if it isn't a matter of life, limb, or property in danger, then I guess the carrier would be entitled to honor barring. Also, the quote you cite argues that "emergency" shouldn't be in use for other sorts of things. > But, as I said, I don't care much. I won't bother to restate my position, since I've already done so enough. Thanks, Paul > Brian > > On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: > >> Folks, >> >> Going back to the original question: >> >>> Resolve to use "emergency" as the Private header value, since any new (other) value doesn't offer a real advantage. >>> >>> Does anyone disagree as to wg acceptance of this approach in the meeting? >> >> I haven't understood the position against using "emergency". I am happy to use "emergency" as the Private header value. >> >> Kind regards, >> >> JL >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, August 17, 2012 10:38 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >> >> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>> Hi, >>> >>> I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PSAP callback. >> >> If you are working within a domain you can use whatever criteria you want to decide whether to preserve or remove this header when it comes across the boundary of the domain. If you want, the border elements can only permit it from PSAPs. >> >> One it is inside the trust domain, it is what it is. If it's Priority:emergency, then that's what it is. Something inside the trust domain could have put it in. Or something on the boundary of the domain might have a different policy to let it in from some class of users other than PSAPs. >> >> My point is that it is an emergency call, which might have a high probability of being an emergency callback from a PSAP. It isn't definitively an emergency callback. And then there needs to be a set of policies for how to handle emergency calls. That might include things like calling barred numbers that you don't want just anybody to be able to do. >> >> Of course this is just a philosophical difference from what you said. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>> John-Luc Bakker [jbakker@rim.com] >>> Sent: Thursday, August 16, 2012 6:22 PM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> Hi Christer, >>> >>> What you describe below is a trust domain applicable only to a particular header field's value, right? >>> Are you saying only if the new value is present, the UA can derive that the header field value can be trusted as it must have been "subjected to verification" (any other value for that header field cannot be trusted)? >>> >>> I need to look deeper into trust domains, as I hadn't realized existing (legacy?) header fields could be subjected to trust domain, based on that header field's value. >>> >>> I was so far leaning towards Martin's and Paul's position, where they claim "emergency" is the right word. >>> >>> Regards, >>> >>> John-Luc >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Christer Holmberg >>> Sent: Thursday, August 16, 2012 4:28 AM >>> To: Martin Thomson; Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> Hi, >>> >>> It is true that some entity in the network needs to verify the context, and that the call comes from a PSAP. But, once that is done, other entities within the same network (trust domain) do not need to do that. >>> >>> So, for that reason I think a new value would be good. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: Martin Thomson [martin.thomson@gmail.com] >>> Sent: Wednesday, August 15, 2012 7:36 PM >>> To: Paul Kyzivat >>> Cc: Christer Holmberg; ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>> As I said, I'm *ok* with a new value. >>>> But it offends me to have to add a new value when we already have a >>>> value "emergency" and this *is* an emergency. It sets a precedent >>>> that nobody can use predefined values that weren't assigned for their >>>> own specific case. Its another example of a philosophy that we need >>>> to signal features or use cases rather than simply assemble basic primitives to accomplish features. >>> >>> I'm with Paul on this one. These are just labels that have essentially arbitrary or context-specific semantics. This looks very much like a case where context is everything. >>> >>> "emergency" is the right word. The only concern is that it might have some other meaning. But those uses are specifically in some other context. This is a new context (probably based on identification of the PSAP, but that's simply an example). >>> >>> If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that. >>> _______________________________________________ >>> 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 >> >> --------------------------------------------------------------------- >> 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 christer.holmberg@ericsson.com Tue Aug 21 00:56: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 2698D21F86B7 for ; Tue, 21 Aug 2012 00:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.152 X-Spam-Level: X-Spam-Status: No, score=-6.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 teA2RYXJTPpY for ; Tue, 21 Aug 2012 00:56:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8161721F862A for ; Tue, 21 Aug 2012 00:56:44 -0700 (PDT) X-AuditID: c1b4fb25-b7f236d000005cde-08-50333f3a1a65 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A7.AD.23774.A3F33305; Tue, 21 Aug 2012 09:56:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 21 Aug 2012 09:56:41 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "ecrit@ietf.org" Date: Tue, 21 Aug 2012 09:56:41 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/HPNEN2zAd2x0RaGMXIWaMx9JlQAVHlgg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@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> In-Reply-To: <5032AFAB.4080300@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+Jvra6VvXGAwZUXUhaNi56yWqzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYOG8bU8Fy94rjG7UbGHdadTFyckgImEhs OrePCcIWk7hwbz1bFyMXh5DAKUaJk6+vMkE4Cxgl5j/7xtLFyMHBJmAh0f1PG6RBRMBXYl1n FzOIzSKgKnGsp50dxBYWcJW4v3QqO0SNm8Tzh6dYIGwjicZbF1lBbF6BcInnrXOg5m9jlbi3 7SsjSIJTQEfi+ayFYBcxAl30/dQaMJtZQFzi1pP5UJcKSCzZc54ZwhaVePn4HytEvajEnfb1 jBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUonJuYmZNe bqSXWpSZXFycn6dXnLqJERgjB7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwrty/5pl1L+fMYwVJZuaZDHH3ZSbOvcTi92zDhgOh9sVPNth+YmTI0YsW abZ9f/L9v+sejtN2HfK/skrT8sGlTlfTb4vYPFc+vzt1/hyVKdrcRUxCgoYTZs7M31rBYWQj 2NjCckrv+12HurxfzxJVF02Te7fYz8fK+fDDl96hc1bPvxG+5FWdiBJLcUaioRZzUXEiAAgi bgpfAgAA 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, 21 Aug 2012 07:56:46 -0000 Hi, >>> I don't care much about this decision. >>> >>> I'd prefer a new one. My reason is that 3261 says: >>> It is RECOMMENDED that the value of "emergency" only be used when life,= limb, or >>> property are in imminent danger. >> >> Call backs don't necessarily have that implication. They might, but it a= lso can be much less important. >> >> I think most implementors would view the emergency call as having priori= ty emergency, but not necessarily the call back. That's why I think it wou= ld be better to create a new value. > > Well, if the callback is happening because the emergency call was inadver= tently disconnected, then it is still as much an emergency as it had been. > > And I thought the psap could perform the "callback" without the priority = if it isn't called for. > > And, if it isn't a matter of life, limb, or property in danger, then I gu= ess the carrier would be entitled to honor barring. AFAIK, in countries where special treatment is given to PSAP callbacks, it = applies to *ALL* callbacks. Now, in such countries, whether some callbacks = would be given different importance, I don't know. But, it means that all c= allbacks have to be indicated as callbacks. So, if we think that there are cases where an PSAP would not indicate "emer= gency" for a PSAP callback, I really think we need a separate value. Regards, Christer > On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: > >> Folks, >> >> Going back to the original question: >> >>> Resolve to use "emergency" as the Private header value, since any new (= other) value doesn't offer a real advantage. >>> >>> Does anyone disagree as to wg acceptance of this approach in the meetin= g? >> >> I haven't understood the position against using "emergency". I am happy = to use "emergency" as the Private header value. >> >> Kind regards, >> >> JL >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: Friday, August 17, 2012 10:38 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >> >> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>> Hi, >>> >>> I am saying that if the value has been verified, other entities within = the trust domain don't need to perform the verification. And, using a new v= alue, those entities will also know that it is a PSAP callback. >> >> If you are working within a domain you can use whatever criteria you wan= t to decide whether to preserve or remove this header when it comes across = the boundary of the domain. If you want, the border elements can only permi= t it from PSAPs. >> >> One it is inside the trust domain, it is what it is. If it's Priority:em= ergency, then that's what it is. Something inside the trust domain could ha= ve put it in. Or something on the boundary of the domain might have a diffe= rent policy to let it in from some class of users other than PSAPs. >> >> My point is that it is an emergency call, which might have a high probab= ility of being an emergency callback from a PSAP. It isn't definitively an = emergency callback. And then there needs to be a set of policies for how to= handle emergency calls. That might include things like calling barred numb= ers that you don't want just anybody to be able to do. >> >> Of course this is just a philosophical difference from what you said. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of=20 >>> John-Luc Bakker [jbakker@rim.com] >>> Sent: Thursday, August 16, 2012 6:22 PM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>> Indicator >>> >>> Hi Christer, >>> >>> What you describe below is a trust domain applicable only to a particul= ar header field's value, right? >>> Are you saying only if the new value is present, the UA can derive that= the header field value can be trusted as it must have been "subjected to v= erification" (any other value for that header field cannot be trusted)? >>> >>> I need to look deeper into trust domains, as I hadn't realized existing= (legacy?) header fields could be subjected to trust domain, based on that = header field's value. >>> >>> I was so far leaning towards Martin's and Paul's position, where they c= laim "emergency" is the right word. >>> >>> Regards, >>> >>> John-Luc >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>> Behalf Of Christer Holmberg >>> Sent: Thursday, August 16, 2012 4:28 AM >>> To: Martin Thomson; Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>> Indicator >>> >>> Hi, >>> >>> It is true that some entity in the network needs to verify the context,= and that the call comes from a PSAP. But, once that is done, other entitie= s within the same network (trust domain) do not need to do that. >>> >>> So, for that reason I think a new value would be good. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: Martin Thomson [martin.thomson@gmail.com] >>> Sent: Wednesday, August 15, 2012 7:36 PM >>> To: Paul Kyzivat >>> Cc: Christer Holmberg; ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>> Indicator >>> >>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>> As I said, I'm *ok* with a new value. >>>> But it offends me to have to add a new value when we already have a=20 >>>> value "emergency" and this *is* an emergency. It sets a precedent=20 >>>> that nobody can use predefined values that weren't assigned for=20 >>>> their own specific case. Its another example of a philosophy that=20 >>>> we need to signal features or use cases rather than simply assemble ba= sic primitives to accomplish features. >>> >>> I'm with Paul on this one. These are just labels that have essentially= arbitrary or context-specific semantics. This looks very much like a case= where context is everything. >>> >>> "emergency" is the right word. The only concern is that it might have = some other meaning. But those uses are specifically in some other context.= This is a new context (probably based on identification of the PSAP, but = that's simply an example). >>> >>> If context provides insufficient information to enable the sorts of dec= ision that we want to enable, then a new label isn't going to fix that. >>> _______________________________________________ >>> 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 prote= cted by the solicitor-client or other applicable privileges), or constitute= non-public information. Any use of this information by anyone other than t= he intended recipient is prohibited. If you have received this transmission= in error, please immediately reply to the sender and delete this informati= on from your system. Use, dissemination, distribution, or reproduction of t= his transmission by unintended recipients is not authorized and may be unla= wful. >>> _______________________________________________ >>> 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 >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y 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 From mlinsner@cisco.com Tue Aug 21 05:16:40 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 76D3721F8618 for ; Tue, 21 Aug 2012 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrsO48Mbr2bm for ; Tue, 21 Aug 2012 05:16:39 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8CC21F860D for ; Tue, 21 Aug 2012 05:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=8608; q=dns/txt; s=iport; t=1345551398; x=1346760998; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=/gVR64X/Ozn4ZnGl3jwnXtxbck0IFZbBPzJc3NOdo2s=; b=RL4S+RNa7/WuWaNTnYwXazpj1nN2sZRrL4sm9LOeV4hnZYMmzju+20D5 k0CW+Br3SGRIhmwAr3hK8uVZjdDiZAiVV08DigEfpAj8+73796RxuLTlv T9aQEaJBud9f5OKyFXIVsZ3VGh6r8ihPS9rM+2+jJZIrxwKECzmFl8yEg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPB7M1BIo8UY/2dsb2JhbABFu2aCIAEBAQQBAQEPAScCATEXBwgRAwEBAQEnKAYfCQgGExkJh1wDDAuXWIEollUNiUoEiiVjhxwDk3+BU4VchTGDIIFmgn0 X-IronPort-AV: E=Sophos;i="4.77,802,1336348800"; d="scan'208";a="16289176" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 21 Aug 2012 12:16:15 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7LCGDfN030482 for ; Tue, 21 Aug 2012 12:16:14 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 21 Aug 2012 08:16:12 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator In-Reply-To: <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: Tue, 21 Aug 2012 12:16:40 -0000 If a PSAP callback *could* be something other than an emergency, what's wrong with using less ambigous 'PSAP-callback' as the indicator? -Marc- -----Original Message----- From: "Rosen, Brian" Date: Monday, August 20, 2012 4:19 PM To: John-Luc Bakker Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >I don't care much about this decision. > >I'd prefer a new one. My reason is that 3261 says: >It is RECOMMENDED > that the value of "emergency" only be used when life, limb, or > property are in imminent danger. > >Call backs don't necessarily have that implication. They might, but it >also can be much less important. > >I think most implementors would view the emergency call as having >priority emergency, but not necessarily the call back. That's why I >think it would be better to create a new value. > >But, as I said, I don't care much. > >Brian > >On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: > >> Folks, >> >> Going back to the original question: >> >>> Resolve to use "emergency" as the Private header value, since any new >>>(other) value doesn't offer a real advantage. >>> >>> Does anyone disagree as to wg acceptance of this approach in the >>>meeting? >> >> I haven't understood the position against using "emergency". I am happy >>to use "emergency" as the Private header value. >> >> Kind regards, >> >> JL >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>Of Paul Kyzivat >> Sent: Friday, August 17, 2012 10:38 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >> >> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>> Hi, >>> >>> I am saying that if the value has been verified, other entities within >>>the trust domain don't need to perform the verification. And, using a >>>new value, those entities will also know that it is a PSAP callback. >> >> If you are working within a domain you can use whatever criteria you >>want to decide whether to preserve or remove this header when it comes >>across the boundary of the domain. If you want, the border elements can >>only permit it from PSAPs. >> >> One it is inside the trust domain, it is what it is. If it's >>Priority:emergency, then that's what it is. Something inside the trust >>domain could have put it in. Or something on the boundary of the domain >>might have a different policy to let it in from some class of users >>other than PSAPs. >> >> My point is that it is an emergency call, which might have a high >>probability of being an emergency callback from a PSAP. It isn't >>definitively an emergency callback. And then there needs to be a set of >>policies for how to handle emergency calls. That might include things >>like calling barred numbers that you don't want just anybody to be able >>to do. >> >> Of course this is just a philosophical difference from what you said. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>> John-Luc Bakker [jbakker@rim.com] >>> Sent: Thursday, August 16, 2012 6:22 PM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> Hi Christer, >>> >>> What you describe below is a trust domain applicable only to a >>>particular header field's value, right? >>> Are you saying only if the new value is present, the UA can derive >>>that the header field value can be trusted as it must have been >>>"subjected to verification" (any other value for that header field >>>cannot be trusted)? >>> >>> I need to look deeper into trust domains, as I hadn't realized >>>existing (legacy?) header fields could be subjected to trust domain, >>>based on that header field's value. >>> >>> I was so far leaning towards Martin's and Paul's position, where they >>>claim "emergency" is the right word. >>> >>> Regards, >>> >>> John-Luc >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Christer Holmberg >>> Sent: Thursday, August 16, 2012 4:28 AM >>> To: Martin Thomson; Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> Hi, >>> >>> It is true that some entity in the network needs to verify the >>>context, and that the call comes from a PSAP. But, once that is done, >>>other entities within the same network (trust domain) do not need to do >>>that. >>> >>> So, for that reason I think a new value would be good. >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________________ >>> From: Martin Thomson [martin.thomson@gmail.com] >>> Sent: Wednesday, August 15, 2012 7:36 PM >>> To: Paul Kyzivat >>> Cc: Christer Holmberg; ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>> As I said, I'm *ok* with a new value. >>>> But it offends me to have to add a new value when we already have a >>>> value "emergency" and this *is* an emergency. It sets a precedent >>>> that nobody can use predefined values that weren't assigned for their >>>> own specific case. Its another example of a philosophy that we need >>>> to signal features or use cases rather than simply assemble basic >>>>primitives to accomplish features. >>> >>> I'm with Paul on this one. These are just labels that have >>>essentially arbitrary or context-specific semantics. This looks very >>>much like a case where context is everything. >>> >>> "emergency" is the right word. The only concern is that it might have >>>some other meaning. But those uses are specifically in some other >>>context. This is a new context (probably based on identification of >>>the PSAP, but that's simply an example). >>> >>> If context provides insufficient information to enable the sorts of >>>decision that we want to enable, then a new label isn't going to fix >>>that. >>> _______________________________________________ >>> 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 >> >> --------------------------------------------------------------------- >> 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 hannes.tschofenig@nsn.com Tue Aug 21 05:33: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 B021621F8639 for ; Tue, 21 Aug 2012 05:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 CPbRZBd8g+3R for ; Tue, 21 Aug 2012 05:33:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 522B621F861F for ; Tue, 21 Aug 2012 05:33:23 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7LCXGme002979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 14:33:17 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7LCXErP010688; Tue, 21 Aug 2012 14:33:14 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 14:32:54 +0200 Received: from 10.144.253.163 ([10.144.253.163]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Aug 2012 12:32:53 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 21 Aug 2012 15:32:51 +0300 From: Hannes Tschofenig To: Marc Linsner , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/mRQ+GfCcBjo8fk+fN5Tmtna7nQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Aug 2012 12:32:54.0078 (UTC) FILETIME=[161485E0:01CD7F99] 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: 9150 X-purgate-ID: 151667::1345552397-00006F5F-AE32F521/0-0/0-0 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, 21 Aug 2012 12:33:25 -0000 I agree with you Marc. On 8/21/12 3:16 PM, "Marc Linsner" wrote: > If a PSAP callback *could* be something other than an emergency, what's > wrong with using less ambigous 'PSAP-callback' as the indicator? > > -Marc- > > -----Original Message----- > From: "Rosen, Brian" > Date: Monday, August 20, 2012 4:19 PM > To: John-Luc Bakker > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > >> I don't care much about this decision. >> >> I'd prefer a new one. My reason is that 3261 says: >> It is RECOMMENDED >> that the value of "emergency" only be used when life, limb, or >> property are in imminent danger. >> >> Call backs don't necessarily have that implication. They might, but it >> also can be much less important. >> >> I think most implementors would view the emergency call as having >> priority emergency, but not necessarily the call back. That's why I >> think it would be better to create a new value. >> >> But, as I said, I don't care much. >> >> Brian >> >> On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: >> >>> Folks, >>> >>> Going back to the original question: >>> >>>> Resolve to use "emergency" as the Private header value, since any new >>>> (other) value doesn't offer a real advantage. >>>> >>>> Does anyone disagree as to wg acceptance of this approach in the >>>> meeting? >>> >>> I haven't understood the position against using "emergency". I am happy >>> to use "emergency" as the Private header value. >>> >>> Kind regards, >>> >>> JL >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Friday, August 17, 2012 10:38 AM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> I am saying that if the value has been verified, other entities within >>>> the trust domain don't need to perform the verification. And, using a >>>> new value, those entities will also know that it is a PSAP callback. >>> >>> If you are working within a domain you can use whatever criteria you >>> want to decide whether to preserve or remove this header when it comes >>> across the boundary of the domain. If you want, the border elements can >>> only permit it from PSAPs. >>> >>> One it is inside the trust domain, it is what it is. If it's >>> Priority:emergency, then that's what it is. Something inside the trust >>> domain could have put it in. Or something on the boundary of the domain >>> might have a different policy to let it in from some class of users >>> other than PSAPs. >>> >>> My point is that it is an emergency call, which might have a high >>> probability of being an emergency callback from a PSAP. It isn't >>> definitively an emergency callback. And then there needs to be a set of >>> policies for how to handle emergency calls. That might include things >>> like calling barred numbers that you don't want just anybody to be able >>> to do. >>> >>> Of course this is just a philosophical difference from what you said. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>> John-Luc Bakker [jbakker@rim.com] >>>> Sent: Thursday, August 16, 2012 6:22 PM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> Hi Christer, >>>> >>>> What you describe below is a trust domain applicable only to a >>>> particular header field's value, right? >>>> Are you saying only if the new value is present, the UA can derive >>>> that the header field value can be trusted as it must have been >>>> "subjected to verification" (any other value for that header field >>>> cannot be trusted)? >>>> >>>> I need to look deeper into trust domains, as I hadn't realized >>>> existing (legacy?) header fields could be subjected to trust domain, >>>> based on that header field's value. >>>> >>>> I was so far leaning towards Martin's and Paul's position, where they >>>> claim "emergency" is the right word. >>>> >>>> Regards, >>>> >>>> John-Luc >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Christer Holmberg >>>> Sent: Thursday, August 16, 2012 4:28 AM >>>> To: Martin Thomson; Paul Kyzivat >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> Hi, >>>> >>>> It is true that some entity in the network needs to verify the >>>> context, and that the call comes from a PSAP. But, once that is done, >>>> other entities within the same network (trust domain) do not need to do >>>> that. >>>> >>>> So, for that reason I think a new value would be good. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: Martin Thomson [martin.thomson@gmail.com] >>>> Sent: Wednesday, August 15, 2012 7:36 PM >>>> To: Paul Kyzivat >>>> Cc: Christer Holmberg; ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>>> As I said, I'm *ok* with a new value. >>>>> But it offends me to have to add a new value when we already have a >>>>> value "emergency" and this *is* an emergency. It sets a precedent >>>>> that nobody can use predefined values that weren't assigned for their >>>>> own specific case. Its another example of a philosophy that we need >>>>> to signal features or use cases rather than simply assemble basic >>>>> primitives to accomplish features. >>>> >>>> I'm with Paul on this one. These are just labels that have >>>> essentially arbitrary or context-specific semantics. This looks very >>>> much like a case where context is everything. >>>> >>>> "emergency" is the right word. The only concern is that it might have >>>> some other meaning. But those uses are specifically in some other >>>> context. This is a new context (probably based on identification of >>>> the PSAP, but that's simply an example). >>>> >>>> If context provides insufficient information to enable the sorts of >>>> decision that we want to enable, then a new label isn't going to fix >>>> that. >>>> _______________________________________________ >>>> 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 >>> >>> --------------------------------------------------------------------- >>> 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 From pkyzivat@alum.mit.edu Tue Aug 21 06:43: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 569A321F865B for ; Tue, 21 Aug 2012 06:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] 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 CWAQgPpU463Z for ; Tue, 21 Aug 2012 06:43:55 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id A87E421F8645 for ; Tue, 21 Aug 2012 06:43:48 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id pRjJ1j0051HzFnQ5FRk4NR; Tue, 21 Aug 2012 13:44:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id pRjq1j00N3ZTu2S3aRjqhE; Tue, 21 Aug 2012 13:43:50 +0000 Message-ID: <50339093.5080700@alum.mit.edu> Date: Tue, 21 Aug 2012 09:43:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg 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> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> 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: Tue, 21 Aug 2012 13:43:56 -0000 On 8/21/12 3:56 AM, Christer Holmberg wrote: > > Hi, > >>>> I don't care much about this decision. >>>> >>>> I'd prefer a new one. My reason is that 3261 says: >>>> It is RECOMMENDED that the value of "emergency" only be used when life, limb, or >>>> property are in imminent danger. >>> >>> Call backs don't necessarily have that implication. They might, but it also can be much less important. >>> >>> I think most implementors would view the emergency call as having priority emergency, but not necessarily the call back. That's why I think it would be better to create a new value. >> >> Well, if the callback is happening because the emergency call was inadvertently disconnected, then it is still as much an emergency as it had been. >> >> And I thought the psap could perform the "callback" without the priority if it isn't called for. >> >> And, if it isn't a matter of life, limb, or property in danger, then I guess the carrier would be entitled to honor barring. > > AFAIK, in countries where special treatment is given to PSAP callbacks, it applies to *ALL* callbacks. Now, in such countries, whether some callbacks would be given different importance, I don't know. But, it means that all callbacks have to be indicated as callbacks. > So, if we think that there are cases where an PSAP would not indicate "emergency" for a PSAP callback, I really think we need a separate value. Do you mean that if I make an emergency call today, and then next week the psap decides to call me back to take a survey about how nice they were on the phone, that should still be treated as an emergency callback that gets priority and can bypass barring??? Or if the operator in the PSAP calls to have pizza delivered for lunch that should be treated as an emergency callback and work even if the pizza place has had its calls barred? I presume not. Rather, doesn't it need to be on a call by call basis, the psap will mark the calls that should be treated as emergency callback calls? If so, then the job of the provider sw is to honor the marking if its there, and perhaps to screen which lines are permitted to include the marking. In that case the psap can include "priority:xyz" for those calls it considers to be deserving of emergency callback treatment, and not include that marking for other calls. And that is the same whether "xyz" is "emergency" or "PSAP-callback". Thanks, Paul > Regards, > > Christer > > > > >> On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: >> >>> Folks, >>> >>> Going back to the original question: >>> >>>> Resolve to use "emergency" as the Private header value, since any new (other) value doesn't offer a real advantage. >>>> >>>> Does anyone disagree as to wg acceptance of this approach in the meeting? >>> >>> I haven't understood the position against using "emergency". I am happy to use "emergency" as the Private header value. >>> >>> Kind regards, >>> >>> JL >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Friday, August 17, 2012 10:38 AM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PSAP callback. >>> >>> If you are working within a domain you can use whatever criteria you want to decide whether to preserve or remove this header when it comes across the boundary of the domain. If you want, the border elements can only permit it from PSAPs. >>> >>> One it is inside the trust domain, it is what it is. If it's Priority:emergency, then that's what it is. Something inside the trust domain could have put it in. Or something on the boundary of the domain might have a different policy to let it in from some class of users other than PSAPs. >>> >>> My point is that it is an emergency call, which might have a high probability of being an emergency callback from a PSAP. It isn't definitively an emergency callback. And then there needs to be a set of policies for how to handle emergency calls. That might include things like calling barred numbers that you don't want just anybody to be able to do. >>> >>> Of course this is just a philosophical difference from what you said. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>> John-Luc Bakker [jbakker@rim.com] >>>> Sent: Thursday, August 16, 2012 6:22 PM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>> Indicator >>>> >>>> Hi Christer, >>>> >>>> What you describe below is a trust domain applicable only to a particular header field's value, right? >>>> Are you saying only if the new value is present, the UA can derive that the header field value can be trusted as it must have been "subjected to verification" (any other value for that header field cannot be trusted)? >>>> >>>> I need to look deeper into trust domains, as I hadn't realized existing (legacy?) header fields could be subjected to trust domain, based on that header field's value. >>>> >>>> I was so far leaning towards Martin's and Paul's position, where they claim "emergency" is the right word. >>>> >>>> Regards, >>>> >>>> John-Luc >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: Thursday, August 16, 2012 4:28 AM >>>> To: Martin Thomson; Paul Kyzivat >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>> Indicator >>>> >>>> Hi, >>>> >>>> It is true that some entity in the network needs to verify the context, and that the call comes from a PSAP. But, once that is done, other entities within the same network (trust domain) do not need to do that. >>>> >>>> So, for that reason I think a new value would be good. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: Martin Thomson [martin.thomson@gmail.com] >>>> Sent: Wednesday, August 15, 2012 7:36 PM >>>> To: Paul Kyzivat >>>> Cc: Christer Holmberg; ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>> Indicator >>>> >>>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>>> As I said, I'm *ok* with a new value. >>>>> But it offends me to have to add a new value when we already have a >>>>> value "emergency" and this *is* an emergency. It sets a precedent >>>>> that nobody can use predefined values that weren't assigned for >>>>> their own specific case. Its another example of a philosophy that >>>>> we need to signal features or use cases rather than simply assemble basic primitives to accomplish features. >>>> >>>> I'm with Paul on this one. These are just labels that have essentially arbitrary or context-specific semantics. This looks very much like a case where context is everything. >>>> >>>> "emergency" is the right word. The only concern is that it might have some other meaning. But those uses are specifically in some other context. This is a new context (probably based on identification of the PSAP, but that's simply an example). >>>> >>>> If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that. >>>> _______________________________________________ >>>> 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 >>> >>> --------------------------------------------------------------------- >>> 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 > From brian.rosen@neustar.biz Tue Aug 21 07:06:48 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 CC97E21F8685 for ; Tue, 21 Aug 2012 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 lO9jN9H9duxh for ; Tue, 21 Aug 2012 07:06:47 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C021F8688 for ; Tue, 21 Aug 2012 07:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345557769; x=1660913346; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Pxs8ME68qDFcMOkgrEHJG b3yIz2qTPzpLHczwNL610s=; b=MSR7fdn/p4aHRVMl80J/i/bwz5u4B7De8Xrx9 WSD58WWpHbOW85jMT+0nv0am5ypINbKLXOvaMzfHyroGMtn/A== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10141655; Tue, 21 Aug 2012 10:02:48 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 21 Aug 2012 10:06:40 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Tue, 21 Aug 2012 10:06:39 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/pi9+kDa76vEPRgmmjti29DdFzQ== Message-ID: <9B223AC4-EEB9-47BF-B7CE-2277342CEFE0@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> In-Reply-To: <50339093.5080700@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: NCbat0hx9G19rae9yMu7Aw== 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, 21 Aug 2012 14:06:48 -0000 We already differentiate between a call back to the device that sent the ca= ll (Contact) vs a call back that happens later and is intended to reach the= caller rather than the device (AoR). I don't think it would be appropriat= e in most cases to use any kind of special treatment to a call placed a few= days after the emergency call placed to the AoR (and Contact is not likely= to work at that point). OTOH, I can't see any hard and fast rules here. I agree with your premise though - you mark the calls appropriately, regard= less of what the marking we decide upon, and policing the marking is going = to be important to avoid abuse. Brian On Aug 21, 2012, at 9:43 AM, Paul Kyzivat wrote: > On 8/21/12 3:56 AM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >>>>> I don't care much about this decision. >>>>>=20 >>>>> I'd prefer a new one. My reason is that 3261 says: >>>>> It is RECOMMENDED that the value of "emergency" only be used when lif= e, limb, or >>>>> property are in imminent danger. >>>>=20 >>>> Call backs don't necessarily have that implication. They might, but it= also can be much less important. >>>>=20 >>>> I think most implementors would view the emergency call as having prio= rity emergency, but not necessarily the call back. That's why I think it w= ould be better to create a new value. >>>=20 >>> Well, if the callback is happening because the emergency call was inadv= ertently disconnected, then it is still as much an emergency as it had been= . >>>=20 >>> And I thought the psap could perform the "callback" without the priorit= y if it isn't called for. >>>=20 >>> And, if it isn't a matter of life, limb, or property in danger, then I = guess the carrier would be entitled to honor barring. >>=20 >> AFAIK, in countries where special treatment is given to PSAP callbacks, = it applies to *ALL* callbacks. Now, in such countries, whether some callbac= ks would be given different importance, I don't know. But, it means that al= l callbacks have to be indicated as callbacks. >=20 >> So, if we think that there are cases where an PSAP would not indicate "e= mergency" for a PSAP callback, I really think we need a separate value. >=20 > Do you mean that if I make an emergency call today, and then next week th= e psap decides to call me back to take a survey about how nice they were on= the phone, that should still be treated as an emergency callback that gets= priority and can bypass barring??? >=20 > Or if the operator in the PSAP calls to have pizza delivered for lunch th= at should be treated as an emergency callback and work even if the pizza pl= ace has had its calls barred? >=20 > I presume not. Rather, doesn't it need to be on a call by call basis, the= psap will mark the calls that should be treated as emergency callback call= s? >=20 > If so, then the job of the provider sw is to honor the marking if its the= re, and perhaps to screen which lines are permitted to include the marking. >=20 > In that case the psap can include "priority:xyz" for those calls it consi= ders to be deserving of emergency callback treatment, and not include that = marking for other calls. And that is the same whether "xyz" is "emergency" = or "PSAP-callback". >=20 > Thanks, > Paul >=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>> On Aug 20, 2012, at 3:38 PM, John-Luc Bakker wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Going back to the original question: >>>>=20 >>>>> Resolve to use "emergency" as the Private header value, since any new= (other) value doesn't offer a real advantage. >>>>>=20 >>>>> Does anyone disagree as to wg acceptance of this approach in the meet= ing? >>>>=20 >>>> I haven't understood the position against using "emergency". I am happ= y to use "emergency" as the Private header value. >>>>=20 >>>> Kind regards, >>>>=20 >>>> JL >>>>=20 >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Friday, August 17, 2012 10:38 AM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>>=20 >>>> On 8/17/12 3:52 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>> I am saying that if the value has been verified, other entities withi= n the trust domain don't need to perform the verification. And, using a new= value, those entities will also know that it is a PSAP callback. >>>>=20 >>>> If you are working within a domain you can use whatever criteria you w= ant to decide whether to preserve or remove this header when it comes acros= s the boundary of the domain. If you want, the border elements can only per= mit it from PSAPs. >>>>=20 >>>> One it is inside the trust domain, it is what it is. If it's Priority:= emergency, then that's what it is. Something inside the trust domain could = have put it in. Or something on the boundary of the domain might have a dif= ferent policy to let it in from some class of users other than PSAPs. >>>>=20 >>>> My point is that it is an emergency call, which might have a high prob= ability of being an emergency callback from a PSAP. It isn't definitively a= n emergency callback. And then there needs to be a set of policies for how = to handle emergency calls. That might include things like calling barred nu= mbers that you don't want just anybody to be able to do. >>>>=20 >>>> Of course this is just a philosophical difference from what you said. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> ________________________________________ >>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>>> John-Luc Bakker [jbakker@rim.com] >>>>> Sent: Thursday, August 16, 2012 6:22 PM >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>>> Indicator >>>>>=20 >>>>> Hi Christer, >>>>>=20 >>>>> What you describe below is a trust domain applicable only to a partic= ular header field's value, right? >>>>> Are you saying only if the new value is present, the UA can derive th= at the header field value can be trusted as it must have been "subjected to= verification" (any other value for that header field cannot be trusted)? >>>>>=20 >>>>> I need to look deeper into trust domains, as I hadn't realized existi= ng (legacy?) header fields could be subjected to trust domain, based on tha= t header field's value. >>>>>=20 >>>>> I was so far leaning towards Martin's and Paul's position, where they= claim "emergency" is the right word. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> John-Luc >>>>>=20 >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of Christer Holmberg >>>>> Sent: Thursday, August 16, 2012 4:28 AM >>>>> To: Martin Thomson; Paul Kyzivat >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>>> Indicator >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> It is true that some entity in the network needs to verify the contex= t, and that the call comes from a PSAP. But, once that is done, other entit= ies within the same network (trust domain) do not need to do that. >>>>>=20 >>>>> So, for that reason I think a new value would be good. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> ________________________________________ >>>>> From: Martin Thomson [martin.thomson@gmail.com] >>>>> Sent: Wednesday, August 15, 2012 7:36 PM >>>>> To: Paul Kyzivat >>>>> Cc: Christer Holmberg; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>>> Indicator >>>>>=20 >>>>> On 14 August 2012 14:19, Paul Kyzivat wrote: >>>>>> As I said, I'm *ok* with a new value. >>>>>> But it offends me to have to add a new value when we already have a >>>>>> value "emergency" and this *is* an emergency. It sets a precedent >>>>>> that nobody can use predefined values that weren't assigned for >>>>>> their own specific case. Its another example of a philosophy that >>>>>> we need to signal features or use cases rather than simply assemble = basic primitives to accomplish features. >>>>>=20 >>>>> I'm with Paul on this one. These are just labels that have essential= ly arbitrary or context-specific semantics. This looks very much like a ca= se where context is everything. >>>>>=20 >>>>> "emergency" is the right word. The only concern is that it might hav= e some other meaning. But those uses are specifically in some other contex= t. This is a new context (probably based on identification of the PSAP, bu= t that's simply an example). >>>>>=20 >>>>> If context provides insufficient information to enable the sorts of d= ecision that we want to enable, then a new label isn't going to fix that. >>>>> _______________________________________________ >>>>> 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 pro= tected by the solicitor-client or other applicable privileges), or constitu= te non-public information. Any use of this information by anyone other than= the intended recipient is prohibited. If you have received this transmissi= on in error, please immediately reply to the sender and delete this informa= tion from your system. Use, dissemination, distribution, or reproduction of= this transmission by unintended recipients is not authorized and may be un= lawful. >>>>> _______________________________________________ >>>>> 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 >>>>=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 soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended reci= pient is prohibited. If you have received this transmission in error, pleas= e immediately reply to the sender and delete this information from your sys= tem. 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 >>>=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 bernard_aboba@hotmail.com Tue Aug 21 07:49:52 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 34A7F21F8501 for ; Tue, 21 Aug 2012 07:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 ypOwX-eVwRuB for ; Tue, 21 Aug 2012 07:49:51 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 22FD621F84E2 for ; Tue, 21 Aug 2012 07:49:51 -0700 (PDT) Received: from BLU401-EAS245 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 07:49:50 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [n1kKiyV0HIwHoIMAr19d8Kk2Or85BbuC] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Date: Tue, 21 Aug 2012 07:49:47 -0700 From: Bernard Aboba To: Hannes Tschofenig MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 21 Aug 2012 14:49:50.0575 (UTC) FILETIME=[377E77F0:01CD7FAC] 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, 21 Aug 2012 14:49:52 -0000 +1 Hannes Tschofenig wrote: I agree with you Marc. On 8/21/12 3:16 PM=2C "Marc Linsner" wrote: > If a PSAP callback *could* be something other than an emergency=2C what's > wrong with using less ambigous 'PSAP-callback' as the indicator? > > -Marc- > > -----Original Message----- > From: "Rosen=2C Brian" > Date: Monday=2C August 20=2C 2012 4:19 PM > To: John-Luc Bakker > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > >> I don't care much about this decision. >> >> I'd prefer a new one. My reason is that 3261 says: >> It is RECOMMENDED >> that the value of "emergency" only be used when life=2C limb=2C or >> property are in imminent danger. >> >> Call backs don't necessarily have that implication. They might=2C but it >> also can be much less important. >> >> I think most implementors would view the emergency call as having >> priority emergency=2C but not necessarily the call back. That's why I >> think it would be better to create a new value. >> >> But=2C as I said=2C I don't care much. >> >> Brian >> >> On Aug 20=2C 2012=2C at 3:38 PM=2C John-Luc Bakker wro= te: >> >>> Folks=2C >>> >>> Going back to the original question: >>> >>>> Resolve to use "emergency" as the Private header value=2C since any ne= w >>>> (other) value doesn't offer a real advantage. >>>> >>>> Does anyone disagree as to wg acceptance of this approach in the >>>> meeting? >>> >>> I haven't understood the position against using "emergency". I am happy >>> to use "emergency" as the Private header value. >>> >>> Kind regards=2C >>> >>> JL >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Friday=2C August 17=2C 2012 10:38 AM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> On 8/17/12 3:52 AM=2C Christer Holmberg wrote: >>>> Hi=2C >>>> >>>> I am saying that if the value has been verified=2C other entities with= in >>>> the trust domain don't need to perform the verification. And=2C using = a >>>> new value=2C those entities will also know that it is a PSAP callback. >>> >>> If you are working within a domain you can use whatever criteria you >>> want to decide whether to preserve or remove this header when it comes >>> across the boundary of the domain. If you want=2C the border elements c= an >>> only permit it from PSAPs. >>> >>> One it is inside the trust domain=2C it is what it is. If it's >>> Priority:emergency=2C then that's what it is. Something inside the trus= t >>> domain could have put it in. Or something on the boundary of the domain >>> might have a different policy to let it in from some class of users >>> other than PSAPs. >>> >>> My point is that it is an emergency call=2C which might have a high >>> probability of being an emergency callback from a PSAP. It isn't >>> definitively an emergency callback. And then there needs to be a set of >>> policies for how to handle emergency calls. That might include things >>> like calling barred numbers that you don't want just anybody to be able >>> to do. >>> >>> Of course this is just a philosophical difference from what you said. >>> >>> Thanks=2C >>> Paul >>> >>>> Regards=2C >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>> John-Luc Bakker [jbakker@rim.com] >>>> Sent: Thursday=2C August 16=2C 2012 6:22 PM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> Hi Christer=2C >>>> >>>> What you describe below is a trust domain applicable only to a >>>> particular header field's value=2C right? >>>> Are you saying only if the new value is present=2C the UA can derive >>>> that the header field value can be trusted as it must have been >>>> "subjected to verification" (any other value for that header field >>>> cannot be trusted)? >>>> >>>> I need to look deeper into trust domains=2C as I hadn't realized >>>> existing (legacy?) header fields could be subjected to trust domain=2C >>>> based on that header field's value. >>>> >>>> I was so far leaning towards Martin's and Paul's position=2C where the= y >>>> claim "emergency" is the right word. >>>> >>>> Regards=2C >>>> >>>> John-Luc >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Christer Holmberg >>>> Sent: Thursday=2C August 16=2C 2012 4:28 AM >>>> To: Martin Thomson=3B Paul Kyzivat >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> Hi=2C >>>> >>>> It is true that some entity in the network needs to verify the >>>> context=2C and that the call comes from a PSAP. But=2C once that is do= ne=2C >>>> other entities within the same network (trust domain) do not need to d= o >>>> that. >>>> >>>> So=2C for that reason I think a new value would be good. >>>> >>>> Regards=2C >>>> >>>> Christer >>>> >>>> ________________________________________ >>>> From: Martin Thomson [martin.thomson@gmail.com] >>>> Sent: Wednesday=2C August 15=2C 2012 7:36 PM >>>> To: Paul Kyzivat >>>> Cc: Christer Holmberg=3B ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> On 14 August 2012 14:19=2C Paul Kyzivat wrote: >>>>> As I said=2C I'm *ok* with a new value. >>>>> But it offends me to have to add a new value when we already have a >>>>> value "emergency" and this *is* an emergency. It sets a precedent >>>>> that nobody can use predefined values that weren't assigned for their >>>>> own specific case. Its another example of a philosophy that we need >>>>> to signal features or use cases rather than simply assemble basic >>>>> primitives to accomplish features. >>>> >>>> I'm with Paul on this one. These are just labels that have >>>> essentially arbitrary or context-specific semantics. This looks very >>>> much like a case where context is everything. >>>> >>>> "emergency" is the right word. The only concern is that it might have >>>> some other meaning. But those uses are specifically in some other >>>> context. This is a new context (probably based on identification of >>>> the PSAP=2C but that's simply an example). >>>> >>>> If context provides insufficient information to enable the sorts of >>>> decision that we want to enable=2C then a new label isn't going to fix >>>> that. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential >>>> information=2C privileged material (including material protected by th= e >>>> solicitor-client or other applicable privileges)=2C 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=2C please immediately reply to the sender and >>>> delete this information from your system. Use=2C dissemination=2C >>>> distribution=2C 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 >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential >>> information=2C privileged material (including material protected by the >>> solicitor-client or other applicable privileges)=2C or constitute >>> non-public information. Any use of this information by anyone other tha= n >>> the intended recipient is prohibited. If you have received this >>> transmission in error=2C please immediately reply to the sender and del= ete >>> this information from your system. Use=2C dissemination=2C distribution= =2C 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 From christer.holmberg@ericsson.com Tue Aug 21 09:16:42 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 5733121F8796 for ; Tue, 21 Aug 2012 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 RA34oQ37uNKd for ; Tue, 21 Aug 2012 09:16:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB721F875C for ; Tue, 21 Aug 2012 09:16:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-cb-5033b467ae7b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.CB.01197.764B3305; Tue, 21 Aug 2012 18:16:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 21 Aug 2012 18:16:39 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 21 Aug 2012 18:16:38 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/ov6JLEAf/kcySlOmltPOIM1EgQAFCKLd Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@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> In-Reply-To: <50339093.5080700@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+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvrW76FuMAg3vzzSwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRMuMcc8EN0YqzB+4xNTBOFuxi5OCQEDCR uLFJrouRE8gUk7hwbz1bFyMXh5DAKUaJvmPL2EESQgILGCV2z9YAqWcTsJDo/qcNYooIaEhM 2qoGUsEsoCpxrvExC4jNAmSv7rzCCGILC7hK3F86FWyKiICbxPOHp1ggbCOJtdMbwOK8AuES /2/tZIHYtIRNYvUUfxCbU0BH4u2FLWwgNiPQad9PrWGC2CUucevJfCaIkwUkluw5zwxhi0q8 fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYhTOTczMSS831EstykwuLs7P0ytO3cQIjJqDW37r7mA8dU7kEKM0B4uSOC9X0n5/IYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwiL3auXCLJFvRSZbardcnd691MAboqoQGl+lYKT7dn J/Tcj2hh2/xQ/rpa76tw3+ZghZT4jwWHhBzFP9s6z7l79fm522JX7PY+err5KbtrPvsuLtlZ V+oWveH0S6k6rs5uvtSV53kll3Pq+Sc3dCyyl2sfD0wJENBZJz7FXP+t6JHsK0uPXFZiKc5I NNRiLipOBAC7sydpaAIAAA== 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, 21 Aug 2012 16:16:42 -0000 Hi, >>>>>> I don't care much about this decision. >>>>>> >>>>>> I'd prefer a new one. My reason is that 3261 says: >>>>>> It is RECOMMENDED that the value of "emergency" only be used when li= fe, limb, or >>>>>> property are in imminent danger. >>>>> >>>>> Call backs don't necessarily have that implication. They might, but i= t also can be much less important. >>>>> >>>>> I think most implementors would view the emergency call as having pri= ority emergency, but not necessarily the call back. That's why I think it = would be better to create a new value. >>>> >>>> Well, if the callback is happening because the emergency call was inad= vertently disconnected, then it is still as much an emergency as it had bee= n. >>>> >>>> And I thought the psap could perform the "callback" without the priori= ty if it isn't called for. >>>> >>>> And, if it isn't a matter of life, limb, or property in danger, then I= guess the carrier would be entitled to honor barring. >>> >>> AFAIK, in countries where special treatment is given to PSAP callbacks,= it applies to *ALL* callbacks. Now, in such=20 >>> countries, whether some callbacks would be given different importance, = I don't know. But, it means that all callbacks have to be indicated as call= backs. >> >> So, if we think that there are cases where an PSAP would not indicate "e= mergency" for a PSAP callback, I really think we need a separate value. > > Do you mean that if I make an emergency call today, and then next week > the psap decides to call me back to take a survey about how nice they > were on the phone, that should still be treated as an emergency callback > that gets priority and can bypass barring??? Note that "callback" and "call back" are not necessarily the same thing :) If the call from PSAP is classified as a "PSAP callback", then it shall get= special treatment. If the call from the PSAP is just another "call back", then it would not ge= t special treatment. >Or if the operator in the PSAP calls to have pizza delivered for lunch >that should be treated as an emergency callback and work even if the >pizza place has had its calls barred? In that case it is not a "PSAP callback". >I presume not. Rather, doesn't it need to be on a call by call basis, >the psap will mark the calls that should be treated as emergency >callback calls? I am not saying that ALL calls from a PSAP shall be marked as "PSAP callbac= ks". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :) And, in the case the PSAP calls 911, e.g. because the building where the PS= AP is located is burning, that would not be marked as a "PSAP callback" eit= her. It would, however, be marked "emergency". Regards, Christer= From pkyzivat@alum.mit.edu Tue Aug 21 10:12: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 2C34421F86FA for ; Tue, 21 Aug 2012 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599] 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 lAAL8MivevkU for ; Tue, 21 Aug 2012 10:12:07 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id EEE4821F86DE for ; Tue, 21 Aug 2012 10:12:06 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id pMtA1j00M16LCl053VC9Al; Tue, 21 Aug 2012 17:12:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id pVBs1j00G3ZTu2S3SVBsKe; Tue, 21 Aug 2012 17:11:52 +0000 Message-ID: <5033C164.20807@alum.mit.edu> Date: Tue, 21 Aug 2012 13:12:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg 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> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> 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: Tue, 21 Aug 2012 17:12:08 -0000 On 8/21/12 12:16 PM, Christer Holmberg wrote: >> Do you mean that if I make an emergency call today, and then next week >> the psap decides to call me back to take a survey about how nice they >> were on the phone, that should still be treated as an emergency callback >> that gets priority and can bypass barring??? > > Note that "callback" and "call back" are not necessarily the same thing :) > > If the call from PSAP is classified as a "PSAP callback", then it shall get special treatment. > > If the call from the PSAP is just another "call back", then it would not get special treatment. > >> Or if the operator in the PSAP calls to have pizza delivered for lunch >> that should be treated as an emergency callback and work even if the >> pizza place has had its calls barred? > > In that case it is not a "PSAP callback". > >> I presume not. Rather, doesn't it need to be on a call by call basis, >> the psap will mark the calls that should be treated as emergency >> callback calls? > > I am not saying that ALL calls from a PSAP shall be marked as "PSAP callbacks". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :) OK. Unless somebody else chimes in, I guess this part is clear. And it would be true regardless of whether the marking is "Priority:psap-callback" or "Priority:emergency". Right? > And, in the case the PSAP calls 911, e.g. because the building where the PSAP is located is burning, that would not be marked as a "PSAP callback" either. It would, however, be marked "emergency". I guess this raises the question of whether the 911 call might contain Priority:emergency, and if so what that means. Superficially it seems reasonable that an emergency call (and presumably a 911 call qualifies) could, and perhaps SHOULD, contain Priority:emergency. And if so, does that imply the same semantics as the callback case? The distinction here is not about the priority of the call. It is about whether the priority is based on the status of the caller or the callee, if that matters. ISTM that the *call* is equally important regardless of the direction. For instance, in the unlikely event that the psap hasn't paid its phone bills and has been barred, the 911 call should still go through. Is it really necessary for the indication of the priority of the call to indicate which end the priority applies to??? I don't think so. But if so, then maybe we need: Priority: caller-emergency Priority: callee-emergency The notion of "emergency callback" is just an artifact. The prior emergency call is the way in which the psap has learned that the call being made is about an ongoing emergency at the callee. For instance - suppose I call 911 on my home phone and am talking to the psap. But then I have to move away from that phone. (The fire is getting too close to me.) But I have a cell phone. It would be good if the psap could call my phone and have it treated as an "emergency callback". (So even if my phone is barred it would work.) And this is better than me calling 911 again on my cell phone because even if it isn't barred I might not get the same psap or operator. Thanks Paul Thanks, Paul From christer.holmberg@ericsson.com Tue Aug 21 11:21:50 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 C0B0621F86E5 for ; Tue, 21 Aug 2012 11:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 p226kdmk3L7g for ; Tue, 21 Aug 2012 11:21:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 638B721F8687 for ; Tue, 21 Aug 2012 11:21:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-f2-5033d1a9be73 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D1.44.01197.9A1D3305; Tue, 21 Aug 2012 20:21:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 21 Aug 2012 20:21:28 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 21 Aug 2012 20:21:28 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/wBfYOuQrTs7dQySbcua5pUdY3wAB/FsX Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2ED0@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: <5033C164.20807@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+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre7Ki8YBBqf2Slg0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj5eHlTAUX5Cv2HVjC0sD4U6KLkZNDQsBE 4ue18ywQtpjEhXvr2boYuTiEBE4xSky9uZkdwlnAKNG6qBvI4eBgE7CQ6P6nDWKKCGhITNqq BtLLLKAqca7xMdgcFiB7zqkvYLawgKvE/aVT2UFsEQE3iecPT7FA2EYSW/euBYvzCoRLTFz2 nBVi1QR2iTMvn7CBJDgFtCSmd2wAK2IEOu77qTVMEMvEJW49mc8EcbSAxJI955khbFGJl4// sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgbFzcMtv3R2Mp86JHGKU5mBREuflStrvLySQnliS mp2aWpBaFF9UmpNafIiRiYNTqoHRccvs40vO35+k8aNiZQdvXXDKfNXJpVOORqTNl5/zPYex roIxSzel8ujUBTwSLQsZdr/5+mprqPQqg4KsL7l1dgJzFkflzLuseZvxofSizRMja9ZKcrVH HxJdN3X3pOKq+fK5br0V+XWHciyvvtWcsfHI7LYn3z4FLGuTdJtqI7u/4ZSgnuIqJZbijERD Leai4kQAm3gWgWsCAAA= 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, 21 Aug 2012 18:21:50 -0000 Hi, >>> Do you mean that if I make an emergency call today, and then next week >>> the psap decides to call me back to take a survey about how nice they >>> were on the phone, that should still be treated as an emergency callbac= k >>> that gets priority and can bypass barring??? >> >> Note that "callback" and "call back" are not necessarily the same thing = :) >> >> If the call from PSAP is classified as a "PSAP callback", then it shall = get special treatment. >> >> If the call from the PSAP is just another "call back", then it would not= get special treatment. >> >>> Or if the operator in the PSAP calls to have pizza delivered for lunch >>> that should be treated as an emergency callback and work even if the >>> pizza place has had its calls barred? >> >> In that case it is not a "PSAP callback". >> >>> I presume not. Rather, doesn't it need to be on a call by call basis, >>> the psap will mark the calls that should be treated as emergency >>> callback calls? >> >> I am not saying that ALL calls from a PSAP shall be marked as "PSAP call= backs". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :) > > OK. Unless somebody else chimes in, I guess this part is clear. > And it would be true regardless of whether the marking is > "Priority:psap-callback" or "Priority:emergency". Right? Well, it depends on whether the PSAP would use "Priority:emergency" for som= ething else than PSAP callback calls (see below). But, it would only use "P= riority-psap-callback" for PSAP callback calls. >> And, in the case the PSAP calls 911, e.g. because the building where the= PSAP is located is burning, that would not be marked as a "PSAP callback" = either. It would, however, be marked "emergency". > > I guess this raises the question of whether the 911 call might contain Pr= iority:emergency, and if so what that means. Ok, but my point was that if the PSAP makes an emergency call itself, it wo= uld not be marked as a PSAP callback call. It may still be marked (using wh= atever mechanism) as an emergency call, though. > Superficially it seems reasonable that an emergency call (and presumably > a 911 call qualifies) could, and perhaps SHOULD, contain > Priority:emergency. And if so, does that imply the same semantics as the > callback case? At least I think they are routed differently. An emergency call is routed t= owards a PSAP, while a callback call is routed towards the caller who made = the associated emergency call. > The distinction here is not about the priority of the call. It is about > whether the priority is based on the status of the caller or the callee, > if that matters. > > ISTM that the *call* is equally important regardless of the direction. > For instance, in the unlikely event that the psap hasn't paid its phone > bills and has been barred, the 911 call should still go through. > > Is it really necessary for the indication of the priority of the call to > indicate which end the priority applies to??? > > I don't think so. But if so, then maybe we need: > > Priority: caller-emergency > Priority: callee-emergency > > The notion of "emergency callback" is just an artifact. The prior > emergency call is the way in which the psap has learned that the call > being made is about an ongoing emergency at the callee. > > For instance - suppose I call 911 on my home phone and am talking to the > psap. But then I have to move away from that phone. (The fire is getting > too close to me.) But I have a cell phone. It would be good if the psap > could call my phone and have it treated as an "emergency callback". (So > even if my phone is barred it would work.) And this is better than me > calling 911 again on my cell phone because even if it isn't barred I > might not get the same psap or operator. Yes - and that is what PSAP callback is about :)=20 There is no such thing as "emergency callback". There are "emergency calls"= and "PSAP callbacks" :) Regards, Christer= From pkyzivat@alum.mit.edu Tue Aug 21 11:51:27 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 7FFA321F8678 for ; Tue, 21 Aug 2012 11:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 Lx+BSX2u6b9v for ; Tue, 21 Aug 2012 11:51:26 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BC21F86D6 for ; Tue, 21 Aug 2012 11:51:26 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id pVdv1j00216LCl058WrLXf; Tue, 21 Aug 2012 18:51:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id pWr21j00h3ZTu2S3SWr2b7; Tue, 21 Aug 2012 18:51:03 +0000 Message-ID: <5033D8A0.4040907@alum.mit.edu> Date: Tue, 21 Aug 2012 14:51:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg 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> <7F2072F1E0DE894DA4B517B93C6A05853409FF2ED0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2ED0@ESESSCMS0356.eemea.ericsson.se> 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: Tue, 21 Aug 2012 18:51:27 -0000 On 8/21/12 2:21 PM, Christer Holmberg wrote: > Hi, > >>>> Do you mean that if I make an emergency call today, and then next week >>>> the psap decides to call me back to take a survey about how nice they >>>> were on the phone, that should still be treated as an emergency callback >>>> that gets priority and can bypass barring??? >>> >>> Note that "callback" and "call back" are not necessarily the same thing :) >>> >>> If the call from PSAP is classified as a "PSAP callback", then it shall get special treatment. >>> >>> If the call from the PSAP is just another "call back", then it would not get special treatment. >>> >>>> Or if the operator in the PSAP calls to have pizza delivered for lunch >>>> that should be treated as an emergency callback and work even if the >>>> pizza place has had its calls barred? >>> >>> In that case it is not a "PSAP callback". >>> >>>> I presume not. Rather, doesn't it need to be on a call by call basis, >>>> the psap will mark the calls that should be treated as emergency >>>> callback calls? >>> >>> I am not saying that ALL calls from a PSAP shall be marked as "PSAP callbacks". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :) >> >> OK. Unless somebody else chimes in, I guess this part is clear. >> And it would be true regardless of whether the marking is >> "Priority:psap-callback" or "Priority:emergency". Right? > > Well, it depends on whether the PSAP would use "Priority:emergency" for something else than PSAP callback calls (see below). But, it would only use "Priority-psap-callback" for PSAP callback calls. My point was just that in the end it is a label. The label will trigger certain behavior, regardless of the name we choose for that. >>> And, in the case the PSAP calls 911, e.g. because the building where the PSAP is located is burning, that would not be marked as a "PSAP callback" either. It would, however, be marked "emergency". >> >> I guess this raises the question of whether the 911 call might contain Priority:emergency, and if so what that means. > > Ok, but my point was that if the PSAP makes an emergency call itself, it would not be marked as a PSAP callback call. It may still be marked (using whatever mechanism) as an emergency call, though. > >> Superficially it seems reasonable that an emergency call (and presumably >> a 911 call qualifies) could, and perhaps SHOULD, contain >> Priority:emergency. And if so, does that imply the same semantics as the >> callback case? > > At least I think they are routed differently. An emergency call is routed towards a PSAP, while a callback call is routed towards the caller who made the associated emergency call. The mechanism for emergency calls has been defined to work without use of the Priority header. The routing of the call is determined by the request URI containing urn:sos. The presence or absence of Priority:emergency wouldn't change that. And maybe the provider wouldn't allow the caller to put in Priority:emergency. But *if* the call *did* have Priority:emergency, and it wasn't stripped (because it was the psap calling 911) then presumably it would work the same as a psap-callback. >> The distinction here is not about the priority of the call. It is about >> whether the priority is based on the status of the caller or the callee, >> if that matters. >> >> ISTM that the *call* is equally important regardless of the direction. >> For instance, in the unlikely event that the psap hasn't paid its phone >> bills and has been barred, the 911 call should still go through. >> >> Is it really necessary for the indication of the priority of the call to >> indicate which end the priority applies to??? >> >> I don't think so. But if so, then maybe we need: >> >> Priority: caller-emergency >> Priority: callee-emergency >> >> The notion of "emergency callback" is just an artifact. The prior >> emergency call is the way in which the psap has learned that the call >> being made is about an ongoing emergency at the callee. >> >> For instance - suppose I call 911 on my home phone and am talking to the >> psap. But then I have to move away from that phone. (The fire is getting >> too close to me.) But I have a cell phone. It would be good if the psap >> could call my phone and have it treated as an "emergency callback". (So >> even if my phone is barred it would work.) And this is better than me >> calling 911 again on my cell phone because even if it isn't barred I >> might not get the same psap or operator. > > Yes - and that is what PSAP callback is about :) AFAIK the assumption has been that a "psap callback" is always in conjunction with a prior recent emergency call, and to the same device that initiated that call. What I described above is to a device that isn't the same one that made the emergency call, and not even to another device with the same AOR. Its really a fundamental conceptual difference, even if the same mechanisms support both. Its a change to a concept that the psap can mark a call (any call it makes) as deserving of this special treatment. > There is no such thing as "emergency callback". There are "emergency calls" and "PSAP callbacks" :) Or "calls indicating that the caller wants help with an emergency", and "calls indicating that the caller needs to talk to the callee about a callee emergency". Thanks, Paul > Regards, > > Christer > From martin.thomson@gmail.com Tue Aug 21 16:11:54 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 28BE711E8091 for ; Tue, 21 Aug 2012 16:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 8lVrlX1Q7VRj for ; Tue, 21 Aug 2012 16:11:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 628DC11E808D for ; Tue, 21 Aug 2012 16:11:53 -0700 (PDT) Received: by lahm15 with SMTP id m15so202243lah.31 for ; Tue, 21 Aug 2012 16:11:52 -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=LpICWjZ0O/D3AuoASRcQ4HqiIuTvIRwZu09CAKDYXK0=; b=t9KaSBR3wfR07EaSZXqHuLK/7IfEMSQUYHkeNYO21hlzXViF2tiUwFyRGg346FWBdP rfZyOJ2WLPVAeD1NTCol8k7EQy1wMxtn7Qas+CtGzjzgFx6U/WoYTtAosjwwAzMtTOYR isu3/ycs47e+xtj04IyNhVVz4AM4rYOcvE+qv5jl7OeDBr5ItrtrUYgH0zPahZXyJjei DuZP98N4gXPpsvUZVNqg4HJkwSeeXVS/TGdZZALMgKOEMiWsLy+vFJruO9Fsk89xxyud ZVtgJYSoxmUAWLXBZsn7v/tfiAhYLDQtxdZZlKM09Mqaf7BXau/Slvv5jDK3Vob0m8UX R+jg== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr19456513lab.11.1345590712262; Tue, 21 Aug 2012 16:11:52 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Tue, 21 Aug 2012 16:11:52 -0700 (PDT) In-Reply-To: <5033C164.20807@alum.mit.edu> 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> Date: Tue, 21 Aug 2012 16:11:52 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 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, 21 Aug 2012 23:11:54 -0000 On 21 August 2012 10:12, Paul Kyzivat wrote: > The distinction here is not about the priority of the call. It is about > whether the priority is based on the status of the caller or the callee, if > that matters. Whoa, we're at risk of over-rotating on this one. 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. --Martin From pkyzivat@alum.mit.edu Tue Aug 21 16:42:18 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 4031621F85AD for ; Tue, 21 Aug 2012 16:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 i0YYg2-EURTa for ; Tue, 21 Aug 2012 16:42:17 -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 93B1221F85A8 for ; Tue, 21 Aug 2012 16:42:17 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id pUv71j00B0ldTLk51biLFv; Tue, 21 Aug 2012 23:42:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id pbiB1j00J3ZTu2S3QbiB8L; Tue, 21 Aug 2012 23:42:11 +0000 Message-ID: <50341CD7.3040108@alum.mit.edu> Date: Tue, 21 Aug 2012 19:42:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Thomson 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: Content-Type: text/plain; charset=UTF-8; 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: Tue, 21 Aug 2012 23:42:18 -0000 Martin, In an earlier reply to christer I agreed with you, that the mechanism for emergency calls works just fine without using Priority. That overloads a lot of things, but a big part of it is that the decision of who the call is *to* is delegated to the network more than it usually is. On 8/21/12 7:11 PM, Martin Thomson wrote: > On 21 August 2012 10:12, Paul Kyzivat wrote: >> The distinction here is not about the priority of the call. It is about >> whether the priority is based on the status of the caller or the callee, if >> that matters. > > Whoa, we're at risk of over-rotating on this one. > > 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). It sounds like you are agreeing with me that a psap callback may not be "back" to a phone that made an emergency call. And maybe its not even "back" to a person who made an emergency call. Its just a call that the psap operator wants to receive special treatment. There may be policies about when this can be used, but that is different from building limitations into the mechanism. Thanks, Paul > 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. > > --Martin > From randy@qualcomm.com Thu Aug 30 11:57: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 A303E21F8575 for ; Thu, 30 Aug 2012 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.255 X-Spam-Level: X-Spam-Status: No, score=-106.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 ytIYH3frmhWD for ; Thu, 30 Aug 2012 11:57:01 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id DD02421F855D for ; Thu, 30 Aug 2012 11:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346353021; x=1377889021; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=jLQeJNEW3IRbzhO6+Fm2gQeV1GLLT4aCkjDKKLM9noA=; b=Be2E9M7/ksh295aQLKl1xKe5JJL0Buu9T8xeWEfO6d5BdtF+arJ4TCU9 o17kQpqQpE9cJEmuglM8rC6On9UyKiAbxOcWZ26Ky0pQhaHh4XNcAwZ3W Lt2A4qY6EhcCNBB6nAY17C/PWwwoTmA6T6PvO5E8UDWx+5RdRR7pdF6je A=; X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231310081" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 11:56:46 -0700 X-IronPort-AV: E=Sophos;i="4.80,342,1344236400"; d="scan'208";a="160919467" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 11:56:46 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 30 Aug 2012 11:56:46 -0700 Message-ID: In-Reply-To: References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> X-Mailer: Eudora for Mac OS X Date: Thu, 30 Aug 2012 11:52:08 -0700 To: "Rosen, Brian" , Matt Serra From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] comment field in additional-data 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, 30 Aug 2012 18:57:02 -0000 Would a comment in the service provider block and a comment in the PIDF be directed at different uses? Likely I'm misunderstanding one, the other, or both. I read Brian's note on adding a comment to the service provider block as a way for a service provider to add free-form information to, for example, the contact info for the service provider ("For non-emergency requests, call the listed administrative number and ask for Marge; if it's an emergency, call the listed mobile number"). A comment in the PIDF-LO would be a way to make a remark regarding the location. At 6:30 PM -0400 8/9/12, Brian Rosen wrote: > Well, I think we want entities other than an access network to be > able to use a comment, so the latter of your two answers is what I > would say. > > If there is a comment in additional-data, I don't think we need > another in PIDF. > > Brian > > On Aug 9, 2012, at 5:28 PM, Matt Serra wrote: > >> Brian - >> >> No objection, but a question: >> >> We mentioned possibly putting this field into the PIDF instead. >> Did we arrive on putting this into the Add'l Call Data to keep the >> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >> >> I suspect the driver is also based on whether the "Comment" is >> related to the address, or the provider/service as well. >> >> Thanks. >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, August 09, 2012 11:42 AM >> To: ecrit@ietf.org Org >> Subject: [Ecrit] comment field in additional-data >> >> Would there be any objection to adding a field in the service >> provider info block for a comment? >> I'm asking because we found a backwards compatibility issue in >> NENA, but I think it's generally useful. There are always a >> couple of things it may be helpful to tell the call taker (human). >> I'd put cautionary text in that suggests using an extension >> mechanism to pass actual data intended to be consumed by an >> automaton. This is just for free text to be displayed to a call >> taker or other PSAP staff. >> >> >> >> _______________________________________________ >> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Boling's postulate: If you're feeling good, don't worry. You'll get over it. From brian.rosen@neustar.biz Thu Aug 30 12:18:07 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 2027C21F84B8 for ; Thu, 30 Aug 2012 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_05=-1.11, 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 XCfGo7lAjc5J for ; Thu, 30 Aug 2012 12:18:06 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C739721F847A for ; Thu, 30 Aug 2012 12:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346354564; x=1661713256; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ZuZBaHnsAwMvT0OWIJeH4 zzZ+2vsyaeWrBs/bgfntJs=; b=MAAOd/wHvPNWcRLgbH2g1gssKf6coScHlIf9M ablFA6yKBTXC4z/wXSh+OurJI+b4Io4Hy6MqiTOjjmrFQfM8w== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13672299; Thu, 30 Aug 2012 15:22:43 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 30 Aug 2012 15:18:00 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Thu, 30 Aug 2012 15:17:58 -0400 Thread-Topic: Ids in LoST Thread-Index: Ac2G5CtiMZOhHH6pSGGYTflZ0sNHrg== Message-ID: 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: 9evJAzlZRZ82AFNs1KdKnQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Ids in LoST 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, 30 Aug 2012 19:18:07 -0000 In NENA, we're interested in being able to log queries on the LoST server, = and relate them to the call. There isn't any way to do that - the LoST ser= ver doesn't know the call id or incident id. Here is a specific use: We use a LoST server inside our Emergency Services IP network to route to t= he proper responders based on the location of the caller. The PSAP queries= using LoST and a special service URN to get the URI of the appropriate fir= e brigade that serves the location of the incident. The client (the PSAP) = and the LoST server both log the query and response, and if the query recur= s (because, for example, the call is answered out of area, and the local Lo= ST server isn't authoritative for the incident location), the recursion is = logged along the path by each step. If something goes wrong, we want to be able to search the logger for all ev= ents that occurred for a particular call or incident (we have two identifie= rs, since we can have multiple calls about the same incident). The problem= , of course, is while the PSAP knows the call and incident IDs, the LoST se= rvers don't. So when they log the query and response, they can't annotate = the log record appropriately. =20 Most emergency systems have stringent logging requirements like this. If the LoST server has to recursively query another LoST server, we have es= sentially the same problem - no way to relate the queries as we trace them = through the network. What would be helpful is to have an id passed in the query which is returne= d in the response, and also passed on in the recursive query (and thus pass= ed back in the recursive response). We would like the ID to be typed (that is, we need to know it's a NENA call= id), so what we are thinking of is an optional extension to LoST that pass= es and ID and an id type (which is listed in a registry). We would like to= be able to have more than one. The server is only asked to include it (or= them if it there are more than one of them) in the response, and in any re= cursive query. If this seems reasonable, I will write a draft. If IETF won't, NENA can al= ways do a private extension. Seems like a generally useful capability. Example 4547s8gs889 Brian From dmarnold@verizon.net Thu Aug 30 12:22: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 C351921F8616 for ; Thu, 30 Aug 2012 12:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 D-eHuw4FvVXQ for ; Thu, 30 Aug 2012 12:22:23 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9121F84B8 for ; Thu, 30 Aug 2012 12:22:23 -0700 (PDT) Received: from DelaineHP ([unknown] [173.166.111.177]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9L005NM1SI5QC0@vms173021.mailsrvcs.net> for ecrit@ietf.org; Thu, 30 Aug 2012 14:21:55 -0500 (CDT) From: "Delaine Arnold ENP" To: References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> In-reply-to: Date: Thu, 30 Aug 2012 15:21:53 -0400 Message-id: <01ca01cd86e4$b7310140$259303c0$@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGqfj/2guad5hBfGSkk+vQijZd56wK1ybZKApKt19gB12sxipd/zYTQ Content-language: en-us Subject: Re: [Ecrit] comment field in additional-data 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, 30 Aug 2012 19:22:25 -0000 PIDF-LO already has a LOC (Additional Location Information). Why won't = that work? Thank you, Delaine --------------------------------------- Delaine M. Arnold, ENP NENA Data Structures Sub-Committee Chair Voice:=A0 813-960-1698 Cell:=A0=A0=A0=A0 813-928-1692 Email:=A0 dmarnold@verizon.net -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Randall Gellens Sent: Thursday, August 30, 2012 2:52 PM To: Rosen, Brian; Matt Serra Cc: Rosen, Brian; ecrit@ietf.org Org Subject: Re: [Ecrit] comment field in additional-data Would a comment in the service provider block and a comment in the PIDF = be directed at different uses? Likely I'm misunderstanding one, the other, = or both. I read Brian's note on adding a comment to the service provider = block as a way for a service provider to add free-form information to, for example, the contact info for the service provider ("For non-emergency requests, call the listed administrative number and ask for Marge; if = it's an emergency, call the listed mobile number"). A comment in the PIDF-LO would be a way to make a remark regarding the location. At 6:30 PM -0400 8/9/12, Brian Rosen wrote: > Well, I think we want entities other than an access network to be=20 > able to use a comment, so the latter of your two answers is what I=20 > would say. > > If there is a comment in additional-data, I don't think we need=20 > another in PIDF. > > Brian > > On Aug 9, 2012, at 5:28 PM, Matt Serra wrote: > >> Brian - >> >> No objection, but a question: >> >> We mentioned possibly putting this field into the PIDF instead.=20 >> Did we arrive on putting this into the Add'l Call Data to keep the=20 >> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >> >> I suspect the driver is also based on whether the "Comment" is=20 >> related to the address, or the provider/service as well. >> >> Thanks. >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, August 09, 2012 11:42 AM >> To: ecrit@ietf.org Org >> Subject: [Ecrit] comment field in additional-data >> >> Would there be any objection to adding a field in the service=20 >> provider info block for a comment? >> I'm asking because we found a backwards compatibility issue in NENA, = >> but I think it's generally useful. There are always a couple of=20 >> things it may be helpful to tell the call taker (human). >> I'd put cautionary text in that suggests using an extension mechanism = >> to pass actual data intended to be consumed by an automaton. This is = >> just for free text to be displayed to a call taker or other PSAP=20 >> staff. >> >> >> >> _______________________________________________ >> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Boling's = postulate: If you're feeling good, don't worry. You'll get over it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Thu Aug 30 13:55:54 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 9CAA321F8570 for ; Thu, 30 Aug 2012 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.549 X-Spam-Level: X-Spam-Status: No, score=-107.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, 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 PxOhY+eMc3a1 for ; Thu, 30 Aug 2012 13:55:53 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 305C021F853C for ; Thu, 30 Aug 2012 13:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1346360153; x=1377896153; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; bh=Kn4IPmMyz3L1/+SGHqajGLlrOhHG2f7ltYoxEbbN2+A=; b=Yez5eY2oTiJ4gutq42H/+w6CoO5igv6uLDwdlelHMKNJDScQDslTdkGg ACsEcEeEdi7ru+4JcowDmHAxI4qIYV64aEHsBaAhjnfd+3guYOfp68+YD hisJe12CJqKxOOoftB9H/Uaw3OO2L3kdnnbXDlpm7km2HOV7fgW8a6++W U=; X-IronPort-AV: E=McAfee;i="5400,1158,6820"; a="231374231" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 30 Aug 2012 13:55:52 -0700 X-IronPort-AV: E=Sophos;i="4.80,342,1344236400"; d="scan'208";a="317628263" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Aug 2012 13:55:52 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 30 Aug 2012 13:55:51 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 30 Aug 2012 13:53:41 -0700 To: "Rosen, Brian" , "ecrit@ietf.org Org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] Ids in LoST 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, 30 Aug 2012 20:55:54 -0000 At 3:17 PM -0400 8/30/12, Brian Rosen wrote: > What would be helpful is to have an id passed in the query which is > returned in the response, and also passed on in the recursive query > (and thus passed back in the recursive response). > > We would like the ID to be typed (that is, we need to know it's a > NENA call id), so what we are thinking of is an optional extension > to LoST that passes and ID and an id type (which is listed in a > registry). We would like to be able to have more than one. The > server is only asked to include it (or them if it there are more > than one of them) in the response, and in any recursive query. > > If this seems reasonable, I will write a draft. This seems both generally useful and harmless. Useful for the specific case Brian described, but also because in general it's useful to be able to pass strings around that are only for logging (e.g., trace fields in SMTP message format). Harmless because it's an optional field that doesn't alter the protocol and doesn't affect behavior. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have made this letter longer than usual because I lack the time to make it shorter. --Blaise Pascal From mserra@ravemobilesafety.com Thu Aug 30 14:31:40 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 63B4A21F8530 for ; Thu, 30 Aug 2012 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 YfS55vHo2wwB for ; Thu, 30 Aug 2012 14:31:39 -0700 (PDT) Received: from server505.appriver.com (server505h.appriver.com [98.129.35.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAEB21F851B for ; Thu, 30 Aug 2012 14:31:38 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/30/2012 4:31:37 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G285 G286 G287 G288 G292 G293 G304 G395 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 248532527; Thu, 30 Aug 2012 16:31:37 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.137]) by HT08-E5.exg5.exghost.com ([98.129.23.244]) with mapi; Thu, 30 Aug 2012 16:31:31 -0500 From: Matt Serra To: Randall Gellens , "Rosen, Brian" Date: Thu, 30 Aug 2012 16:31:25 -0500 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac2G4UeeRwgI+comTCCXKmAblN8KGwAFF3Fg Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA109D6DD5F02@MBX05.exg5.exghost.com> References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] comment field in additional-data 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, 30 Aug 2012 21:31:40 -0000 I'll respond, as I think I'm responsible for the confusion. Brian proposes that this new "Comment" field appear ONLY within the Additio= nal-Data Service Provider Block and NOT within the PIDF. This way, anyone = can populate the "Comment" field. If it were in the PIDF, only access netw= orks could populate the new "Comment" field. I think this field should only be used to provide incremental comments abou= t the Service Provider, or the Services Provided, and NOT about the locatio= n. It would be better to carry information about the location in a separat= e Call-Info header having the Purpose parameter set to 'emergencyLocationDa= ta' (at least this is what is documented in the NENA i3 specification). Matt. -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: Thursday, August 30, 2012 2:52 PM To: Rosen, Brian; Matt Serra Cc: Rosen, Brian; ecrit@ietf.org Org Subject: Re: [Ecrit] comment field in additional-data Would a comment in the service provider block and a comment in the PIDF be = directed at different uses? Likely I'm misunderstanding one, the other, or = both. I read Brian's note on adding a comment to the service provider bloc= k as a way for a service provider to add free-form information to, for exam= ple, the contact info for the service provider ("For non-emergency requests= , call the listed administrative number and ask for Marge; if it's an emerg= ency, call the listed mobile number"). A comment in the PIDF-LO would be a= way to make a remark regarding the location. At 6:30 PM -0400 8/9/12, Brian Rosen wrote: > Well, I think we want entities other than an access network to be=20 > able to use a comment, so the latter of your two answers is what I=20 > would say. > > If there is a comment in additional-data, I don't think we need=20 > another in PIDF. > > Brian > > On Aug 9, 2012, at 5:28 PM, Matt Serra wro= te: > >> Brian - >> >> No objection, but a question: >> >> We mentioned possibly putting this field into the PIDF instead.=20 >> Did we arrive on putting this into the Add'l Call Data to keep the=20 >> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >> >> I suspect the driver is also based on whether the "Comment" is=20 >> related to the address, or the provider/service as well. >> >> Thanks. >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Thursday, August 09, 2012 11:42 AM >> To: ecrit@ietf.org Org >> Subject: [Ecrit] comment field in additional-data >> >> Would there be any objection to adding a field in the service=20 >> provider info block for a comment? >> I'm asking because we found a backwards compatibility issue in NENA,=20 >> but I think it's generally useful. There are always a couple of=20 >> things it may be helpful to tell the call taker (human). >> I'd put cautionary text in that suggests using an extension mechanism=20 >> to pass actual data intended to be consumed by an automaton. This is=20 >> just for free text to be displayed to a call taker or other PSAP=20 >> staff. >> >> >> >> _______________________________________________ >> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Boling's postulate: If you're feeling good, don't worry. You'll get over it. From brian.rosen@neustar.biz Thu Aug 30 15:19: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 CA7C321F8513 for ; Thu, 30 Aug 2012 15:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 bZZs69rC2UHJ for ; Thu, 30 Aug 2012 15:19:37 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AA33821F8510 for ; Thu, 30 Aug 2012 15:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346365101; x=1661719642; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=VC3Kp+ZhNQOMg+Nj2mvIS nzYxDHxJgNztEdJLCshEyw=; b=FJJ/3B4Zb7OJIDT3DgQ9a7sJ/F5UoCK4vXm0k e7RAxohbGY8iL2X4Y32bdiKRfr1e5hBZC9AzRs117uoIOWo0A== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8807442; Thu, 30 Aug 2012 18:18:20 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 30 Aug 2012 18:19:34 -0400 From: "Rosen, Brian" To: Matt Serra Date: Thu, 30 Aug 2012 18:19:33 -0400 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac2G/Yg3EJwzj5fXTFmPUt01W9LJbA== Message-ID: <7F34CC81-ED06-412F-BF46-52B30567B44E@neustar.biz> References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> <6B92B1E73D1E7B468E5C97CAE569CBA109D6DD5F02@MBX05.exg5.exghost.com> In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA109D6DD5F02@MBX05.exg5.exghost.com> 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: x9yZ7DA2Je1l/igvHJHvLQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randall Gellens , "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] comment field in additional-data 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, 30 Aug 2012 22:19:37 -0000 Please let's not get additional location data confused with this. The request is for free text from a service provider in the path of an emer= gency call, or in the case of a PIDF, the author of a PIDF. =20 "Additional Location Data" is defined by NENA as information specific to a = location (not a PIDF, but the location the PIDF represents). It has things= like floor plans, tenant/building owner contact data, elevator status, .. = It probably could use a comment field, but it's an entirely separate data = structure, not defined in this document. Brian On Aug 30, 2012, at 5:31 PM, Matt Serra wrote= : > I'll respond, as I think I'm responsible for the confusion. >=20 > Brian proposes that this new "Comment" field appear ONLY within the Addit= ional-Data Service Provider Block and NOT within the PIDF. This way, anyon= e can populate the "Comment" field. If it were in the PIDF, only access ne= tworks could populate the new "Comment" field. >=20 > I think this field should only be used to provide incremental comments ab= out the Service Provider, or the Services Provided, and NOT about the locat= ion. It would be better to carry information about the location in a separ= ate Call-Info header having the Purpose parameter set to 'emergencyLocation= Data' (at least this is what is documented in the NENA i3 specification). >=20 > Matt. >=20 >=20 > -----Original Message----- > From: Randall Gellens [mailto:randy@qualcomm.com]=20 > Sent: Thursday, August 30, 2012 2:52 PM > To: Rosen, Brian; Matt Serra > Cc: Rosen, Brian; ecrit@ietf.org Org > Subject: Re: [Ecrit] comment field in additional-data >=20 > Would a comment in the service provider block and a comment in the PIDF b= e directed at different uses? Likely I'm misunderstanding one, the other, o= r both. I read Brian's note on adding a comment to the service provider bl= ock as a way for a service provider to add free-form information to, for ex= ample, the contact info for the service provider ("For non-emergency reques= ts, call the listed administrative number and ask for Marge; if it's an eme= rgency, call the listed mobile number"). A comment in the PIDF-LO would be= a way to make a remark regarding the location. >=20 > At 6:30 PM -0400 8/9/12, Brian Rosen wrote: >=20 >> Well, I think we want entities other than an access network to be=20 >> able to use a comment, so the latter of your two answers is what I=20 >> would say. >>=20 >> If there is a comment in additional-data, I don't think we need=20 >> another in PIDF. >>=20 >> Brian >>=20 >> On Aug 9, 2012, at 5:28 PM, Matt Serra wro= te: >>=20 >>> Brian - >>>=20 >>> No objection, but a question: >>>=20 >>> We mentioned possibly putting this field into the PIDF instead.=20 >>> Did we arrive on putting this into the Add'l Call Data to keep the=20 >>> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >>>=20 >>> I suspect the driver is also based on whether the "Comment" is=20 >>> related to the address, or the provider/service as well. >>>=20 >>> Thanks. >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Thursday, August 09, 2012 11:42 AM >>> To: ecrit@ietf.org Org >>> Subject: [Ecrit] comment field in additional-data >>>=20 >>> Would there be any objection to adding a field in the service=20 >>> provider info block for a comment? >>> I'm asking because we found a backwards compatibility issue in NENA,=20 >>> but I think it's generally useful. There are always a couple of=20 >>> things it may be helpful to tell the call taker (human). >>> I'd put cautionary text in that suggests using an extension mechanism=20 >>> to pass actual data intended to be consumed by an automaton. This is=20 >>> just for free text to be displayed to a call taker or other PSAP=20 >>> staff. >>>=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 >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Boling's postulate: > If you're feeling good, don't worry. You'll get over it. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Thu Aug 30 16:23:53 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 61AE821F8518 for ; Thu, 30 Aug 2012 16:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] 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 UqG-BIy3Ad-K for ; Thu, 30 Aug 2012 16:23:52 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id B93BF21F8513 for ; Thu, 30 Aug 2012 16:23:52 -0700 (PDT) X-AuditID: 0a0404e8-b7c1dae0000009ce-fa-503ff60e6a9f Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 57.D8.02510.E06FF305; Thu, 30 Aug 2012 18:23:58 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 30 Aug 2012 18:23:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 31 Aug 2012 07:23:48 +0800 From: "Winterbottom, James" To: "Rosen, Brian" , "ecrit@ietf.org Org" Date: Fri, 31 Aug 2012 07:23:45 +0800 Thread-Topic: Ids in LoST Thread-Index: Ac2G5CtiMZOhHH6pSGGYTflZ0sNHrgAIhRqg Message-ID: <5A55A45AE77F5941B18E5457ECAC818801212C255279@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAxlX8ksbsmdMG7ONbQ== Subject: Re: [Ecrit] Ids in LoST 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, 30 Aug 2012 23:23:53 -0000 I understand why it is wanted. I agree that it is probably useful once you = are inside the ESInet, but I understood the current charter to be limited t= o getting us to the ESInet. I think that this kind of extension would be better done inside NENA. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= osen, Brian Sent: Friday, 31 August 2012 5:18 AM To: ecrit@ietf.org Org Subject: [Ecrit] Ids in LoST In NENA, we're interested in being able to log queries on the LoST server, = and relate them to the call. There isn't any way to do that - the LoST ser= ver doesn't know the call id or incident id. Here is a specific use: We use a LoST server inside our Emergency Services IP network to route to t= he proper responders based on the location of the caller. The PSAP queries= using LoST and a special service URN to get the URI of the appropriate fir= e brigade that serves the location of the incident. The client (the PSAP) = and the LoST server both log the query and response, and if the query recur= s (because, for example, the call is answered out of area, and the local Lo= ST server isn't authoritative for the incident location), the recursion is = logged along the path by each step. If something goes wrong, we want to be able to search the logger for all ev= ents that occurred for a particular call or incident (we have two identifie= rs, since we can have multiple calls about the same incident). The problem= , of course, is while the PSAP knows the call and incident IDs, the LoST se= rvers don't. So when they log the query and response, they can't annotate = the log record appropriately. =20 Most emergency systems have stringent logging requirements like this. If the LoST server has to recursively query another LoST server, we have es= sentially the same problem - no way to relate the queries as we trace them = through the network. What would be helpful is to have an id passed in the query which is returne= d in the response, and also passed on in the recursive query (and thus pass= ed back in the recursive response). We would like the ID to be typed (that is, we need to know it's a NENA call= id), so what we are thinking of is an optional extension to LoST that pass= es and ID and an id type (which is listed in a registry). We would like to= be able to have more than one. The server is only asked to include it (or= them if it there are more than one of them) in the response, and in any re= cursive query. If this seems reasonable, I will write a draft. If IETF won't, NENA can al= ways do a private extension. Seems like a generally useful capability. Example 4547s8gs889 Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From dmarnold@verizon.net Thu Aug 30 18:53: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 C963721F84DA for ; Thu, 30 Aug 2012 18:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 0k1noaMybEgT for ; Thu, 30 Aug 2012 18:53:16 -0700 (PDT) Received: from vms173021pub.verizon.net (vms173021pub.verizon.net [206.46.173.21]) by ietfa.amsl.com (Postfix) with ESMTP id E296D21F84F3 for ; Thu, 30 Aug 2012 18:53:12 -0700 (PDT) Received: from vznit170078pub.verizon.net ([unknown] [192.168.1.3]) by vms173021.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9L006M7JW2KEDW@vms173021.mailsrvcs.net> for ecrit@ietf.org; Thu, 30 Aug 2012 20:52:50 -0500 (CDT) Received: from 24.91.92.159 ([24.91.92.159]) by vznit170078 (Verizon Webmail) with HTTP; Thu, 30 Aug 2012 20:52:50 -0500 (CDT) Date: Thu, 30 Aug 2012 20:52:50 -0500 (CDT) From: Delaine Arnold-ENP To: Brian.Rosen@neustar.biz Message-id: <1849658175.387136.1346377970094.JavaMail.root@vznit170078> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Originating-IP: [24.91.92.159] Cc: randy@qualcomm.com, Brian.Rosen@neustar.biz, mserra@ravemobilesafety.com, ecrit@ietf.org Subject: Re: [Ecrit] comment field in additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dmarnold@verizon.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 01:53:16 -0000 Brian, PIDF-LO has a field with a tag of LOC. There is also Additional Data Associated with a Location. These are 2 separate things. I thought LOC was for the SP to use to populate anything they wanted, while Additional Data Associated with a Location is just what you indicated - floor plans, or any specific details about the location being responded to. Since SPs/devices create PIDF-LO, why can't these additional comments from the SP be in the LOC data element? Thank you, Delaine --------------------------------------- Delaine M. Arnold Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net Aug 30, 2012 06:19:54 PM, Brian.Rosen@neustar.biz wrote: =========================================== Please let's not get additional location data confused with this. The request is for free text from a service provider in the path of an emergency call, or in the case of a PIDF, the author of a PIDF. "Additional Location Data" is defined by NENA as information specific to a location (not a PIDF, but the location the PIDF represents). It has things like floor plans, tenant/building owner contact data, elevator status, .. It probably could use a comment field, but it's an entirely separate data structure, not defined in this document. Brian On Aug 30, 2012, at 5:31 PM, Matt Serra wrote: > I'll respond, as I think I'm responsible for the confusion. > > Brian proposes that this new "Comment" field appear ONLY within the Additional-Data Service Provider Block and NOT within the PIDF. This way, anyone can populate the "Comment" field. If it were in the PIDF, only access networks could populate the new "Comment" field. > > I think this field should only be used to provide incremental comments about the Service Provider, or the Services Provided, and NOT about the location. It would be better to carry information about the location in a separate Call-Info header having the Purpose parameter set to 'emergencyLocationData' (at least this is what is documented in the NENA i3 specification). > > Matt. > > > -----Original Message----- > From: Randall Gellens [mailto:randy@qualcomm.com] > Sent: Thursday, August 30, 2012 2:52 PM > To: Rosen, Brian; Matt Serra > Cc: Rosen, Brian; ecrit@ietf.org Org > Subject: Re: [Ecrit] comment field in additional-data > > Would a comment in the service provider block and a comment in the PIDF be directed at different uses? Likely I'm misunderstanding one, the other, or both. I read Brian's note on adding a comment to the service provider block as a way for a service provider to add free-form information to, for example, the contact info for the service provider ("For non-emergency requests, call the listed administrative number and ask for Marge; if it's an emergency, call the listed mobile number"). A comment in the PIDF-LO would be a way to make a remark regarding the location. > > At 6:30 PM -0400 8/9/12, Brian Rosen wrote: > >> Well, I think we want entities other than an access network to be >> able to use a comment, so the latter of your two answers is what I >> would say. >> >> If there is a comment in additional-data, I don't think we need >> another in PIDF. >> >> Brian >> >> On Aug 9, 2012, at 5:28 PM, Matt Serra wrote: >> >>> Brian - >>> >>> No objection, but a question: >>> >>> We mentioned possibly putting this field into the PIDF instead. >>> Did we arrive on putting this into the Add'l Call Data to keep the >>> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >>> >>> I suspect the driver is also based on whether the "Comment" is >>> related to the address, or the provider/service as well. >>> >>> Thanks. >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Thursday, August 09, 2012 11:42 AM >>> To: ecrit@ietf.org Org >>> Subject: [Ecrit] comment field in additional-data >>> >>> Would there be any objection to adding a field in the service >>> provider info block for a comment? >>> I'm asking because we found a backwards compatibility issue in NENA, >>> but I think it's generally useful. There are always a couple of >>> things it may be helpful to tell the call taker (human). >>> I'd put cautionary text in that suggests using an extension mechanism >>> to pass actual data intended to be consumed by an automaton. This is >>> just for free text to be displayed to a call taker or other PSAP >>> staff. >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Boling's postulate: > If you're feeling good, don't worry. You'll get over it. > _______________________________________________ > 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 mserra@ravemobilesafety.com Thu Aug 30 18:59:50 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 3E68621F84F1 for ; Thu, 30 Aug 2012 18:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 0dJB9haZm6MW for ; Thu, 30 Aug 2012 18:59:49 -0700 (PDT) Received: from server505.appriver.com (server505g.appriver.com [98.129.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6201921F84DD for ; Thu, 30 Aug 2012 18:59:48 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/30/2012 8:59:48 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G285 G286 G287 G288 G292 G293 G304 G395 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 316739637; Thu, 30 Aug 2012 20:59:48 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.137]) by HT07.exg5.exghost.com ([98.129.23.207]) with mapi; Thu, 30 Aug 2012 20:59:47 -0500 From: Matt Serra To: "Rosen, Brian" Date: Thu, 30 Aug 2012 20:59:43 -0500 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac2HHEvXw2Z3LkCgTwWrANhIsgBFqw== Message-ID: <7B651231-84E6-4585-9A96-DAFDCC232DA5@ravemobilesafety.com> References: <6B92B1E73D1E7B468E5C97CAE569CBA108DE0399E6@MBX05.exg5.exghost.com> <6B92B1E73D1E7B468E5C97CAE569CBA109D6DD5F02@MBX05.exg5.exghost.com> <7F34CC81-ED06-412F-BF46-52B30567B44E@neustar.biz> In-Reply-To: <7F34CC81-ED06-412F-BF46-52B30567B44E@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 Cc: Randall Gellens , "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] comment field in additional-data 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, 31 Aug 2012 01:59:50 -0000 Agreed. I was trying to address Randall's remark about using a comment in = the PIDF to "to make a remark regarding location" - which is best left to B= rian's definition of Additional Location Data.=20 On Aug 30, 2012, at 6:19 PM, "Rosen, Brian" wrote= : > Please let's not get additional location data confused with this. >=20 > The request is for free text from a service provider in the path of an em= ergency call, or in the case of a PIDF, the author of a PIDF. =20 >=20 > "Additional Location Data" is defined by NENA as information specific to = a location (not a PIDF, but the location the PIDF represents). It has thin= gs like floor plans, tenant/building owner contact data, elevator status, .= . It probably could use a comment field, but it's an entirely separate dat= a structure, not defined in this document. >=20 > Brian >=20 > On Aug 30, 2012, at 5:31 PM, Matt Serra wro= te: >=20 >> I'll respond, as I think I'm responsible for the confusion. >>=20 >> Brian proposes that this new "Comment" field appear ONLY within the Addi= tional-Data Service Provider Block and NOT within the PIDF. This way, anyo= ne can populate the "Comment" field. If it were in the PIDF, only access n= etworks could populate the new "Comment" field. >>=20 >> I think this field should only be used to provide incremental comments a= bout the Service Provider, or the Services Provided, and NOT about the loca= tion. It would be better to carry information about the location in a sepa= rate Call-Info header having the Purpose parameter set to 'emergencyLocatio= nData' (at least this is what is documented in the NENA i3 specification). >>=20 >> Matt. >>=20 >>=20 >> -----Original Message----- >> From: Randall Gellens [mailto:randy@qualcomm.com]=20 >> Sent: Thursday, August 30, 2012 2:52 PM >> To: Rosen, Brian; Matt Serra >> Cc: Rosen, Brian; ecrit@ietf.org Org >> Subject: Re: [Ecrit] comment field in additional-data >>=20 >> Would a comment in the service provider block and a comment in the PIDF = be directed at different uses? Likely I'm misunderstanding one, the other, = or both. I read Brian's note on adding a comment to the service provider b= lock as a way for a service provider to add free-form information to, for e= xample, the contact info for the service provider ("For non-emergency reque= sts, call the listed administrative number and ask for Marge; if it's an em= ergency, call the listed mobile number"). A comment in the PIDF-LO would b= e a way to make a remark regarding the location. >>=20 >> At 6:30 PM -0400 8/9/12, Brian Rosen wrote: >>=20 >>> Well, I think we want entities other than an access network to be=20 >>> able to use a comment, so the latter of your two answers is what I=20 >>> would say. >>>=20 >>> If there is a comment in additional-data, I don't think we need=20 >>> another in PIDF. >>>=20 >>> Brian >>>=20 >>> On Aug 9, 2012, at 5:28 PM, Matt Serra wr= ote: >>>=20 >>>> Brian - >>>>=20 >>>> No objection, but a question: >>>>=20 >>>> We mentioned possibly putting this field into the PIDF instead.=20 >>>> Did we arrive on putting this into the Add'l Call Data to keep the=20 >>>> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >>>>=20 >>>> I suspect the driver is also based on whether the "Comment" is=20 >>>> related to the address, or the provider/service as well. >>>>=20 >>>> Thanks. >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Thursday, August 09, 2012 11:42 AM >>>> To: ecrit@ietf.org Org >>>> Subject: [Ecrit] comment field in additional-data >>>>=20 >>>> Would there be any objection to adding a field in the service=20 >>>> provider info block for a comment? >>>> I'm asking because we found a backwards compatibility issue in NENA,=20 >>>> but I think it's generally useful. There are always a couple of=20 >>>> things it may be helpful to tell the call taker (human). >>>> I'd put cautionary text in that suggests using an extension mechanism= =20 >>>> to pass actual data intended to be consumed by an automaton. This is= =20 >>>> just for free text to be displayed to a call taker or other PSAP=20 >>>> staff. >>>>=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 >>=20 >>=20 >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- Boling's postulate= : >> If you're feeling good, don't worry. You'll get over it. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From James.Winterbottom@commscope.com Thu Aug 30 19:05:17 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 AFB5E21F84F3 for ; Thu, 30 Aug 2012 19:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 GqrHR+cwHOCm for ; Thu, 30 Aug 2012 19:05:16 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0821F84F1 for ; Thu, 30 Aug 2012 19:05:13 -0700 (PDT) X-AuditID: 0a0404e8-b7c1dae0000009ce-26-50401bdfa910 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 19.2B.02510.FDB10405; Thu, 30 Aug 2012 21:05:19 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 30 Aug 2012 21:05:12 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 31 Aug 2012 10:05:09 +0800 From: "Winterbottom, James" To: "dmarnold@verizon.net" , "Brian.Rosen@neustar.biz" Date: Fri, 31 Aug 2012 10:05:07 +0800 Thread-Topic: [Ecrit] comment field in additional-data Thread-Index: Ac2HG2vI6iTKbJu8RluDlpaTc3zjJQAAXiSA Message-ID: <5A55A45AE77F5941B18E5457ECAC818801212C2552BA@SISPE7MB1.commscope.com> References: <1849658175.387136.1346377970094.JavaMail.root@vznit170078> In-Reply-To: <1849658175.387136.1346377970094.JavaMail.root@vznit170078> 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: AAAAAhlX8ksbs41t Cc: "randy@qualcomm.com" , "mserra@ravemobilesafety.com" , "ecrit@ietf.org" Subject: Re: [Ecrit] comment field in additional-data 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, 31 Aug 2012 02:05:17 -0000 Delaine, What if I want to include the extra information that Brian is talking about= but the location itself is geodetic? If the information is not specifically location information then it doesn't= belong in the civic or geodetic data set. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= elaine Arnold-ENP Sent: Friday, 31 August 2012 11:53 AM To: Brian.Rosen@neustar.biz Cc: randy@qualcomm.com; Brian.Rosen@neustar.biz; mserra@ravemobilesafety.co= m; ecrit@ietf.org Subject: Re: [Ecrit] comment field in additional-data Brian, PIDF-LO has a field with a tag of LOC. There is also Additional Data Assoc= iated with a Location. These are 2 separate things. I thought LOC was for the SP to use to populate anything they wanted, while= Additional Data Associated with a Location is just what you indicated - fl= oor plans, or any specific details about the location being responded to. Since SPs/devices create PIDF-LO, why can't these additional comments from = the SP be in the LOC data element? Thank you, Delaine --------------------------------------- Delaine M. Arnold Voice: 813-960-1698 Cell: 813-928-1692 Email: dmarnold@verizon.net Aug 30, 2012 06:19:54 PM, Brian.Rosen@neustar.biz wrote: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please let's not get additional location data confused with this. The request is for free text from a service provider in the path of an emer= gency call, or in the case of a PIDF, the author of a PIDF. =20 "Additional Location Data" is defined by NENA as information specific to a = location (not a PIDF, but the location the PIDF represents). It has things= like floor plans, tenant/building owner contact data, elevator status, .. = It probably could use a comment field, but it's an entirely separate data = structure, not defined in this document. Brian On Aug 30, 2012, at 5:31 PM, Matt Serra wrote: > I'll respond, as I think I'm responsible for the confusion. >=20 > Brian proposes that this new "Comment" field appear ONLY within the Addit= ional-Data Service Provider Block and NOT within the PIDF. This way, anyon= e can populate the "Comment" field. If it were in the PIDF, only access ne= tworks could populate the new "Comment" field. >=20 > I think this field should only be used to provide incremental comments ab= out the Service Provider, or the Services Provided, and NOT about the locat= ion. It would be better to carry information about the location in a separ= ate Call-Info header having the Purpose parameter set to 'emergencyLocation= Data' (at least this is what is documented in the NENA i3 specification). >=20 > Matt. >=20 >=20 > -----Original Message----- > From: Randall Gellens [mailto:randy@qualcomm.com] > Sent: Thursday, August 30, 2012 2:52 PM > To: Rosen, Brian; Matt Serra > Cc: Rosen, Brian; ecrit@ietf.org Org > Subject: Re: [Ecrit] comment field in additional-data >=20 > Would a comment in the service provider block and a comment in the PIDF b= e directed at different uses? Likely I'm misunderstanding one, the other, o= r both. I read Brian's note on adding a comment to the service provider bl= ock as a way for a service provider to add free-form information to, for ex= ample, the contact info for the service provider ("For non-emergency reques= ts, call the listed administrative number and ask for Marge; if it's an eme= rgency, call the listed mobile number"). A comment in the PIDF-LO would be= a way to make a remark regarding the location. >=20 > At 6:30 PM -0400 8/9/12, Brian Rosen wrote: >=20 >> Well, I think we want entities other than an access network to be=20 >> able to use a comment, so the latter of your two answers is what I=20 >> would say. >>=20 >> If there is a comment in additional-data, I don't think we need=20 >> another in PIDF. >>=20 >> Brian >>=20 >> On Aug 9, 2012, at 5:28 PM, Matt Serra wrote: >>=20 >>> Brian - >>>=20 >>> No objection, but a question: >>>=20 >>> We mentioned possibly putting this field into the PIDF instead.=20 >>> Did we arrive on putting this into the Add'l Call Data to keep the=20 >>> PIDF "clean" assuming it has no alternate use outside of 9-1-1? >>>=20 >>> I suspect the driver is also based on whether the "Comment" is=20 >>> related to the address, or the provider/service as well. >>>=20 >>> Thanks. >>>=20 >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Thursday, August 09, 2012 11:42 AM >>> To: ecrit@ietf.org Org >>> Subject: [Ecrit] comment field in additional-data >>>=20 >>> Would there be any objection to adding a field in the service=20 >>> provider info block for a comment? >>> I'm asking because we found a backwards compatibility issue in NENA,=20 >>> but I think it's generally useful. There are always a couple of=20 >>> things it may be helpful to tell the call taker (human). >>> I'd put cautionary text in that suggests using an extension=20 >>> mechanism to pass actual data intended to be consumed by an=20 >>> automaton. This is just for free text to be displayed to a call=20 >>> taker or other PSAP staff. >>>=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 >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Boling's postulate: > If you're feeling good, don't worry. You'll get over it. > _______________________________________________ > 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