From randy@qti.qualcomm.com Thu Aug 1 00:40:53 2013 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 9623921F9D44 for ; Thu, 1 Aug 2013 00:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tu+2IWpd8eG for ; Thu, 1 Aug 2013 00:40:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B85CC21F9CF3 for ; Thu, 1 Aug 2013 00:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1375342843; x=1406878843; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=WiknO1qLqKi9w89DbQfhtrX4LcvWVbn8givfvXVe8ro=; b=DkJmXJNXxR3sZV5KAdPuGFNLQIJBNHImECn3R2S95nQq8KHb+rO/oRxo koLQC/NYoxqXGo0nqWJYY6mljol13+O0LUdoPz4/fUjes7rc3R4luEWYO igueo5w+UT6G/S9z0JfynGRdEO83R/oqjo0OEmzoEmYd6jMEmnFKkkIbM g=; X-IronPort-AV: E=Sophos;i="4.89,792,1367996400"; d="scan'208";a="48605498" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 01 Aug 2013 00:40:43 -0700 X-IronPort-AV: E=Sophos;i="4.89,792,1367996400"; d="scan'208";a="577263457" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Aug 2013 00:40:43 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 00:40:42 -0700 Received: from [10.35.200.44] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 00:40:41 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Aug 2013 00:40:37 -0700 To: Roger Marshall , "ecrit@ietf.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.48.1] Cc: "Randall Gellens \(randy@qti.qualcomm.com\)" , "A. Jean Mahoney \(mahoney@nostrum.com\)" Subject: Re: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting 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, 01 Aug 2013 07:40:53 -0000 At 6:56 AM +0000 8/1/13, Roger Marshall wrote: > 20 min * Additional Data related to an Emergency Call (Brian) > http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > ACTION: Randall Gellens to add text that the Call-Info header can be a sid. I don't recall this discussion or this action item. The draft does discuss that the URL in Call-Info can be a CID. Is there something else it needs to say? If so, I can fix it quickly. > ACTION: Randall Gellens to fix editorial issues in the draft. This has been done in -11 which is posted. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It has always seemed to me that the most difficult part of building a bridge would be the start. --Robert Benchley From randy@qti.qualcomm.com Thu Aug 1 07:17:04 2013 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 997A621F9EA1 for ; Thu, 1 Aug 2013 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go1ITCAFEOzD for ; Thu, 1 Aug 2013 07:16:59 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F721F9F12 for ; Thu, 1 Aug 2013 07:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1375366600; x=1406902600; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=1KeCulpArtgK2n9qtox5Evghkc33+zfjS4+smfoat9o=; b=ClsOe6g5TBStY7TGZHHDx3AfsnkIiVNxNfjU/Q7TSFbSyn0zJql+BJP/ JvVBJ+E3Jw3OYEjtHFN2xS8HZNdeWydkZhXmnleq3dMQLUblS90wthueU D1D7DEiSeYrTNBzgpGUaudeZrBVW+NFAojkR42vrkxBYjCsCXE+qOfvFv g=; X-IronPort-AV: E=Sophos;i="4.89,794,1367996400"; d="scan'208";a="48728021" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 01 Aug 2013 07:16:39 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Aug 2013 07:16:38 -0700 Received: from [10.35.200.44] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 07:16:37 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Aug 2013 05:39:38 -0700 To: Roger Marshall , "ecrit@ietf.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] Cc: "Randall Gellens \(randy@qti.qualcomm.com\)" , "A. Jean Mahoney \(mahoney@nostrum.com\)" Subject: Re: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting 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, 01 Aug 2013 14:17:04 -0000 At 6:56 AM +0000 8/1/13, Roger Marshall wrote: > Randall - The reviews should be in parallel with WGLC. Just to clarify: I didn't state that these should be in parallel, I asked the chairs if the intent was to do them in parallel or do WGLC after the reviews, to which the chairs replied they'd prefer them in parallel. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Studied carefully, a modern payphone reveals itself as a little fortress, carefully designed and redesigned over generations, to resist coin, slugs, zaps of electricity, chunks of coin-shaped ice, prybars, magnets, lockpicks, blasting caps. Public pay- phones must survive in a world of unfriendly, greedy people, and a modern payphone is as exquisitely evolved as a cactus. --Bruce Sterling From rg+ietf@qualcomm.com Thu Aug 1 07:17:08 2013 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 E54BA21E81D1 for ; Thu, 1 Aug 2013 07:17:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYUEssN8aFq1 for ; Thu, 1 Aug 2013 07:17:03 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7743021E8150 for ; Thu, 1 Aug 2013 07:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1375366607; x=1406902607; h=cc:message-id:in-reply-to:references:x-mailer:date:to: from:subject:content-type; bh=xRdBExaUlY0aNhxD2MhGxx2ZvMum296uVnOR1CmxAxg=; b=CA+cVmfa7f9nS2yCJH6W6ZC/hpJ+ssEq7tGHJosRqLb0mh63eZfHu62t tlzWrlWbf5k4aqzmNr4IWlWfAh+CfIv1jOqrkSpHoeMRPNMfjkFzZDEDN 7UnQO4RzR070ATHg39ny4lxF0MwUPyskmpAjZy4ZpVutYqrLvxFcSPvaQ k=; X-IronPort-AV: E=Sophos;i="4.89,794,1367996400"; d="scan'208";a="48621823" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([172.30.48.16]) by sabertooth01.qualcomm.com with ESMTP; 01 Aug 2013 07:16:45 -0700 X-IronPort-AV: E=Sophos;i="4.89,794,1367996400"; d="scan'208";a="85149092" Received: from warlock.qualcomm.com ([129.46.50.49]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2013 07:16:44 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r71EGhcg009697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2013 07:16:43 -0700 X-IronPort-AV: E=Sophos;i="4.89,794,1367996400"; d="scan'208";a="577403374" Received: from unknown (HELO [10.35.200.44]) ([10.64.193.73]) by Ironmsg04-R.qualcomm.com with ESMTP; 01 Aug 2013 07:16:40 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Aug 2013 05:37:53 -0700 To: Roger Marshall , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Cc: "Randall Gellens \(randy@qti.qualcomm.com\)" , "A. Jean Mahoney \(mahoney@nostrum.com\)" Subject: Re: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting 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, 01 Aug 2013 14:17:08 -0000 At 6:56 AM +0000 8/1/13, Roger Marshall wrote: > Randall Gellens - The Call-Info header can be a sid. I can add text > after WGLC. Ah, now that I see the detailed note, it's clear: I was making a comment on Brian's slide/presentation, which didn't say that Call-Info can contain a CID. The document text clearly does say this. The text I said I'd add was to re-add some editorial text that was accidently deleted during a previous revision. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Average estimated salary, in 2005 dollars, of the dads on the 10 top- rated TV shows of the 1950s: $77,000; average for dads on the 2005 10 top-rated TV shows: $207,000. (from Harper's Index 11/05) From randy@qti.qualcomm.com Thu Aug 1 10:07:10 2013 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 D41F721E8202 for ; Thu, 1 Aug 2013 10:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPtTAvzkvDv5 for ; Thu, 1 Aug 2013 10:07:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE721E81AB for ; Thu, 1 Aug 2013 10:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1375376826; x=1406912826; h=message-id:date:to:from:subject:mime-version; bh=GqcJ6URzZXZ5+YcHvR5QBeh9FefQuMXwliQlQASyaR4=; b=mUQ8HT3vV+OrR6o1uHMsZVtH/FTpMupfnVQKNSsTAeCd8kRxI+u2o9Vp DRUREljXVO96dmVzQN8l6x4q+CyxYtmNZIh5F9U0DlEu9qBv0/8qQwZor IjEc3ztMpENfev1pHy29TMqXbIUAKkY6RzU0Zfn3dXq2vMCNoxLgMT3Jk A=; X-IronPort-AV: E=Sophos;i="4.89,795,1367996400"; d="scan'208";a="66187882" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 01 Aug 2013 10:07:05 -0700 X-IronPort-AV: E=Sophos;i="4.89,795,1367996400"; d="scan'208";a="488895853" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Aug 2013 10:07:05 -0700 Received: from [10.35.200.44] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 1 Aug 2013 10:07:04 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Thu, 1 Aug 2013 10:04:52 -0700 To: 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.48.1] Subject: [Ecrit] What belongs in "Service:SOS" URNs? 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, 01 Aug 2013 17:07:11 -0000 In the ECRIT session, there was much discussion regarding what belongs as a subservice in the SOS service URN. Much of the debate focused on a distinction between a pragmatic view and an architectural view, if I may characterize it as such. The pragmatic side arguing that what we have are service numbers (also called short codes) that people are trained to use, such as 911 in the U.S. and 112 in Europe, which are mapped to a service URN, which is used to obtain a SIP route. Alternatively, the architectural side argues that what belongs in a service URN is a distinct service, that is, a different type of response (e.g., police, fire with water, fire with halon, ambulance, animal control, etc.) and that items used for routing don't belong in the URN. In recapping this debate for a fellow IETFer who doesn't follow ECRIT, he asked about the ability to request multiple distinct services. For example, a building where the fire, flood, and burglar alarms have all gone off. Or a vehicle that knows it is being stolen and is on fire (or a vehicle that knows it has a horse trailer and has crashed). His point is that if we don't have the ability to add multiple services at the same time, then in reality what we have is used for routing and isn't a distinct service request. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- tartle (TAR-tul; Scottish; verb): to hesitate in recognizing a person or thing. From RMarshall@telecomsys.com Thu Aug 1 17:13:50 2013 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 79DCA11E8263 for ; Thu, 1 Aug 2013 17:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abq-JM8uid5q for ; Thu, 1 Aug 2013 17:13:38 -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 9D01111E82E5 for ; Thu, 1 Aug 2013 16:27:35 -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 r71NRLlj015828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 1 Aug 2013 16:27:21 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.68]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Thu, 1 Aug 2013 16:27:21 -0700 From: Roger Marshall To: Randall Gellens Thread-Topic: IETF87 Berlin: ECRIT Minutes for 07/29 meeting Thread-Index: Ac6OhCQg2tV1AIsDR4y2YIBZYJFkXgAankCAAAgDjVI= Date: Thu, 1 Aug 2013 23:27:20 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" , "A. Jean Mahoney \(mahoney@nostrum.com\)" , "Randall Gellens \(randy@qti.qualcomm.com\)" Subject: Re: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting 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, 02 Aug 2013 00:13:50 -0000 Randy: I agree - the draft does talk about adding a "CID" in a few places already. That said, the -11 version cut out a whole bunch of Figure call outs, which= might be fine stylistically, but there are now a bunch of in anchored refe= rences in the text (look above many of the example snippets that had the fi= gure labels removed). Anyway, it will causes problems for reviewers. -roger. Sent from my mobile device On Aug 1, 2013, at 7:16 AM, "Randall Gellens" wrote: > At 6:56 AM +0000 8/1/13, Roger Marshall wrote: >=20 >> Randall Gellens - The Call-Info header can be a sid. I can add text afte= r WGLC. >=20 > Ah, now that I see the detailed note, it's clear: I was making a comment = on Brian's slide/presentation, which didn't say that Call-Info can contain = a CID. The document text clearly does say this. The text I said I'd add w= as to re-add some editorial text that was accidently deleted during a previ= ous revision. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Average estimated salary, in 2005 dollars, of the dads on the 10 top- > rated TV shows of the 1950s: $77,000; average for dads on the 2005 10 > top-rated TV shows: $207,000. (from Harper's Index 11/05) CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From RMarshall@telecomsys.com Wed Jul 31 23:56:55 2013 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 C860621F9C99 for ; Wed, 31 Jul 2013 23:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 pfvQYMU2SyP1 for ; Wed, 31 Jul 2013 23:56:34 -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 B6E6021F8E79 for ; Wed, 31 Jul 2013 23:56:33 -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 r716uKOw017015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 31 Jul 2013 23:56:20 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.68]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 31 Jul 2013 23:56:20 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF87 Berlin: ECRIT Minutes for 07/29 meeting Thread-Index: Ac6OhCQg2tV1AIsDR4y2YIBZYJFkXg== Date: Thu, 1 Aug 2013 06:56:19 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC3A6680SEAEXMB2telecomsy_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 01 Aug 2013 18:43:36 -0700 Cc: "Randall Gellens \(randy@qti.qualcomm.com\)" , "A. Jean Mahoney \(mahoney@nostrum.com\)" Subject: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting 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, 01 Aug 2013 06:56:55 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC3A6680SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes for ECRIT WG Meeting, IETF87 Berlin, meeting date 7/29/2013, 13:00-= 15:00 If you have any additions or modifications to these minutes, please let Roger & Marc know via email. These minutes, along with more detailed notes= are pasted below, and are also posted to the IETF87 meeting materials page. A big thank you goes out to both Jean Mahoney and Randall Gellens for their= excellent note-taking. Thanks also to Shida Shubert for being the Jabber = scribe. Chairs: Roger Marshall, rmarshall@telecomsys.com Marc Linsner, mlinsner@cisco.com --------------------------------------------------------------------------- The following contains summarized minutes, followed by more detailed notes. --------------------------------------------------------------------------- ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin --------------------------------------------------------------------------- 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx Note takers: Jean Mahoney and Randall Gellens Jabber scribe: Shida Shubert Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html Chairs presented. ACTION: Go forward with the draft-ietf-ecrit-country-emg-urn document. Keith Drage commented that the current milestones have little relationship to the current charter of the group; suggests rechartering if the group continues to work on such drafts, or else such drafts should go to DISPATCH ACTION: Hannes to send milestone updates to the mailing list. - draft-ietf-ecrit-trustworthy-location - draft-ietf-ecrit-unauthenticated-access - draft-ietf-ecrit-country-emg-urn ACTION: Chairs to review the charter. --------------------------------------------------------------------------- 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx Brian presented. There was a discussion about reviewing the document, and adding the IANA re= gistration table to the draft. ACTION: Brian to discuss IANA registration table on sipcore list. ACTION: Randall Gellens to add text that the Call-Info header can be a sid. ACTION: Randall Gellens to fix editorial issues in the draft. ACTION: WGLC and reviewer reviews of draft-ietf-ecrit-additional-data to be= started in parallel. ACTION: Christer Holmberg and Barbara Stark to review draft-ietf-ecrit-addi= tional-data. ACTION: Chairs to coordinate reviews from NENA and EENA. ----------------------------------------------------------------------- 10 min * (Brian) Updating Additional Data related to an Emergency Call usin= g Subscribe/Notify (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/ Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx Brian presented. Draft proposes using subscribe/notify to allow updated sensor data to be se= nt Uses extension mechanism from Additional-Data to allow subscribe address fo= r updates to be sent as an additional-data block (as per the additional-dat= a draft) Objection raised to this being done in ECRIT, saying this is a general prob= lem for which there are general solutions Suggestion to conceptualize not as an extension to additional-data but rath= er data-only (sensor data sent as CAP in MESSAGE where there is no session)= , as this narrows the scope and focuses the problem Discussion followed about using INFO as an alternative solution to using SU= BSCRIBE/NOTIFY. ACTION: Brian to update the draft on how to solve the problem of devices th= at can't set up a server to receive a SUBSCRIBE. ACTION: Chairs to determine if a more general RAI solution should be applie= d. ACTION: Brian to start the additional-data discussion on the list so that a= problem statement can be defined, and a charter item created. --------------------------------------------------------------------------- 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt Bernard Aboba presented. Added discussions of place shifting, location shifting, time shifting, etc.= , from previous Martin Thomson drafts Added discussion of location theft (attacker uses target's location as his/= her own) Room had no feedback on the draft or presentation. ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending any f= inal WGLC comments. --------------------------------------------------------------------------- 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt Ban Al-Bakri presented eCall information on behalf of ETSI (i.e., what they= want from IETF) There was a discussion about whether it would be a use case for additional = data, if gateways would be used, the requirements surrounding ASN.1, planni= ng for future migration, making any IETF work on it more global. Some questions from audience regarding requirements Ban mentioned for PSAP = to request actions by the IVS and how this fits into Brian's update proposa= l. Comments from audience on ASN.1 encoding and why can't XML be used Comment made regarding ASN.1 and XML being temporary and a means is needed = to upgrade later Comment made to separate the issues of mechanism and encoding Suggestion made to have IETF define two ways of transporting the same data:= ASN.1 for eCall and XML for anyone else Comment and suggestion that this can be done but needs to be carefully done= so as not to appear as though the IETF is messing in eCall ACTION: Continue eCall discussion on the list. --------------------------------------------------------------------------- 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall/ Intention: Discussion of draft & WG adoption question Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf Randall Gellens presented. Comments made about the current charter language that says the group does n= ot work on items that are specific to a regulatory environment, and hence t= he group could adopt the ACN bits but not the ecall parts There was a discussion about splitting the document into eCall and ACN draf= ts. An eCall specific draft is currently not covered in the charter. ACTION: Chairs to work with the ADs on rechartering to do specific eCall wo= rk. --------------------------------------------------------------------------- 10 min * Uniform Resource Name (URN) extension for automatic and manual Eme= rgency Services (Roland) draft-jesske-ecrit-ecall-urn-extension-01 Intention: Discussion of changes to draft Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx Roland presented on the ecall URN extension for subservices. Proposes to add police/fire/ambulance/etc., into the ecall service URN It was pointed out this out as a two dimensional problem and that this pres= ents a combinatorial nightmare. Suggested that other mechanisms (such as Caller-Preferences) to pass this i= nformation but not in the URN. There was a discussion about how these extensions are not scalable and how = they were conflating concepts of "What?" (sos emergency call) with the "How= " (eCall, police, fire, ambulance). Comment made that even automatic and manual should not be in the URN either No actions. --------------------------------------------------------------------------- 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates to draft presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx Brian presented. Data-only call that does not create a session (carries sensor data as CAP m= essage) Draft changed how CAP message is sent: now as a block of additional-data (a= nd hence can be passed by value or reference) No discussion other than the timing of the review. ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneously= with draft-ietf-ecrit-additional-data. --------------------------------------------------------------------------- 10 min * Service Coverage Scope for Service URN (Brian) http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/ Intention: Discuss new draft Brian presented. Presentation around service coverage scope (geographic scope), so-called "A= 1", "A2", etc. level of geoprif PIDF-LO, to distinguish from neighborhood w= atch up to borough, to city or town, to county or parish, to state or regio= n, to entire country Discussion covered how these scopes weren't really geographical, and some o= f the taxonomy issues. Objection heard that this approach conflates geographic division with type = of service (see detailed notes) Vigorous debate on how services are divided up today, between a "pure" arch= itecture and pragmatics. Comment made that IMS needs something besides a number in the request URI. More debate, especially from Henning and Ted versus Brian (see detailed not= es) ACTION: discuss draft-mongrain-ecrit-service-coverage-scope-urn on the mail= ing list. --------------------------------------------------------------------------- 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location Intention: Discussion of changes to draft slides: Brian presented. Defines an extension to LoST so that location information can be included i= n a LoST response to a FindService query Uses are: provide missing fields if location information in request is vali= d but not complete ("The crrect representation is") -- used when provisioni= ng Additionally, so it can provide alternatives when location in request is no= t valid (a "Did you mean?") Very few people in the room had read the draft. ACTION: working group to read draft-marshall-ecrit-similar-location and com= ment on the list. --------------------------------------------------------------------------- 5 min * Open Discussion No questions [EOM] --------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////// --------------------------------------------------------------------------- --------------------------------------------------------------------------- Detailed meeting notes as follows, by A. Jean Mahoney --------------------------------------------------------------------------- ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin --------------------------------------------------------------------------- 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx Note takers: Jean Mahoney and Randall Gellens Jabber scribe: Shida Schubert Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html The agenda was bashed on the mailing list and updated. Slide 4 - Document Status draft-ietf-ecrit-country-emg-urn-00 Marc Linsner - The WGLC completed today, are there any comments? No comments from the room. Marc - How to progress the doc? It won't be presented at this meeting. Any = comments? Brian Rosen - Everyone agreed that the prior version was what they wanted t= o see. There was substantial list discussion that converged. The author ref= lected working group consensus in the prior draft. draft-ietf-ecrit-trustworthy-location-07 - WGLC completed today Slide 5 - Milestones Marc - Need to revise the June 2013 for "Trustworthy Location Information d= raft" Richard Barnes - The rough-loc draft expired. The AD should talk with the c= hairs after this meeting. ACTION Hannes Tschofenig - draft-ietf-ecrit-unauthenticated-access has been sent t= o IESG Roger - We will note it as done on the milestones. Hannes - draft-ietf-ecrit-country-emg-urn should be moved up from December = 2013. Marc - We can move that up. ACTION: Hannes to send milestone updates to the mailing list. Keith Drage - The active working group documents don't match the core chart= er. Will you recharter? Marc - you're right about the docs. Keith - Non-charter docs should go to dispatch. Marc - We'll review the charter. ACTION: Chairs to review the charter. --------------------------------------------------------------------------- 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx Brian presented the slides, which provided a quick overview of how addition= al data works, a covered changes to the doc. Brian - The authors think this is done. No list contention. Just need to do= some editorial work. Randall Gellens - The Call-Info header can be a sid. I can add text after W= GLC. Roger Marshall - I don't think the doc has had a good review for a while. S= hould request reviews from NENA and EENA since they rely on this doc. We n= eed two good reviews from the working group. Marc - has anyone read it? Brian - Barbara? Barbara Stark - yes, I'll review it. Hannes - Christer? Christer Holmberg - I'm ok to do it. ACTION: Christer Holmberg and Barbara Stark to review draft-ietf-ecrit-a= dditional-data. Chairs to coordinate reviews from NENA and EENA. Randall - The reviews should be in parallel with WGLC. Marc - We need new spin on draft. Randall - I can do that. ACTION: Randall to fix editorial issues, and release the document. When t= he draft is available, start WGLC and reviewer reviews in parallel. Keith - Did this document raise the IANA registration table to ... ? Brian - Yes Keith - Was there a discussion in sipcore? Brian - Assuming that there was, but I will raise the issue on sipcore list ACTION: Brian to discuss IANA registration table on sipcore list. Keith - It shouldn't take place ad-hoc. Brian - The document doesn't create a purpose table. I will raise the issue= . It won't be added to the document until we get agreement. ----------------------------------------------------------------------- 10 min * (Brian) Updating Additional Data related to an Emergency Call usin= g Subscribe/Notify (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/ Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx Brian presented. Brian - The PSAP has to control rate of updates. Defines new URI. Send the = subscription to. The event package is XML multi-part MIME, there is no new = definition here. Just a new block of data. If you send by reference, can g= et it. No new mechanism. There has been a fair amount of discussion. There are other working group p= articipants that want info-block, but then the PSAP couldn't control the ra= te. The main advantage of this solution is that you get the filter mechanis= m. I would like to adopt this document as a working group item. Marc - Who's read this document? Room - 5 or so hands Christer - I would like to adopt the draft. However, a user behind a NAT ha= s to register. However they don't get the credentials, it won't work. That'= s the main issue. If you use INFO, then it's in the dialog, don't have that= problem. If you use SUBSCRIBE, there are issues with reaching the PSAP. In= dialog, it would go to PSAP. This should be discussed. Brian - For handling devices that can't set up a server to receive a SUBSCR= IBE. The next version of the draft will say that they should use a server o= utside of that. It's the presence problem, and can be solved the same way -= use an outside server. The problem with INFO - you have to create filters = - copy all of the filters RFC - and reproduce it for INFO. ACTION: Brian to update the draft on how to solve the problem of devices th= at can't set up a server to receive a SUBSCRIBE. Christer - You need it for info package anyway. Brian - I would have to quadruple the draft and copy everything from the Fi= lters RFC. Brian - The most common occurrence of this is data-only. There is no sessio= n. In the eCall case, there is the call and data so there's a dialog. Christer - You could establish a session. Updating data. Brian - The PSAP needs to control that. The PSAP would create the session. = The people along the line don't want updates. Only the responder does, but = they aren't in the call path. The want updates after call is over. Keith - Why is this emergency call specific? Only because the PSAP wants to= use it. ecrit should not solve the problem - transmit data once call is in= progress. There's a more general solution here. Brian - You are saying that we need a generic RAI solution for updating dat= a in a SIP message. Keith - Not necessarily. There are RAI solutions already there. It shouldn'= t be ecrit in terms of making decision. Brian - Make chairs make that decision. ACTION: Chairs to determine if a more general RAI solution should be applie= d. Randall - If it's data only, it narrows the scope and fits better with the = solution. It's a solution for sending data when you don't have sessions. Richard - Isn't this solved by additional-data itself - put it in the URI? Brian - You don't want to just poll since you don't know when data changes. Richard - Subscribe to a SIP URI. Brian - That's what I said. It's a block of additional data. It's a URI, yo= u can subscribe to it. Hannes - We had a discussion about data-only being sent around without sess= ion. It was conflated with this draft on the list by Ivo. Brian - When you look at discussion, the subject references data-only, not = additional-data. There's 7 blocks of data, only 2 would have updates. Christer - The use case was data only. There is no session. Brian - INFO won't solve that problem since there's no session. Christer - You can establish the session. Brian, Hannes - No! We don't want to open a session. Brian - there's an alternative that folks want to see. Need to define a pro= blem statement, get a charter item, and get drafts that fit. ACTION: Brian to start the additional-data discussion on the list so that a= problem statement can be defined, and a charter item created. Randall - Why is not in the data-only draft? Brian - It was suggested that it be split out. --------------------------------------------------------------------------- 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt Bernard Aboba presented. Bernard - There was an issue raised in WGLC, which ended today. Issue 15 - = the definitions could be revised, made simpler. Any feedback? Room had no feedback. Marc - Sounds like we're ready to go forward pending end of WGLC. Brian - I have a few more hours to get my comments in. ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending any f= inal WGLC comments. --------------------------------------------------------------------------- 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt Ban Al-Bakri presented. Questions: Christer - This is a use case with the session and additional data. Ban - The PSAP can request additional data. Christer - INFO would then be the appropriate mechanism. Maybe the solution= should be split into session based and non-session based. Brian - Reasons for update that survive the call Ban - The PSAP can request update to the MSD. Once the voice call is releas= ed, there may be a call back maybe. Brian - Can the MSD call back? The PSAP is not interested in updates unless= there's an error. But the responders want the data. If you have updates, t= he responders want them. Ban - the EU requirement is that the PSAP should keep on the call until res= ponders are on the scene. Randall - eCall requirements are different that requirements for updates fo= r sensor data - the sensor knows that there are updates, not the PSAP. Hannes - I don't care about specific encoding - text or JSON. We can ship d= ata around. Hadriel Kaplan - Both you guys need to go up a level and describe how the r= esponder gets the data. If they get it from the PSAP, then the SUBSCRIBE go= es to that. Brian - The PSAP doesn't want to be in the path. Hadriel - ASN.1 is a legal requirement? Ban - Yes. Hadriel - If the EC wants to support a SIP-based service, they should just = point to RFCs. Randall - The more IETF gets into business of telling EC how to do eCall, t= he less progress we make. We can tell them how SIP can solve it. Hadriel - If you can't specify to the PSAPs, then we need a gateway. ban - Should be transferred as a package. Need minimum impact on the networ= k. Don't want extra network elements. Hadriel - But if you are working with existing infrastructure. Hannes - In US, the BES (?) data looks different than eCall data. Hadriel - Why is this specific to eCall? We should design globally. Randall - Even if it's encoded in XML, it doesn't ensure that the vendor's = implementation (like OnStar) would be clear. Can work towards commonality, = but can't just jump there. Henning - The solution should be long-lived - 20 year old cars break down. = As you migrate with car model years. PSAP software is provided by a small n= umber of vendors. Need mechanism in place where gradual migration is possib= le. Have you thought about that? Ban - We have discussed this. Too much work right now. Henning - In SIP we've tried to separate format. It's handled with a negoti= ation or a label, versioning scheme. You don't want to throw out the whole = thing if the format changes. Keith - We will continue this discussion on the list. Be clear about transf= er syntax or the encoding. Need to be specific. ACTION: Continue eCall discussion on the list. Brian - We'll define block of additional data as chunk of ASN.1, could we n= ot also have XML with the same data? Multipart alternative. Randall - Can use MIME type for ASN.1 and then can wrap it later to upgrade. Brian - For data structures that have already been defined, put them in a M= IME block. Could and should define an XML block as an alternative. Allow so= meone else to use the same idea, not in EU law. Ban - 3gPP should specify which block to use. Randall - Say how to do eCall the way it is now. And then how to do it more= generally. Brian - Exactly. Roger - Is there a draft to describe this? Ban - The EC is funding this work. Please sign the attendance sheet - so it= can get in kind funding. Keith - Have you checked with secretariat on this process? You should use t= he blue sheets. Ban - It's ok, I've checked with the secretariat. Marc - If you don't want to sign, just pass it on. --------------------------------------------------------------------------- 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall/ Intention: Discussion of draft & WG adoption question Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf Randall Gellens presented. ACN - Automatic crash notifications Brian - The current draft is informational. If we split it, the eCall draft= would be normative. Would define block of additional data with MSD. Ban - I support this, but the info draft will be ... Brian - will be ACN. Marc - Split the docs? Hannes - Randy's comment - We trying to make doc generic so it works everyw= here. Routing functionality, SIP setup is generic, but for specific vendors= , they don't care. Keith - ACN is not an emergency call? Randall - It is. Keith - How does this fit in the charter? Randall - these are all emergency calls. Ted Hardie - I agree with Keith. If you split into ACN and eCall, eCall is = specific regulatory environment, which the charter forbids work in. You hav= e to recharter to adopt eCall. You could adopt the ACN bits now. Marc - chairs will work with ADs on recharters. ACTION: Chairs to work with the ADs on rechartering to do specific eCall wo= rk. --------------------------------------------------------------------------- 10 min * Uniform Resource Name (URN) extension for automatic and manual Eme= rgency Services (Roland) draft-jesske-ecrit-ecall-urn-extension-01 Intention: Discussion of changes to draft Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx Roland presented. There's eCall for police, eCall for fire. Ban - 3gpp has the requirement. However, haven't seen the requirement on ca= r manufacturers to provide this info. Needs to be regulated across Europe. = There are liability issues here. When you have multiple categories, you can= 't fork the voice call to all the categories. You need to route to the PSAP= that supports eCall, and they find appropriate services. Defining multiple= categories is in the network, and is also regulated. Roland - I have received similar comments. There are PSAPs that can support= eCall and others not. Henning Schulzrinne - There are two dimensions here - who gets the call? Po= lice, Fire; Automatic, Manual. You have combinatorial explosion problems. A= nytime you add a service (health monitoring (fallen can't get up), you have= to update this. We use this as a key in LoST, but we route on location, on= language capabilities. this leads to a non-scalable solution, and you have= to have fallbacks, etc. If we need a coarse-grain routing, we have mechani= sms that do that without the explosion. Roland - We have an existing implementation, description in 3GPP. Drawback = currently. Don't want to redo anything at the IT level. If you only have eC= all implemented. Henning - You are assuming a hierarchy, the more dimensions you have, the h= arder to determine a hierarchy. OnStar gets police, ambulance, and then rou= tes. If you add poison control, it would go to OnStar and they would deal w= ith it. You need a responder hierarchy. We can change protocols. If it's no= t in LoST, add it. You make complicated tradeoffs. For eCall, you don't rou= te differently for automatic and manual. Keith - IMS sticks URN in the URI and doesn't use LoST. There are scenarios= where neither of these work. My car needs to work in any country it goes t= o. Work in countries that don't support eCall, or support the first hierarc= hy of police, fire. Ted Hardie - A URN service sos is a "what?". You are conflating a "how?" Ma= nual and Automatic are also "hows?". Need to do in 2 urn namespaces to get = "how" away from "what". Hadriel - I'm agreeing with Ted and Keith. eCall shouldn't be in Brian's dr= aft. Ban - Auto and Manual indicate the target. Could be different PSAPs. Ted - It's not a different "what". sos.fire - who I want the response from.= If automatic gives me a different responder, then it's different. If it's = just a different PSAP, then it's not. Henning - There are all kinds of things to route on. Fire department - the = truck and the equipment, the people - are the same. In terms of trustworthi= ness.... The PSAPs use all sorts of differentiators. It's a gray zone. A UR= N is not the only thing to use. Not the details on agency, whether it was m= ediated by alarm company, not valuable in a URN. You can only have 1 hierar= chy. Appropriate default responses. Ban - Need to keep mind in automatic, it's part of the flag. Henning - You need to look at the routing behaviors that you want, then wha= t are your tools to make the info available to the required parties. And wh= ere is it available, where could it be added. If you look at PSTN - call ty= pes - pay phone, prison. Labeled them ... --------------------------------------------------------------------------- 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates to draft presentation: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx Brian presented. Brian - Other than the discussion of using a block of additional data, I th= ink the doc is settled and is ready to go. No one has raised objections. Marc - Move to WGLC next week. Brian - You have to do WGLC simultaneously with additional-data. ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneously= with draft-ietf-ecrit-additional-data. --------------------------------------------------------------------------- 10 min * Service Coverage Scope for Service URN (Brian) http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/ Intention: Discuss new draft Brian presented. Henning - What about transit police, or campus police, secret service, etc? Brian - They have geographic boundaries. Randall - But roads can be confusing - you think it's a public road, but ac= tually you need park police. Ted - If it's based on location. Brian - What if you are sitting in one of these buildings, but want the sta= te police. Ted - You are conflating geographic dominion with different services. Fire = service - halon versus water. It's a "what". Police provide different servi= ces - put that in a "what" rather than "where". Describe the "what" in the = URN - for instance, drug-enforcement. Brian - Interesting idea, but that isn't the way services are organized, th= ere is no taxonomy, I couldn't come up with a way to build a device. RIght = now people use phone numbers. Ted - it's in people's brains. Brian - I don't know how to deal with the taxonomy issues. Ted - But this is muddying the service URN because there is muddiness in th= e background. Brian - there are different numbers for different services. Ted - Some human will have to pick a department. Brian - There's no solution. Ted - If they need to call a specific phone number, they pick up the phone.= You know the difference between the park service and the police. Keith - The draft goes into irrelevant geographic details. Say you want the= police force that handles kidnapping versus theft. Brian - If we could just start over. Keith - It's too late. But in each country has distinguished between them. Marc - This discussion is cutting into your next presentation, brian. Keith - Want to use something in the request URI, not the dialed number. Henning - Geography doesn't work. It's not clear to a citizen. There's comi= ngling. If someone calls 911, and if I forward their call to the metro poli= ce. There is no reason for the cities have the same organizations - it's da= tabase identifiers. Brian - This is an external problem. Start with a service phone number, map= to service URN, get a URI to route the call. The current drafts don't solv= e this. Henning - Is it solvable? Brian - You want a service number for kidnapping. Hadriel - You call 911 Brian - This issue isn't applicable for US. Hadriel - We don't need to convert to URN. Dial Emergency on your phone, an= d it works. If you need to call DEA - then you can look that up and call. I= t's not a real emergency. Marc - Take to the list. ACTION: discuss raft-mongrain-ecrit-service-coverage-scope-urn on the maili= ng list. --------------------------------------------------------------------------- 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location Intention: Discussion of changes to draft slides: Brian presented. Is there sufficient interest here? The NENA guys are interested. Marc - How many people have read? 2 or so Brian - please read and comment on list. ACTION: working group to read draft-marshall-ecrit-similar-location and com= ment on the list. Randall - Is this the same proposal that came up in geopriv? Brian - This is a LoST thing. Not geopriv. Barbara - I read this draft, and my colleague has asked me to support it. I= thought it looked good. --------------------------------------------------------------------------- 5 min * Open Discussion No questions [EOM] --------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////// --------------------------------------------------------------------------- --------------------------------------------------------------------------- Detailed meeting notes as follows, by Randall Gellens --------------------------------------------------------------------------- Here are my notes from the ecrit session: * Updated milestones * Keith Drage comments that the current milestones have little re= lationship to the current charter of the group; suggests rechartering if th= e group continues to work on such drafts, or else such drafts should go to = DISPATCH * Brian Rosen presents on status of additional-data draft * Editorial revisions from Randy were lost in recent update from = Hannes * Randy will update document this week; WGLC will start next week * Christer and Barbara agree to do reviews * Brian Rosen presented on sub-not draft * Draft proposes using subscribe/notify to allow updated sensor d= ata to be sent * Uses extension mechanism from Additional-Data to allow subscrib= e address for updates to be sent as an additional-data block (as per the ad= ditional-data draft) * Allows PSAP (or other recipient) to control rate * Brian asks for WG adoption * Christer says he has an issue: data updates don't go in session= , could be a problem with credentials and access (separate credentials need= ed to successfully subscribe, server may not be accessible to arbitrary cli= ents). Brian says in that case the device uploads the update to an externa= lly-accessible server and sends an address on that server * Christer prefers to send updates in INFO in the session, but Br= ian objects because there is no mechanism now for PSAPs (or other recipient= ) to set filter/throttle to control rate of updates, and also because in th= e data-only case there is no session, and also because the party interested= in updates may not be the PSAP itself but rather a responder (who isn't in= the call path) * Keith Drage objects to this being done in ECRIT, saying this is= a general problem for which there are general solutions * Randy suggests that this should be conceptualized not as an ext= ension to additional-data but rather data-only (sensor data sent as CAP in = MESSAGE where there is no session), as this narrows the scope and focuses t= he problem * Much further discussion * Bernard presents on trustworthy-location * Added discussions of place shifting, location shifting, time sh= ifting, etc., from previous Martin Thomson drafts * Added discussion of location theft (attacker uses target's loca= tion as his/her own) * Document passed WGLC * Ban presented on eCall on behalf of ETSI (what it is, what they= want from IETF) * Some questions from audience regarding requirements Ban mention= ed for PSAP to request actions by the IVS and how this fits into Brian's up= date proposal. * Randy says that the requirements that Brian is solving (where s= ensor knows it has updates) and in eCall (where PSAP knows what it wants) a= re different and we should not get into details now * Comments from audience on ASN.1 encoding and why can't XML be u= sed * Henning has comments regarding ASN.1 and XML being temporary an= d a means is needed to upgrade later * Keith Drage says we need to separate the issues of mechanism an= d encoding * Brian suggests that the IETF define two ways of transporting th= e same data: ASN.1 for eCall and XML for anyone else * Randy suggests that this can be done but needs to be carefully = done so as not to appear as though the IETF is messing in eCall * Randy presented on the ecall draft * Keith asks how any of this is in charter * Ted Hardie points to charter language that says the group does = not work on items that are specific to a regulatory environment, and hence = the group could adopt the ACN bits but not the ecall parts * Chairs will take this under advisement and consider rechartering * Roland (D-T) presented on the ecall URN extension for subservic= es * Proposes to add police/fire/ambulance/etc. into the ecall URN (= as proposed in the eCall draft), either before or after the 'ecall' portion * Ban asks about the concept before the draft; says there is a 3G= PP requirement and Stage 3 text providing for subservices but that this doe= sn't apply to cars, and further any such facility (e.g., cars reporting tha= t they are on fire) needs to be standardized. Ban also points out that thi= s would be a problem for the MNO to route the call -- currently eCall calls= are routed to an eCall-capable PSAP; how would an eCall with a subservice = be routed? * Henning says that there are two dimensions to the problem: call= routing (ecalls are routed to ecall-capable PSAP and it's not likely that = there will be dedicated PSAPs for eCalls from vehicles on fire, vehicles wi= th poisoning victims, etc.) and that this presents a combinatorial nightmar= e. Henning suggests using other mechanisms (such as Caller-Preferences) to= pass this information but not in the URN. * Keith Drage says this needs to work in countries that don't sup= port eCall, and in countries that don't support police/fire/ambulance/etc. = as the top level. * Ted Hardie says don't conflate the what (sos emergency call) wi= th the how (eCall, police, fire, ambulance) * Hadrien says even automatic and manual should not be in the URN= either * Ted says routing to a different place is a different "how" and = not a different "what" and so manual vs automatic shouldn't be in the URN b= ut 'police', 'fire', etc. are different "what"s. * Henning echoes Ted's point that the URN is supposed to indicate= who you expect to show up (police, fire, etc.) * Henning proposes using a different mechanism for conveying this= information (and discusses the old PSTN concept of call types such as pay = phone, prison, etc.) * Comment to use feature-tag * Brian presents on data-only draft * Data-only call that does not create a session (carries sensor d= ata as CAP message) * Draft changed how CAP message is sent: now as a block of additi= onal-data (and hence can be passed by value or reference) * draft-mongrain-ecrit-service-coverage-scope-urn-00 * Brian discusses service coverage scope (geographic scope), so-c= alled "A" level of geoprif PIDF-LO, to distinguish from neighborhood watch = up to borough, to city or town, to county or parish, to state or region, to= entire country * Ted objects that this is conflating geographic division with ty= pe of service; if different police forces provide the same type of response= , it doesn't belong in the "what" difference * Brian says that's not how services are organized today, where d= ifferent numbers are used * Brian and Ted argue about architectural purity versus pragmatics * Keith says we do need something in the Request-URI so IMS can u= se it, just not the dialed number * Brian says this comes down to: we start with a service number t= hat a user dials, which is mapped to a service URN, which is used to route = to a responder * More debate, especially from Henning and Ted versus Brian * Brian presents on similar-location * Defines an extension to LoST so that location information can b= e included in a LoST response to a FindService query * Uses: provide missing fields if location information in request= is valid but not complete ("The crrect representation is") -- used when pr= ovisioning * also provide alternatives when location in request is not valid= (a "Did you mean?") -- Randall Gellens 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_FBD5AAFFD0978846BF6D3FAB4C892ACC3A6680SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minutes for ECRIT WG Meeting, IETF87 Berlin, meeting= date 7/29/2013, 13:00-15:00

 

If you have any additions or modifications to these = minutes, please let

Roger & Marc know via email.  These minutes= , along with more detailed notes are pasted below, and are also posted to t= he IETF87

meeting materials page.

 

A big thank you= goes out to both Jean Mahoney and Randall Gellens for their excellent note= -taking.  Thanks also to Shida Shubert for being the Jabber scribe.

 

Chairs:

Roger Marshall, rmarshall@telecomsys.com

Marc Linsner, = mlinsner@cisco.com

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

The following contains summarized minutes, followed by more detailed not= es.

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

ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin

 

 

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

10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marsha= ll)

 

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx

 

Note takers: Jean Mahoney and Randall Gellens

 

Jabber scribe: Shida Shubert

Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html

 

Chairs presented.

 

 

ACTION: Go forward with the draft-ietf-ecrit-country-emg-urn document. <= o:p>

 

Keith Drage commented that the current milestones have little relationsh= ip

to the current charter of the group; suggests rechartering if the group =

continues to work on such drafts, or else such drafts should go to DISPA= TCH

 

ACTION: Hannes to send milestone updates to the mailing list.

 - draft-ietf-ecrit-trustworthy-location

- draft-ietf-ecrit-unauthenticated-access

- draft-ietf-ecrit-country-emg-urn

 

ACTION: Chairs to review the charter.

 

 

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

20 min * Additional Data related to an Emergency Call (Brian)=

http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss latest changes and if ready for WGLC

slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx=

 

Brian presented.

 

There was a discussion about reviewing the document, and adding the IANA= registration table to the draft.

 

ACTION: Brian to discuss IANA registration table on sipcore list. <= /o:p>

 

ACTION: Randall Gellens to add text that the Call-Info header can be a s= id.

 

ACTION: Randall Gellens to fix editorial issues in the draft.

 

ACTION: WGLC and reviewer reviews of draft-ietf-ecrit-additional-data to= be started in parallel.

 

ACTION: Christer Holmberg and Barbara Stark to review draft-ietf-ecrit-a= dditional-data.

 

ACTION: Chairs to coordinate reviews from NENA and EENA.

 

 

 

-----------------------------------------------------------------------<= o:p>

10 min * (Brian) Updating Additional Data related to an Emergency Call u= sing Subscribe/Notify (Brian)

http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx

 

Brian presented.

 

Draft proposes using subscribe/notify to allow updated sensor data to be= sent

 

Uses extension mechanism from Additional-Data to allow subscribe address= for updates to be sent as an additional-data block (as per the additional-= data draft)

 

Objection raised to this being done in ECRIT, saying this is a general p= roblem for which there are general solutions

 

Suggestion to conceptualize not as an extension to additional-data but r= ather data-only (sensor data sent as CAP in MESSAGE where there is no sessi= on), as this narrows the scope and focuses the problem

 

Discussion followed about using INFO as an alternative solution to using= SUBSCRIBE/NOTIFY.

 

ACTION: Brian to update the draft on how to solve the problem of devices= that can't set up a server to receive a SUBSCRIBE.

 

ACTION: Chairs to determine if a more general RAI solution should be app= lied.

 

ACTION: Brian to start the additional-data discussion on the list so tha= t a problem statement can be defined, and a charter item created.

 

 

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

15 min. * Trustworthy Location Information (Bernard)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrite

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt

 

Bernard Aboba presented.

 

Added discussions of place shifting, location shifting, time shifting, e= tc., from previous Martin Thomson drafts

 

Added discussion of location theft (attacker uses target's location as h= is/her own)

 

Room had no feedback on the draft or presentation.

 

ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending an= y final WGLC comments.

 

 

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

15 min * eCall - background, current status, and requirements discussion= linked to current ETSI work (Ban Al-Bakri)

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt

 

Ban Al-Bakri presented eCall information on behalf of ETSI (i.e., what t= hey want from IETF)

 

There was a discussion about whether it would be a use case for addition= al data, if gateways would be used, the requirements surrounding ASN.1, pla= nning for future migration, making any IETF work on it more global.

 

Some questions from audience regarding requirements Ban mentioned for PS= AP to request actions by the IVS and how this fits into Brian's update prop= osal.

 

Comments from audience on ASN.1 encoding and why can't XML be used =

 

Comment made regarding ASN.1 and XML being temporary and a means is need= ed to upgrade later

 

Comment made to separate the issues of mechanism and encoding

 

Suggestion made to have IETF define two ways of transporting the same da= ta: ASN.1 for eCall and XML for anyone else

 

Comment and suggestion that this can be done but needs to be carefully d= one so as not to appear as though the IETF is messing in eCall

 

ACTION: Continue eCall discussion on the list.

 

 

 

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

15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes)=

http://tools.ietf.org/id/draft-rosen-ecrit-ecall/

Intention: Discussion of draft & WG adoption question

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf

 

Randall Gellens presented.

 

Comments made about the current charter language that says the group doe= s not work on items that are specific to a regulatory environment, and henc= e the group could adopt the ACN bits but not the ecall parts

 

There was a discussion about splitting the document into eCall and ACN d= rafts. An eCall specific draft is currently not covered in the charter.

 

ACTION: Chairs to work with the ADs on rechartering to do specific eCall= work.

 

 

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

10 min * Uniform Resource Name (URN) extension for automatic and manual = Emergency Services (Roland)

draft-jesske-ecrit-ecall-urn-extension-01

Intention: Discussion of changes to draft

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx

 

Roland presented on the ecall URN extension for subservices.<= /p>

 

Proposes to add police/fire/ambulance/etc., into the ecall service URN

 

It was pointed out this out as a two dimensional problem and that this p= resents a combinatorial nightmare.

 

Suggested that other mechanisms (such as Caller-Preferences) to pass thi= s information but not in the URN.

 

There was a discussion about how these extensions are not scalable and h= ow they were conflating concepts of "What?" (sos emergency call) = with the "How" (eCall, police, fire, ambulance).

 

Comment made that even automatic and manual should not be in the URN eit= her

 

No actions.

 

 

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

10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts= using the Session Initiation Protocol (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss recent updates to draft

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx

 

Brian presented.

 

Data-only call that does not create a session (carries sensor data as CA= P message)

 

Draft changed how CAP message is sent: now as a block of additional-data= (and hence can be passed by value or reference)

 

No discussion other than the timing of the review.

 

ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneou= sly with draft-ietf-ecrit-additional-data.

 

 

 

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

10 min * Service Coverage Scope for Service URN (Brian)

http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn= /

Intention: Discuss new draft

 

Brian presented.

 

Presentation around service coverage scope (geographic scope), so-called= "A1", "A2", etc. level of geoprif PIDF-LO, to distingu= ish from neighborhood watch up to borough, to city or town, to county or pa= rish, to state or region, to entire country

 

Discussion covered how these scopes weren't really geographical, and som= e of the taxonomy issues.

 

Objection heard that this approach conflates geographic division with ty= pe of service (see detailed notes)

 

Vigorous debate on how services are divided up today, between a "pu= re" architecture and pragmatics.

Comment made that IMS needs something besides a number in the request UR= I.

More debate, especially from Henning and Ted versus Brian (see detailed = notes)

 

ACTION: discuss draft-mongrain-ecrit-service-coverage-scope-urn on the m= ailing list.

 

 

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

10 min * A LoST extension to support return of complete and similar loca= tion info (Brian)

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location

Intention: Discussion of changes to draft

slides:

 

Brian presented.

 

Defines an extension to LoST so that location information can be include= d in a LoST response to a FindService query

 

Uses are: provide missing fields if location information in request is v= alid but not complete ("The crrect representation is") -- used wh= en provisioning

 

Additionally, so it can provide alternatives when location in request is= not valid (a "Did you mean?")

 

Very few people in the room had read the draft.

 

ACTION: working group to read draft-marshall-ecrit-similar-location and = comment on the list.

 

 

 

 

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

5 min * Open Discussion

 

No questions

 

[EOM]

 

 

 

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

////////////////////////////////////////////////////////////////////////= ///

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

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

Detailed meeting notes as follows, by A. Jean Mahoney

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

 

ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin

 

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

10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marsha= ll)

 

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx

 

Note takers: Jean Mahoney and Randall Gellens

 

Jabber scribe: Shida Schubert

Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html

 

The agenda was bashed on the mailing list and updated.

 

Slide 4 - Document Status

 

draft-ietf-ecrit-country-emg-urn-00

 

Marc Linsner - The WGLC completed today, are there any comments?

 

No comments from the room.

 

Marc - How to progress the doc? It won't be presented at this meeting. A= ny comments?

 

Brian Rosen - Everyone agreed that the prior version was what they wante= d to see. There was substantial list discussion that converged. The author = reflected working group consensus in the prior draft.

draft-ietf-ecrit-trustworthy-location-07 - WGLC completed today

 

Slide 5 - Milestones

 

Marc - Need to revise the June 2013 for "Trustworthy Location Infor= mation draft"

 

Richard Barnes - The rough-loc draft expired. The AD should talk with th= e chairs after this meeting. ACTION

 

Hannes Tschofenig - draft-ietf-ecrit-unauthenticated-access has been sen= t to IESG

 

Roger - We will note it as done on the milestones.

 

Hannes - draft-ietf-ecrit-country-emg-urn should be moved up from Decemb= er 2013.

 

Marc - We can move that up. 

 

ACTION:   Hannes to send milestone updates to the mailing list= .

 

Keith Drage - The active working group documents don't match the core ch= arter. Will you recharter?

 

Marc - you're right about the docs.

 

Keith - Non-charter docs should go to dispatch.

 

Marc - We'll review the charter.

 

ACTION:   Chairs to review the charter.

 

 

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

20 min * Additional Data related to an Emergency Call (Brian)=

http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss latest changes and if ready for WGLC

slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx=

 

Brian presented the slides, which provided a quick overview of how addit= ional data works, a covered changes to the doc.

 

Brian - The authors think this is done. No list contention. Just need to= do some editorial work.

 

Randall Gellens - The Call-Info header can be a sid. I can add text afte= r WGLC.

 

Roger Marshall - I don't think the doc has had a good review for a while= . Should request reviews from NENA and EENA since they rely on this doc.&nb= sp; We need two good reviews from the working group.

 

Marc - has anyone read it?

 

Brian - Barbara?

 

Barbara Stark - yes, I'll review it.

 

Hannes - Christer?

 

Christer Holmberg - I'm ok to do it.

 

ACTION:    Christer Holmberg and Barbara Stark to review = draft-ietf-ecrit-additional-data.

           Chairs= to coordinate reviews from NENA and EENA.

 

Randall - The reviews should be in parallel with WGLC.

 

Marc - We need new spin on draft.

 

Randall - I can do that.

 

ACTION:   Randall to fix editorial issues, and release the doc= ument. When the draft is available, start WGLC and reviewer reviews in para= llel.

 

Keith - Did this document raise the IANA registration table to … ?=

 

Brian - Yes

 

Keith - Was there a discussion in sipcore?

 

Brian - Assuming that there was, but I will raise the issue on sipcore l= ist

 

ACTION:   Brian to discuss IANA registration table on sipcore = list.

 

Keith - It shouldn't take place ad-hoc.

 

Brian - The document doesn't create a purpose table. I will raise the is= sue. It won't be added to the document until we get agreement.

 

 

-----------------------------------------------------------------------<= o:p>

10 min * (Brian) Updating Additional Data related to an Emergency Call u= sing Subscribe/Notify (Brian)

http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx

 

Brian presented.

 

Brian - The PSAP has to control rate of updates. Defines new URI. Send t= he subscription to. The event package is XML multi-part MIME, there is no n= ew definition here. Just a new block of data. If you send by reference,&nbs= p; can get it. No new mechanism.

 

There has been a fair amount of discussion. There are other working grou= p participants that want info-block, but then the PSAP couldn't control the= rate. The main advantage of this solution is that you get the filter mecha= nism.

 

I would like to adopt this document as a working group item.<= /p>

 

Marc - Who's read this document?

 

Room - 5 or so hands

 

Christer - I would like to adopt the draft. However, a user behind a NAT= has to register. However they don't get the credentials, it won't work. Th= at's the main issue. If you use INFO, then it's in the dialog, don't have t= hat problem. If you use SUBSCRIBE, there are issues with reaching the PSAP. In dialog,  it would go to P= SAP. This should be discussed. 

 

Brian - For handling devices that can't set up a server to receive a SUB= SCRIBE. The next version of the draft will say that they should use a serve= r outside of that. It's the presence problem, and can be solved the same wa= y - use an outside server. The problem with INFO - you have to create filters - copy all of the filters RFC - and= reproduce it for INFO.

 

ACTION: Brian to update the draft on how to solve the problem of devices= that can't set up a server to receive a SUBSCRIBE.

 

Christer - You need it for info package anyway.

 

Brian - I would have to quadruple the draft and copy everything from the= Filters RFC.

 

Brian - The most common occurrence of this is data-only. There is no ses= sion. In the eCall case, there is the call and data so there's a dialog.

 

Christer - You could establish a session. Updating data.

 

Brian - The PSAP needs to control that. The PSAP would create the sessio= n. The people along the line don't want updates. Only the responder does, b= ut  they aren't in the call path. The want updates after call is over.

 

Keith - Why is this emergency call specific? Only because the PSAP wants= to use it. ecrit should not solve the problem - transmit data once call is= in progress. There's a more general solution here.

 

Brian - You are saying that we need a generic RAI solution for updating = data in a SIP message.

 

Keith - Not necessarily. There are RAI solutions already there. It shoul= dn't be ecrit in terms of making decision.

 

Brian - Make chairs make that decision.

 

ACTION: Chairs to determine if a more general RAI solution should be app= lied.

 

Randall - If it's data only, it narrows the scope and fits better with t= he solution. It's a solution for sending data when you don't have sessions.=

 

Richard - Isn't this solved by additional-data itself - put it in the UR= I?

 

Brian - You don't want to just poll since you don't know when data chang= es.

 

Richard - Subscribe to a SIP URI.

 

Brian - That's what I said. It's a block of additional data. It's a URI,= you can subscribe to it.

 

Hannes - We had a discussion about data-only being sent around without s= ession. It was conflated with this draft on the list by Ivo.

 

Brian - When you look at discussion, the subject references data-only, n= ot additional-data. There's 7 blocks of data, only 2 would have updates.

 

Christer - The use case was data only. There is no session. <= /p>

 

Brian - INFO won't solve that problem since there's no session.

 

Christer - You can establish the session.

 

Brian, Hannes - No! We don't want to open a session.

 

Brian - there's an alternative that folks want to see. Need to define a = problem statement, get a charter item, and get drafts that fit.

 

ACTION: Brian to start the additional-data discussion on the list so tha= t a problem statement can be defined, and a charter item created.

 

Randall - Why is not in the data-only draft?

 

Brian - It was suggested that it be split out.

 

 

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

15 min. * Trustworthy Location Information (Bernard)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrite

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt

 

Bernard Aboba presented.

 

Bernard - There was an issue raised in WGLC, which ended today. Issue 15= - the definitions could be revised, made simpler. Any feedback?

 

Room had no feedback. 

 

Marc - Sounds like we're ready to go forward pending end of WGLC. <= /o:p>

 

Brian - I have a few more hours to get my comments in.

 

ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending an= y final WGLC comments.

 

 

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

15 min * eCall - background, current status, and requirements discussion= linked to current ETSI work (Ban Al-Bakri)

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt

 

Ban Al-Bakri presented.

 

Questions:

 

Christer - This is a use case with the session and additional data.

 

Ban - The PSAP can request additional data.

 

Christer - INFO would then be the appropriate mechanism. Maybe the solut= ion should be split into session based and non-session based.

 

Brian - Reasons for update that survive the call

 

Ban - The PSAP can request update to the MSD. Once the voice call is rel= eased, there may be a call back maybe.

 

Brian - Can the MSD call back? The PSAP is not interested in updates unl= ess there's an error. But the responders want the data. If you have updates= , the responders want them.

 

Ban - the EU requirement is that the PSAP should keep on the call until = responders are on the scene.

 

Randall - eCall requirements are different that requirements for updates= for sensor data - the sensor knows that there are updates, not the PSAP.

 

Hannes - I don't care about specific encoding - text or JSON. We can shi= p data around.

 

Hadriel Kaplan - Both you guys need to go up a level and describe how th= e responder gets the data. If they get it from the PSAP, then the SUBSCRIBE= goes to that.

 

Brian - The PSAP doesn't want to be in the path.

 

Hadriel - ASN.1 is a legal requirement?

 

Ban - Yes.

 

Hadriel - If the EC wants to support a SIP-based service, they should ju= st point to RFCs.

 

Randall - The more IETF gets into business of telling EC how to do eCall= , the less progress we make. We can tell them how SIP can solve it.

 

Hadriel - If you can't specify to the PSAPs, then we need a gateway.

 

ban - Should be transferred as a package. Need minimum impact on the net= work. Don't want extra network elements.

 

Hadriel - But if you are working with existing infrastructure.

 

Hannes - In US, the BES (?) data looks different than eCall data. <= /o:p>

 

Hadriel - Why is this specific to eCall? We should design globally.

 

Randall - Even if it's encoded in XML, it doesn't ensure that the vendor= 's implementation (like OnStar) would be clear. Can work towards commonalit= y, but can't just jump there.

 

Henning - The solution should be long-lived - 20 year old cars break dow= n. As you migrate with car model years. PSAP software is provided by a smal= l number of vendors. Need mechanism in place where gradual migration is pos= sible. Have you thought about that?

 

Ban - We have discussed this.  Too much work right now. =

 

Henning - In SIP we've tried to separate format. It's handled with a neg= otiation or a label, versioning scheme. You don't want to throw out the who= le thing if the format changes.

 

Keith - We will continue this discussion on the list. Be clear about tra= nsfer syntax or the encoding. Need to be specific.

 

ACTION: Continue eCall discussion on the list.

 

Brian - We'll define block of additional data as chunk of ASN.1, could w= e not also have XML with the same data? Multipart alternative.

 

Randall - Can use MIME type for ASN.1 and then can wrap it later to upgr= ade.

 

Brian - For data structures that have already been defined, put them in = a MIME block. Could and should define an XML block as an alternative. Allow= someone else to use the same idea, not in EU law.

 

Ban - 3gPP should specify which block to use.

 

Randall - Say how to do eCall the way it is now. And then how to do it m= ore generally.

 

Brian - Exactly.

 

Roger - Is there a draft to describe this?

 

Ban - The EC is funding this work. Please sign the attendance sheet - so= it can get in kind funding.

 

Keith - Have you checked with secretariat on this process? You should us= e the blue sheets.

 

Ban - It's ok, I've checked with the secretariat.

 

Marc - If you don't want to sign, just pass it on.

 

 

 

 

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

15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes)=

http://tools.ietf.org/id/draft-rosen-ecrit-ecall/

Intention: Discussion of draft & WG adoption question

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf

 

Randall Gellens presented.

 

ACN - Automatic crash notifications

 

Brian - The current draft is informational. If we split it, the eCall dr= aft would be normative. Would define block of additional data with MSD.

 

Ban - I support this, but the info draft will be …

 

Brian - will be ACN.

 

Marc - Split the docs?

 

Hannes - Randy's comment - We trying to make doc generic so it works eve= rywhere. Routing functionality, SIP setup is generic, but for specific vend= ors, they don't care.

 

Keith - ACN is not an emergency call?

 

Randall - It is.

 

Keith - How does this fit in the charter?

 

Randall - these are all emergency calls.

 

Ted Hardie - I agree with Keith. If you split into ACN and eCall, eCall = is specific regulatory environment, which the charter forbids work in. You = have to recharter to adopt eCall. You could adopt the ACN bits now.

 

Marc - chairs will work with ADs on recharters.

 

ACTION: Chairs to work with the ADs on rechartering to do specific eCall= work.

 

 

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

10 min * Uniform Resource Name (URN) extension for automatic and manual = Emergency Services (Roland)

draft-jesske-ecrit-ecall-urn-extension-01

Intention: Discussion of changes to draft

 

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx

 

Roland presented.

 

There's eCall for police, eCall for fire.

 

Ban - 3gpp has the requirement. However, haven't seen the requirement on= car manufacturers to provide this info. Needs to be regulated across Europ= e. There are liability issues here. When you have multiple categories, you = can't fork the voice call to all the categories. You need to route to the PSAP that supports eCall, and the= y find appropriate services. Defining multiple categories is in the network= , and is also regulated.

 

Roland - I have received similar comments. There are PSAPs that can supp= ort eCall and others not.

 

Henning Schulzrinne - There are two dimensions here - who gets the call?= Police, Fire; Automatic, Manual. You have combinatorial explosion problems= . Anytime you add a service (health monitoring (fallen can't get up), you h= ave to update this. We use this as a key in LoST, but we route on location, on language capabilities. this= leads to a non-scalable solution, and you have to have fallbacks, etc. If = we need a coarse-grain routing, we have mechanisms that do that without the= explosion.

 

Roland - We have an existing implementation, description in 3GPP. Drawba= ck currently. Don't want to redo anything at the IT level. If you only have= eCall implemented.

 

Henning - You are assuming a hierarchy, the more dimensions you have, th= e harder to determine a hierarchy. OnStar gets police, ambulance, and then = routes. If you add poison control, it would go to OnStar and they would dea= l with it. You need a responder hierarchy. We can change protocols. If it's not in LoST, add it. You make = complicated tradeoffs. For eCall, you don't route differently for automatic= and manual.

 

Keith - IMS sticks URN in the URI and doesn't use LoST. There are scenar= ios where neither of these work. My car needs to work in any country it goe= s to. Work in countries that don't support eCall, or support the first hier= archy of police, fire.

 

Ted Hardie - A URN service sos is a "what?". You are conflatin= g a "how?" Manual and Automatic are also "hows?". Need = to do in 2 urn namespaces to get "how" away from "what"= .

 

Hadriel - I'm agreeing with Ted and Keith. eCall shouldn't be in Brian's= draft.

 

Ban - Auto and Manual indicate the target. Could be different PSAPs.

 

Ted - It's not a different "what". sos.fire - who I want the r= esponse from. If automatic gives me a different responder, then it's differ= ent. If it's just a different PSAP, then it's not.

 

Henning - There are all kinds of things to route on. Fire department - t= he truck and the equipment, the people - are the same. In terms of trustwor= thiness…. The PSAPs use all sorts of differentiators. It's a gray zon= e. A URN is not the only thing to use. Not the details on agency, whether it was mediated by alarm company, not v= aluable in a URN. You can only have 1 hierarchy. Appropriate default respon= ses.

 

Ban - Need to keep mind in automatic, it's part of the flag.<= /p>

 

Henning - You need to look at the routing behaviors that you want, then = what are your tools to make the info available to the required parties. And= where is it available, where could it be added. If you look at PSTN - call= types - pay phone, prison. Labeled them … 

 

 

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

10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts= using the Session Initiation Protocol (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss recent updates to draft

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx

 

 

Brian presented.

 

Brian - Other than the discussion of using a block of additional data, I= think the doc is settled and is ready to go. No one has raised objections.=

 

Marc - Move to WGLC next week.

 

Brian - You have to do WGLC simultaneously with additional-data.

 

ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneou= sly with draft-ietf-ecrit-additional-data.

 

 

 

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

10 min * Service Coverage Scope for Service URN (Brian)

http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn= /

Intention: Discuss new draft

 

Brian presented.

 

Henning - What about transit police, or campus police, secret service, e= tc?

 

Brian - They have geographic boundaries.

 

Randall - But roads can be confusing - you think it's a public road, but= actually you need park police.

 

Ted - If it's based on location.

 

Brian - What if you are sitting in one of these buildings, but want the = state police.

 

Ted - You are conflating geographic dominion with different services. Fi= re service - halon versus water. It's a "what". Police provide di= fferent services - put that in a "what" rather than "where&q= uot;. Describe the "what" in the URN - for instance, drug-enforce= ment.

 

Brian - Interesting idea, but that isn't the way services are organized,= there is no taxonomy, I couldn't come up with a way to build a device. RIg= ht now people use phone numbers.

 

Ted - it's in people's brains.

 

Brian - I don't know how to deal with the taxonomy issues.

 

Ted - But this is muddying the service URN because there is muddiness in= the background.

 

Brian - there are different numbers for different services.

 

Ted - Some human will have to pick a department.

 

Brian - There's no solution.

 

Ted - If they need to call a specific phone number, they pick up the pho= ne. You know the difference between the park service and the police.

 

Keith - The draft goes into irrelevant geographic details. Say you want = the police force that handles kidnapping versus theft.

 

Brian - If we could just start over.

 

Keith - It's too late. But in each country has distinguished between the= m.

 

Marc - This discussion is cutting into your next presentation, brian.

 

Keith - Want to use something in the request URI, not the dialed number.=

 

Henning - Geography doesn't work. It's not clear to a citizen. There's c= omingling. If someone calls 911, and if I forward their call to the metro p= olice. There is no reason for the cities have the same organizations - it's= database identifiers.

 

Brian - This is an external problem. Start with a service phone number, = map to service URN, get a URI to route the call. The current drafts don't s= olve this.

 

Henning - Is it solvable?

 

Brian - You want a service number for kidnapping.

 

Hadriel - You call 911

 

Brian - This issue isn't applicable for US.

 

Hadriel - We don't need to convert to URN. Dial Emergency on your phone,= and it works. If you need to call DEA - then you can look that up and call= . It's not a real emergency.

 

Marc - Take to the list.

 

ACTION: discuss raft-mongrain-ecrit-service-coverage-scope-urn on the ma= iling list.

 

 

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

10 min * A LoST extension to support return of complete and similar loca= tion info (Brian)

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location

Intention: Discussion of changes to draft

slides:

 

Brian presented.

 

Is there sufficient interest here? The NENA guys are interested.

 

Marc - How many people have read?

 

2 or so

 

Brian - please read and comment on list.

 

ACTION: working group to read draft-marshall-ecrit-similar-location and = comment on the list.

 

Randall - Is this the same proposal that came up in geopriv?<= /p>

 

Brian - This is a LoST thing. Not geopriv.

 

Barbara - I read this draft, and my colleague has asked me to support it= . I thought it looked good.

 

 

 

 

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

5 min * Open Discussion

 

No questions

 

[EOM]

 

 

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

////////////////////////////////////////////////////////////////////////= ///

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

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

Detailed meeting notes as follows, by Randall Gellens

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

 

Here are my notes from the ecrit session:

 

•           Upda= ted milestones

•           Keit= h Drage comments that the current milestones have little relationship to th= e current charter of the group; suggests rechartering if the group continue= s to work on such drafts, or else such drafts should go to DISPATCH

 

•           Bria= n Rosen presents on status of additional-data draft

•           Edit= orial revisions from Randy were lost in recent update from Hannes

•           Rand= y will update document this week; WGLC will start next week

•           Chri= ster and Barbara agree to do reviews

 

•           Bria= n Rosen presented on sub-not draft

•           Draf= t proposes using subscribe/notify to allow updated sensor data to be sent

•           Uses= extension mechanism from Additional-Data to allow subscribe address for up= dates to be sent as an additional-data block (as per the additional-data dr= aft)

•           Allo= ws PSAP (or other recipient) to control rate

•           Bria= n asks for WG adoption

•           Chri= ster says he has an issue: data updates don't go in session, could be a pro= blem with credentials and access (separate credentials needed to successful= ly subscribe, server may not be accessible to arbitrary clients).  Bri= an says in that case the device uploads the update to an externally-accessible server and sends= an address on that server

•           Chri= ster prefers to send updates in INFO in the session, but Brian objects beca= use there is no mechanism now for PSAPs (or other recipient) to set filter/= throttle to control rate of updates, and also because in the data-only case= there is no session, and also because the party interested in updates may not be the P= SAP itself but rather a responder (who isn't in the call path)

•           Keit= h Drage objects to this being done in ECRIT, saying this is a general probl= em for which there are general solutions

•           Rand= y suggests that this should be conceptualized not as an extension to additi= onal-data but rather data-only (sensor data sent as CAP in MESSAGE where th= ere is no session), as this narrows the scope and focuses the problem

•           Much= further discussion

 

•           Bern= ard presents on trustworthy-location

•           Adde= d discussions of place shifting, location shifting, time shifting, etc., fr= om previous Martin Thomson drafts

•           Adde= d discussion of location theft (attacker uses target's location as his/her = own)

•           Docu= ment passed WGLC

 

•           Ban = presented on eCall on behalf of ETSI (what it is, what they want from IETF)

•           Some= questions from audience regarding requirements Ban mentioned for PSAP to r= equest actions by the IVS and how this fits into Brian's update proposal.

•           Rand= y says that the requirements that Brian is solving (where sensor knows it h= as updates) and in eCall (where PSAP knows what it wants) are different and= we should not get into details now

•           Comm= ents from audience on ASN.1 encoding and why can't XML be used

•           Henn= ing has comments regarding ASN.1 and XML being temporary and a means is nee= ded to upgrade later

•           Keit= h Drage says we need to separate the issues of mechanism and encoding

•           Bria= n suggests that the IETF define two ways of transporting the same data: ASN= .1 for eCall and XML for anyone else

•           Rand= y suggests that this can be done but needs to be carefully done so as not t= o appear as though the IETF is messing in eCall

 

•           Rand= y presented on the ecall draft

•           Keit= h asks how any of this is in charter

•           Ted = Hardie points to charter language that says the group does not work on item= s that are specific to a regulatory environment, and hence the group could = adopt the ACN bits but not the ecall parts

•           Chai= rs will take this under advisement and consider rechartering

 

•           Rola= nd (D-T) presented on the ecall URN extension for subservices

•           Prop= oses to add police/fire/ambulance/etc. into the ecall URN (as proposed in t= he eCall draft), either before or after the 'ecall' portion

•           Ban = asks about the concept before the draft; says there is a 3GPP requirement a= nd Stage 3 text providing for subservices but that this doesn't apply to ca= rs, and further any such facility (e.g., cars reporting that they are on fi= re) needs to be standardized.  Ban also points out that this would be a problem fo= r the MNO to route the call -- currently eCall calls are routed to an eCall= -capable PSAP; how would an eCall with a subservice be routed?

•           Henn= ing says that there are two dimensions to the problem: call routing (ecalls= are routed to ecall-capable PSAP and it's not likely that there will be de= dicated PSAPs for eCalls from vehicles on fire, vehicles with poisoning vic= tims, etc.) and that this presents a combinatorial nightmare.  Henning suggests using= other mechanisms (such as Caller-Preferences) to pass this information but= not in the URN.

•           Keit= h Drage says this needs to work in countries that don't support eCall, and = in countries that don't support police/fire/ambulance/etc. as the top level.

•           Ted = Hardie says don't conflate the what (sos emergency call) with the how (eCal= l, police, fire, ambulance)

•           Hadr= ien says even automatic and manual should not be in the URN either

•           Ted = says routing to a different place is a different "how" and not a = different "what" and so manual vs automatic shouldn't be in the U= RN but 'police', 'fire', etc. are different "what"s.

•           Henn= ing echoes Ted's point that the URN is supposed to indicate who you expect = to show up (police, fire, etc.)

•           Henn= ing proposes using a different mechanism for conveying this information (an= d discusses the old PSTN concept of call types such as pay phone, prison, e= tc.)

•           Comm= ent to use feature-tag

 

•           Bria= n presents on data-only draft

•           Data= -only call that does not create a session (carries sensor data as CAP messa= ge)

•           Draf= t changed how CAP message is sent: now as a block of additional-data (and h= ence can be passed by value or reference)

 

•           draf= t-mongrain-ecrit-service-coverage-scope-urn-00

•           Bria= n discusses service coverage scope (geographic scope), so-called "A&qu= ot; level of geoprif PIDF-LO, to distinguish from neighborhood watch up to = borough, to city or town, to county or parish, to state or region, to entir= e country

•           Ted = objects that this is conflating geographic division with type of service; i= f different police forces provide the same type of response, it doesn't bel= ong in the "what" difference

•           Bria= n says that's not how services are organized today, where different numbers= are used

•           Bria= n and Ted argue about architectural purity versus pragmatics

•           Keit= h says we do need something in the Request-URI so IMS can use it, just not = the dialed number

•           Bria= n says this comes down to: we start with a service number that a user dials= , which is mapped to a service URN, which is used to route to a responder

•           More= debate, especially from Henning and Ted versus Brian

 

•           Bria= n presents on similar-location

•           Defi= nes an extension to LoST so that location information can be included in a = LoST response to a FindService query

•           Uses= : provide missing fields if location information in request is valid but no= t complete ("The crrect representation is") -- used when provisio= ning

•           also= provide alternatives when location in request is not valid (a "Did yo= u mean?")

 

--

Randall Gellens

 

 

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC3A6680SEAEXMB2telecomsy_-- From keith.drage@alcatel-lucent.com Sun Aug 4 14:13:57 2013 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 71A0521F8F4A for ; Sun, 4 Aug 2013 14:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UYZmeW0Slsha for ; Sun, 4 Aug 2013 14:13:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B95DD21E8093 for ; Sun, 4 Aug 2013 14:13:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r74LDXeJ020269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Aug 2013 16:13:39 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r74LDXbv019369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Aug 2013 23:13:33 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 4 Aug 2013 23:13:32 +0200 From: "DRAGE, Keith (Keith)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: IETF87 Berlin: ECRIT Minutes for 07/29 meeting Thread-Index: Ac6OhCQgz29EQSgj+0yOnhJk0Ba5JwC00COA Date: Sun, 4 Aug 2013 21:13:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07BE83@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B07BE83FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 21:13:57 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B07BE83FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In regard to: "ACTION: Hannes to send milestone updates to the mailing list. - draft-ietf-ecrit-trustworthy-location - draft-ietf-ecrit-unauthenticated-access - draft-ietf-ecrit-country-emg-urn" While I do have have any issue with keeping the working group informed, the= final say on milestones is between the AD and the working group chairs, no= ne of which have been given consequent actions, so I am unclear of what the= result of the above action is. There needs to be a consequent intended act= ion. In regard to: "There was a discussion about splitting the document into eCall and ACN dra= fts. An eCall specific draft is currently not covered in the charter. ACTION: Chairs to work with the ADs on rechartering to do specific eCall wo= rk. " While I agree with the comment from Ted that the eCall specific work is out= of charter, I am also of the view that the ACN work is out of the charter = for other reasons, and I said at the mic that it was all out of scope. Furt= her there are good reasons for saying ACN should be dispatched first. Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: 01 August 2013 07:56 To: ecrit@ietf.org Cc: Randall Gellens (randy@qti.qualcomm.com); A. Jean Mahoney (mahoney@nost= rum.com) Subject: [Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting Minutes for ECRIT WG Meeting, IETF87 Berlin, meeting date 7/29/2013, 13:00-= 15:00 If you have any additions or modifications to these minutes, please let Roger & Marc know via email. These minutes, along with more detailed notes= are pasted below, and are also posted to the IETF87 meeting materials page. --_000_949EF20990823C4C85C18D59AA11AD8B07BE83FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In regard to:=

 

“ACTION: Hannes to send mileston= e updates to the mailing list.

 

 - draft-ietf-ecrit-trustworthy-l= ocation

 

- draft-ietf-ecrit-unauthenticated-acc= ess

 

- draft-ietf-ecrit-country-emg-urnR= 21;

 

While I do have have any issue with ke= eping the working group informed, the final say on milestones is between th= e AD and the working group chairs, none of which have been given consequent actions, so I am un= clear of what the result of the above action is. There needs to be a conseq= uent intended action.

 

In regard to:=

 

“There was a dis= cussion about splitting the document into eCall and ACN drafts. An eCall specifi= c draft is currently not covered in the charter.

 

ACTION: Chairs to work with the ADs on rechartering to do= specific eCall work.

= 220;

 

While I agree with the comment from Te= d that the eCall specific work is out of charter, I am also of the view tha= t the ACN work is out of the chart= er for other reasons, and I said at the mic that it was all out of scope. F= urther there are good reasons for saying ACN should be dispatched fir= st.

 

Keith

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf Of Roger Marshall
Sent: 01 August 2013 07:56 To: ecrit@ietf.org
Cc: Randall Gellens (randy@q= ti.qualcomm.com); A. Jean Mahoney (mahoney@nostrum.com)
Subject: [Ecrit] IETF87 Berl= in: ECRIT Minutes for 07/29 meeting

 

Minutes for ECRIT WG Meeting, IETF87 Berlin, meeting date 7/2= 9/2013, 13:00-15:00

 

If you have any additions or modifications to these minutes, please= let

Roger & Marc know via email.  These minutes, along with mo= re detailed notes are pasted below, and are also posted to the IETF87<= /o:p>

meeting materials page.

 

--_000_949EF20990823C4C85C18D59AA11AD8B07BE83FR712WXCHMBA11zeu_-- From christer.holmberg@ericsson.com Tue Aug 6 07:45:06 2013 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 6F3FE21F9A19 for ; Tue, 6 Aug 2013 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 eZoRmQ3cvBHy for ; Tue, 6 Aug 2013 07:45:00 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3706421F99FD for ; Tue, 6 Aug 2013 07:44:50 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-68-52010be2d30c Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A3.FC.19388.2EB01025; Tue, 6 Aug 2013 16:44:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 16:44:48 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 Thread-Index: Ac6Sss0vFs+I00HHTNynzH+gXjYA8Q== Date: Tue, 6 Aug 2013 14:44:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41E812ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvre4jbsYgg5mLRC0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRl9HK0vBbfWK/bPCGxi/KncxcnJICJhIvF7xlwXCFpO4cG89 WxcjF4eQwGFGiV/XPzNCOIsZJU4cWAxUxcHBJmAh0f1PG6RBREBVYsOZlYwgYWGBPImHPxMg wsUSfZsfMkLYehLXLt5nBilhEVCRmHSnFiTMK+ArsefHdmYQmxFo7fdTa5hAbGYBcYkPB68z Q5wjILFkz3koW1Ti5eN/rBC2ksSPDZdYIOrzJWad28kMMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUje25iZk56ufkmRmDAH9zy22AH46b7YocY pTlYlMR5N+udCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOPfK1jmdcSsVHZ7MrDpxrP5n 0uU36T/cdrBE+abcP+fwZOkS8Wd7ysNenYlYe8zqCnNv1drF4XvyNhp9nsrZd/KPPuvZtkIR xYtfH03znJtYcOlkxnue8urdHI6Fy7w+VJ5cJFuiuMjLccu/pmMxwlv/Tbh3fOLyJ1K6Vzbf 5G6smiC27MuT4I1KLMUZiYZazEXFiQCwtgg+RgIAAA== Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 06 Aug 2013 14:45:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41E812ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A question on the scope of the Contact URI, defined in section 3.1.5 of dra= ft-ietf-ecrit-additional-data-11.txt. Is the Contact URI supposed by the PSAP when making callbacks? If the value represents a "service provider", should PSAP callbacks also be= made to the service provider? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C41E812ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A question on the scope of the Contact URI, defined in section 3= .1.5 of draft-ietf-ecrit-additional-data-11.txt.

 

Is the Contact URI supposed by the PSAP when making callbacks?

 

If the value represents a “service provider”, should= PSAP callbacks also be made to the service provider?

 

Rega= rds,

 

Chri= ster

 

--_000_7594FB04B1934943A5C02806D1A2204B1C41E812ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Aug 6 07:48:28 2013 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 78AF521F99EC for ; Tue, 6 Aug 2013 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 gTaUV9HY9tRR for ; Tue, 6 Aug 2013 07:48:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC2D21F9E9C for ; Tue, 6 Aug 2013 07:48:15 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-a1-52010cae867c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A1.5D.19388.EAC01025; Tue, 6 Aug 2013 16:48:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 16:48:14 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 Thread-Index: Ac6Ss7RGKH4c9vYBRvaO2LXJyDkPvw== Date: Tue, 6 Aug 2013 14:48:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41E829ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre56HsYggxcPuS0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpmtWQVN6hWH5l5lb2BcrdzFyMkhIWAisf5hEzOELSZx4d56 ti5GLg4hgcOMEi9v/mOCcBYzSszcehXI4eBgE7CQ6P6nDdIgIqAqseHMSkYQW1hgIaPExBtS IPUiAssYJZoO3GQFqRcR0JM49ccZpIZFQEVixawJLCA2r4CvxPfFc1lBbEagxd9PrWECsZkF xCU+HLwOdZCAxJI956FsUYmXj/+xQthKEj82XGKBqM+XWLLvHBvETEGJkzOfsExgFJqFZNQs JGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZOenl5psYgUF/cMtvgx2M m+6LHWKU5mBREufdrHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj0Qfft3JzpNbL/Lvg U18q7tcsP2OLuqL01Jv8PmdTuF0u6s35y3S4elN+wSblux/fb8ySEZktNeVl/HN149UXNwdV Miz+sGiD/b1lUxR4WFU3T27eeN7XjueayOlrX11neZ/fUPu207/FdP/jde6Xr4pNnZir86l2 2hs+xrotRi+Nnk86odairMRSnJFoqMVcVJwIADiPV9xIAgAA Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 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, 06 Aug 2013 14:48:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41E829ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In SIP, it is possible to indicate supported languages using the "language"= media feature tag, defined in RFC 3840. Is the semantics different from the data provider language defined in the a= dditional-data draft? Do we need to say something about which/how to use? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C41E829ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In SIP, it is possible to indicate supported languages using the= “language” media feature tag, defined in RFC 3840.<= /span>

 

Is the semantics different from the data provider language defin= ed in the additional-data draft?

 

Do we need to say something about which/how to use?

 

Rega= rds,

 

Chri= ster

 

--_000_7594FB04B1934943A5C02806D1A2204B1C41E829ESESSMB209erics_-- From br@brianrosen.net Tue Aug 6 08:33:51 2013 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 0C26421F9D34 for ; Tue, 6 Aug 2013 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO5wo5o4wrxd for ; Tue, 6 Aug 2013 08:33:45 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0FA21F8B04 for ; Tue, 6 Aug 2013 08:33:45 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so880122pab.7 for ; Tue, 06 Aug 2013 08:33:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2EXlMuOz8jRHDb4mxrF+8UqPCbt+61JPVqtPFWlRDJ4=; b=oQLkHw/aP9KNY1BeKgFzpsZDI0tSPLhJI6GcSBtehxjruuayvy4mZURCjy+JA1hkCu mJ/OzOhawq4YUhPjKjucGu3lpNku89gf9BQ6pctEfIXKtn7xtfnk6WwNYWcNuieYzF/8 zS7gFWd2qmwdsDR9zqx7mf03LNiZHX8DMNbJXBHEXNVGnL1K0gQPm4eE2AYbELEh+2I2 YZKw48S2yLI+3zbjTOHFzLSoD1xfBmHGy37wSMDdtYbPJfdnaFQ22kB90jkKEZoMed2P 9pDjJisWbeAhUpOP7kKSCd6zSLmk55PPIgIks1olWJ02NDdNV2oAatYVzTL5pXntI79h T+aQ== X-Gm-Message-State: ALoCoQkC77FLI1baW/sFkeL64hUYyGuVs/KKiWeORYrzSsl0Tl5Axi9WQc5Z4I99tBOdlwVbCPjl MIME-Version: 1.0 X-Received: by 10.68.194.104 with SMTP id hv8mr2107536pbc.168.1375803225012; Tue, 06 Aug 2013 08:33:45 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 08:33:44 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se> Date: Tue, 6 Aug 2013 11:33:44 -0400 Message-ID: From: Brian Rosen To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b15af798214dd04e3492666 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 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, 06 Aug 2013 15:33:51 -0000 --047d7b15af798214dd04e3492666 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That feature is not the spoken or signed or typed language in the media. There is an ongoing effort to provide a facility to negotiate those, but even still, it's useful to know in advance of a call what languages the service provider can handle. Brian On Tuesday, August 6, 2013, Christer Holmberg wrote: > Hi,**** > > ** ** > > In SIP, it is possible to indicate supported languages using the > =93language=94 media feature tag, defined in RFC 3840.**** > > ** ** > > Is the semantics different from the data provider language defined in the > additional-data draft?**** > > ** ** > > Do we need to say something about which/how to use?**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > --047d7b15af798214dd04e3492666 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That feature is not the spoken or signed or typed language in the media. = =A0There is an ongoing effort to provide a facility to negotiate those, but= even still, it's useful to know in advance of a call what languages th= e service provider can handle.

Brian

On Tuesday, August 6, 2013, Christ= er Holmberg wrote:

H= i,

<= u>=A0

I= n SIP, it is possible to indicate supported languages using the =93language= =94 media feature tag, defined in RFC 3840.

<= u>=A0

I= s the semantics different from the data provider language defined in the ad= ditional-data draft?

<= u>=A0

D= o we need to say something about which/how to use?

<= u>=A0

Regards,<= u>

=A0

Christer<= u>

=A0

--047d7b15af798214dd04e3492666-- From christer.holmberg@ericsson.com Tue Aug 6 08:49:46 2013 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 7F57221F997D for ; Tue, 6 Aug 2013 08:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 6IS5IFZmElrv for ; Tue, 6 Aug 2013 08:49:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA47021F93F3 for ; Tue, 6 Aug 2013 08:49:40 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-78-52011b139143 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.D3.19388.31B11025; Tue, 6 Aug 2013 17:49:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 17:49:39 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 Thread-Index: Ac6Ss7RGKH4c9vYBRvaO2LXJyDkPv///67sAgAAl+rw= Date: Tue, 6 Aug 2013 15:49:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41E9B5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41E9B5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvra6INGOQwdZ9rBZP709js2hc9JTV gcnj/re/7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4seYGS8FL3YpHn+8xNzDu1+hi5OSQEDCR 2NW6kAXCFpO4cG89G4gtJHCYUeLsdc8uRi4gezGjRFPHMqAEBwebgIVE9z9tkBoRAWWJnbc6 2UHCzED2ic54kHJhgbWMEk//LWMEcUQE1jFK3L21jR2iwUri/ZZWsAUsAioSH+40gsV5BXwl ej7PZIRYNolR4tbX+WBFnAKBEnOX/AK7jhHouu+n1jCB2MwC4hK3nsxngrhaQGLJnvPMELao xMvH/1ghavIlPr3ZxgyxQFDi5MwnLBMYRWYhaZ+FpGwWkjKIuIHE+3PzmSFsbYllC19D2foS G7+cZUQWX8DIvoqRPTcxMye93HwTIzB6Dm75bbCDcdN9sUOM0hwsSuK8m/XOBAoJpCeWpGan phakFsUXleakFh9iZOLglGpgLBRU3aUeHu7AWp0Uw2GxdcbGSf83fvgk+NiB8eyaG9fOcveL rxHtXWzpuTSwrr7SLn3K+lvPrn9eGPT1MuODFXe/Ma27c27ig1ClpaIx35YEpgSoL3Lgfc0v /9fd7tA/gR7dRpuWDzsr9D9JsrEFOmlfC3nG/83wyew7a6rmsQjV7uHoX5Oer8RSnJFoqMVc VJwIAIKdBKJsAgAA Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 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, 06 Aug 2013 15:49:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41E9B5ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The language media feature tag does not indicate the media language either = - it indicates the languages the caller can handle. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Brian Rosen [br@brianrosen.net] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: ecrit@ietf.org [ecrit@ietf.org] Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possi= ble conflict between language feature tag and data provider language, defin= ed in section 3.1.6 That feature is not the spoken or signed or typed language in the media. T= here is an ongoing effort to provide a facility to negotiate those, but eve= n still, it's useful to know in advance of a call what languages the servic= e provider can handle. Brian On Tuesday, August 6, 2013, Christer Holmberg wrote: Hi, In SIP, it is possible to indicate supported languages using the =93languag= e=94 media feature tag, defined in RFC 3840. Is the semantics different from the data provider language defined in the a= dditional-data draft? Do we need to say something about which/how to use? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C41E9B5ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
 
The language media feature tag does not indicat= e the media language either - it indicates the languages the caller can han= dle.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Brian Rosen [br@brianrosen.net]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: ecrit@ietf.org [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n possible conflict between language feature tag and data provider language= , defined in section 3.1.6
That feature is not the spoken or signed or typed language in the medi= a.  There is an ongoing effort to provide a facility to negotiate thos= e, but even still, it's useful to know in advance of a call what languages = the service provider can handle.

Brian

On Tuesday, August 6, 2013, Christer Holmberg wrote:

Hi,

 

In SIP, it is possible to indicate supported languages using the =93lang= uage=94 media feature tag, defined in RFC 3840.

 

Is the semantics different from the data provider language defined in th= e additional-data draft?

 

Do we need to say something about which/how to use?=

 

Regards,

 <= u>

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C41E9B5ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Aug 6 08:57:21 2013 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 DC33821F9E4F for ; Tue, 6 Aug 2013 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 uVVlWdALIjt5 for ; Tue, 6 Aug 2013 08:57:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE7621F99A2 for ; Tue, 6 Aug 2013 08:56:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-99-52011cca1c32 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1C.B5.05990.ACC11025; Tue, 6 Aug 2013 17:56:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 17:56:57 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 Thread-Index: Ac6Ss7RGKH4c9vYBRvaO2LXJyDkPv///67sAgAAl+ryAAAIL3A== Date: Tue, 6 Aug 2013 15:56:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41EAC6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1C41E9B5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41E9B5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41EAC6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre5pGcYgg//zOCye3p/GZtG46Cmr A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx8exvloLPVhVfVgs0MH4z7mLk5JAQMJH4 u+g/C4QtJnHh3nq2LkYuDiGBw4wSjf+6WSGcxYwSX89uYepi5OBgE7CQ6P6nDdIgIqAssfNW JztImBnIPtEZD1IuLLCWUeLpv2WMII6IwDpGibu3trFDNDhJfNl9mhHEZhFQkfj07RobiM0r 4CvReGUKO8Sy64wSy5YcZwJJcAr4SfT1TWQFsRmBzvt+ag1YnFlAXOLWk/lMEGcLSCzZc54Z whaVePn4HytETb7EvtvHmSEWCEqcnPmEZQKjyCwk7bOQlM1CUgYRN5B4f24+M4StLbFs4Wso W19i45ezjMjiCxjZVzGy5yZm5qSXG21iBEbPwS2/VXcw3jkncohRmoNFSZx3s96ZQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MfsxLd+puvTv36NEfU/nOqX3l73ZPT1RWXTLn6dkFeyUi LjH4rD5w5U1vdm9ooOYUd0YRztrSdKX6T/7m3/LZJztvEr075fnDDr+oj0eWCl39WrLWim1t 3pnezAMMRXXWwVVvZyY52be85Gb7Ov05r8cKh+wjKpIKc/wOdSXpTHmldLQ4IjBFiaU4I9FQ i7moOBEAq5LVAWwCAAA= Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 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, 06 Aug 2013 15:57:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41EAC6ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As a side note, in MMUSIC it was suggested to define a new SDP attribute to= indicate language capabilities, but it was rejected. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Christer Holmberg [christer.holmberg@ericsson.com] To: Brian Rosen [br@brianrosen.net] CC: ecrit_ietf.org [ecrit@ietf.org] Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possi= ble conflict between language feature tag and data provider language, defin= ed in section 3.1.6 Hi, The language media feature tag does not indicate the media language either = - it indicates the languages the caller can handle. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Brian Rosen [br@brianrosen.net] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: ecrit@ietf.org [ecrit@ietf.org] Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possi= ble conflict between language feature tag and data provider language, defin= ed in section 3.1.6 That feature is not the spoken or signed or typed language in the media. T= here is an ongoing effort to provide a facility to negotiate those, but eve= n still, it's useful to know in advance of a call what languages the servic= e provider can handle. Brian On Tuesday, August 6, 2013, Christer Holmberg wrote: Hi, In SIP, it is possible to indicate supported languages using the =93languag= e=94 media feature tag, defined in RFC 3840. Is the semantics different from the data provider language defined in the a= dditional-data draft? Do we need to say something about which/how to use? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C41EAC6ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As a side note, in MMUSIC it was suggested to define = a new SDP attribute to indicate language capabilities, but it was rejected.=
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Christer Holmberg [christer.holmberg@ericsson.com]
To: Brian Rosen [br@brianrosen.net]
CC: ecrit_ietf.org [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n possible conflict between language feature tag and data provider language= , defined in section 3.1.6
Hi,
 
The language media feature tag does not indicat= e the media language either - it indicates the languages the caller can han= dle.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Brian Rosen [br@brianrosen.net]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: ecrit@ietf.org [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n possible conflict between language feature tag and data provider language= , defined in section 3.1.6
That feature is not the spoken or signed or typed language in the medi= a.  There is an ongoing effort to provide a facility to negotiate thos= e, but even still, it's useful to know in advance of a call what languages = the service provider can handle.

Brian

On Tuesday, August 6, 2013, Christer Holmberg wrote:

Hi,

 

In SIP, it is possible to indicate supported languages using the =93lang= uage=94 media feature tag, defined in RFC 3840.

 

Is the semantics different from the data provider language defined in th= e additional-data draft?

 

Do we need to say something about which/how to use?=

 

Regards,

 <= u>

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C41EAC6ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Aug 6 10:54:14 2013 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 8F9CD21E80A6 for ; Tue, 6 Aug 2013 10:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 r+iZZ1gP0Yp8 for ; Tue, 6 Aug 2013 10:54:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE921E80B0 for ; Tue, 6 Aug 2013 10:53:15 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-69-5201380a3a07 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.5F.05990.A0831025; Tue, 6 Aug 2013 19:53:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 19:53:14 +0200 From: Christer Holmberg To: ecrit Thread-Topic: draft-ietf-ecrit-additional-data-11: multiple entities adding data Thread-Index: Ac6SzdKPrhbeISSaR+SyOz+eqlcDSQ== Date: Tue, 6 Aug 2013 17:53:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41F05AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvrS6XBWOQQftvJYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsa5lB3vBW6GKpe/vsjUwrhLoYuTkkBAwkXg47wIThC0mceHe erYuRi4OIYHDjBLztp1lh3AWM0qs//SMsYuRg4NNwEKi+582SIOIgJTE37sHWEDCwgLeEvPa oMJBErf7jzJD2HoS17rfsoPYLAIqEi19p9hAynkFfCWW3vUBCTMCrf1+ag3YCcwC4hK3nsyH OkdAYsme88wQtqjEy8f/WCFq8iW+btzCCGLzCghKnJz5hGUCo+AsJO2zkJTNQlIGEdeTuDF1 ChuErS2xbOFrZghbV2LGv0MsyOILGNlXMbLnJmbmpJcbbWIEhvbBLb9VdzDeOSdyiFGag0VJ nHez3plAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwduzmOZaeZHFr9iDdW0/h85LHeDx3q x3IEJeyfV3zR+fv2/ol7G1c37D21K+rIUp2tV23avTQXf3wYP/9nko/179WMU0vZNwVUXvxc c0gleaLr59KGi5/vzFIKn7m1hHffmtncC1aeF5zinq68aZnDv9pImU07dNXMVxU28Di1n8nz CQqetzxDiaU4I9FQi7moOBEAGfOJnjsCAAA= Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding 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: Tue, 06 Aug 2013 17:54:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41F05AESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The draft talks about all kind of different entities that might add additio= nal data to an emergency call. First, I think it would be good to have some pictures showing a few differe= nt scenarios. Second, the draft doesn't seem to describe the case where multiple entities= are adding data - for the same call. Will multiple MIMEs etc be used, are = there restrictions, etc etc etc? OR, is it not allowed to begin with? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41F05AESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The draft talks about all kind of different ent= ities that might add additional data to an emergency call.
 
First, I think it would be good to have some pi= ctures showing a few different scenarios.
 
Second, the draft doesn't seem to describe the = case where multiple entities are adding data - for the same call. Will mult= iple MIMEs etc be used, are there restrictions, etc etc etc? OR, is it not = allowed to begin with?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41F05AESESSMB209erics_-- From br@brianrosen.net Tue Aug 6 11:12:03 2013 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 5403221E8098 for ; Tue, 6 Aug 2013 11:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzS-xFP+JYDw for ; Tue, 6 Aug 2013 11:11:58 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE721F9C13 for ; Tue, 6 Aug 2013 11:11:58 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so786687pbb.34 for ; Tue, 06 Aug 2013 11:11:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=//gjLeBD8eMQtN978/zVOzI47dH6bWgPTXQckht0I5w=; b=MNcBUrik6UHigsfA1y0N6DhPdD5TA/4XmFesM04NvflZ7/QpxyRUCANr7i2/1neH8Z VwB4rBw4+r8pxij4d+yoqmVpUBFwAanZ/ewqz+XoAoCv7u2BzPf8BUML7MvGeW6A/gEF OWoPVQ4OGQ3fHWGqfXzXyHGO0+iBQMRjdqvaIiRjJDq5JLFdb1aNEndV2lWi9Lgi4bvQ E3vkrbc4OXYcNE4i8gB+k6pw9+aGrfHDX2FoK2FP7CeV2STW2jcKWBa5fRl/seZ+jqLi kNbgn61SzHb1Bcb/lnYU07rbCSCfnbiCQSala369ah+nc/ryLaH/agdViKtGcItHj1zm SVCw== X-Gm-Message-State: ALoCoQnIoOMFWrbTlAuK7klSBJClLKVFYQim9w1NvSoKOczPfM7jY2eWb0K8qInOQFHHzCMYf1F0 MIME-Version: 1.0 X-Received: by 10.68.223.225 with SMTP id qx1mr2834796pbc.157.1375812717863; Tue, 06 Aug 2013 11:11:57 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Tue, 6 Aug 2013 11:11:57 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> Date: Tue, 6 Aug 2013 14:11:57 -0400 Message-ID: From: Brian Rosen To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b16051553770e04e34b5c16 Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding 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: Tue, 06 Aug 2013 18:12:03 -0000 --047d7b16051553770e04e34b5c16 Content-Type: text/plain; charset=ISO-8859-1 Not sure pictures in ascii art would help, but more words might. My usual example is a medical sensor based device adds some, a specialized service provider who services the device adds some and a communications service provider adds some. all of thise go in the SIP message. then the access network sends some in the PIDF. With respect to multiple entities adding data, proxies can't add bodies, but B2BUAs can. However, you have pointed out a problem that arose in the evolution of the mechanism. Originally, there was an outer envelope wit the blocks inside it. That would let us know the source of each block because the data provider block is required. The current mechanism doesn't have that. It's a problem. Brian On Tuesday, August 6, 2013, Christer Holmberg wrote: > Hi, > > The draft talks about all kind of different entities that might add > additional data to an emergency call. > > First, I think it would be good to have some pictures showing a > few different scenarios. > > Second, the draft doesn't seem to describe the case where multiple > entities are adding data - for the same call. Will multiple MIMEs etc be > used, are there restrictions, etc etc etc? OR, is it not allowed to begin > with? > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > --047d7b16051553770e04e34b5c16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure pictures in ascii art would help, but more words might.

My usual example is a medical sensor based device adds some, a spe= cialized service provider who services the device adds some and a communica= tions service provider adds some. =A0all of thise go in the SIP message. = =A0then the access network sends some in the PIDF.

With respect to multiple entities adding data,=A0proxie= s can't add bodies, but B2BUAs can. =A0

H= owever, you have pointed out a problem that arose in the evolution of the m= echanism. =A0Originally, there was an outer envelope wit the blocks inside = it. =A0That would let us know the source of each block because the data pro= vider block is required. =A0 The current mechanism doesn't have that. = =A0It's a problem.

Brian

On Tuesday,= August 6, 2013, Christer Holmberg wrote:
Hi,
=A0
The draft talks about all kind of different ent= ities that might add additional data to an emergency call.
=A0
First, I think it would be good to have some pi= ctures showing a few=A0different scenarios.
=A0
Second, the draft doesn't seem to describe = the case where multiple entities are adding data - for the same call. Will = multiple MIMEs etc be used, are there restrictions, etc etc etc? OR, is it = not allowed to begin with?
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)
--047d7b16051553770e04e34b5c16-- From christer.holmberg@ericsson.com Tue Aug 6 23:32:54 2013 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 E8E2C11E80C5 for ; Tue, 6 Aug 2013 23:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.391, 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 3XquQ9ZR3xoW for ; Tue, 6 Aug 2013 23:32:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 091A221E8055 for ; Tue, 6 Aug 2013 23:32:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-c2-5201ea1011b5 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D4.8F.05990.01AE1025; Wed, 7 Aug 2013 08:32:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 08:32:47 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data Thread-Index: Ac6SzdKPrhbeISSaR+SyOz+eqlcDSf//47OA//8Q3tA= Date: Wed, 7 Aug 2013 06:32:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra7AK8YggwvPeC2e3p/GZtG46Cmr A5PH/W9/2T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxuCeooI+/Ytn5RYwNjI08XYycHBICJhIr Dr5ih7DFJC7cW8/WxcjFISRwmFHibus2RghnMaPExY1LgDIcHGwCFhLd/7RBGkQElCV23uoE a2YWkJJo6l7HDGILC0RK/O5bwgRREyWx/FU3M4RtJbFo4mOwOIuAisSPnWtZQGxeAV+JtQvv QC2ewijxpGcdWBGnQKDE2++tYEWMQNd9P7WGCWKZuMSHg9eZIa4WkFiy5zyULSrx8vE/Vghb SaJxyRNWiHo9iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYmTP TczMSS832sQIjJGDW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhgZDi0QKV95UOnDXPNdjbOYTvVP4rDvTP2RdobZxmFBo986Y7Wb1fVW5Y9vWlbNiMt9 ZLnhRfJCy+qKJta+nXoLprpxLDaQvys+c66c6yue35/MJF/8v6KQnVs/1TT9hyrbsuuhvGwl X5SO776Qstpuz40U/9qvdb+0H/W/Wr/52c/vws+WqUxVYinOSDTUYi4qTgQAbwCatF8CAAA= Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding 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: Wed, 07 Aug 2013 06:32:55 -0000 Hi Brian, > Not sure pictures in ascii art would help, but more words might. I think some ascii art, showing the calling device (user or sensor), some i= ntermediary ("server") and the PSAP would help. > My usual example is a medical sensor based device adds some, a specialize= d service provider who services the device adds some and a communications s= ervice provider adds some. =A0all of thise go in the SIP message. =A0then t= he access network sends some in the PIDF. > > With respect to multiple entities adding data,=A0proxies can't add bodies= , but B2BUAs can. =A0 Well, that is protocol/solution talk - the question is whether there is a R= EQUIREMENT that multiple entities should be able to add information :) (If so, we then have to either mandate B2BUA functionality, or use some oth= er mechanism. For example, data that can be defined as capabilities could b= e indicated also using feature capability indicators.) Regards, Christer However, you have pointed out a problem that arose in the evolution of the = mechanism. =A0Originally, there was an outer envelope wit the blocks inside= it. =A0That would let us know the source of each block because the data pr= ovider block is required. =A0 The current mechanism doesn't have that. =A0I= t's a problem. Brian On Tuesday, August 6, 2013, Christer Holmberg wrote: Hi, =A0 The draft talks about all kind of different entities that might add additio= nal data to an emergency call. =A0 First, I think it would be good to have some pictures showing a few=A0diffe= rent scenarios. =A0 Second, the draft doesn't seem to describe the case where multiple entities= are adding data - for the same call. Will multiple MIMEs etc be used, are = there restrictions, etc etc etc? OR, is it not allowed to begin with? =A0 Regards, =A0 Christer =A0 Sent from Windows using TouchDown (www.nitrodesk.com) From a.james.winterbottom@gmail.com Wed Aug 7 00:03:55 2013 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 11A1411E810B for ; Wed, 7 Aug 2013 00:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 dTnGso1-F2JT for ; Wed, 7 Aug 2013 00:03:54 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E743211E8109 for ; Wed, 7 Aug 2013 00:03:53 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1520953pbc.8 for ; Wed, 07 Aug 2013 00:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=F+iZ8/sowA+74JLq+/xQb6IW4/qsTmkDEriq9zNGTa8=; b=iXgkNmqD3ksvw7Ki9dz3GeRdYPrxF6WPuvhnRJFO7FbqSC/HO19Dg6SnUGUVGCGNk8 AWcqer3UIATeqQH7AEdJaOU9EevUl/BpS2Mk5iTYlcBItmMPdMWHLUZU/HgX9Bkopsba dbVU3NWTbwgDDhO/C3IVRpaCQUGOy3Cp9FBjzShAxUpYzLhxOWXo3CdDdRvH7ZgnUwg3 MjyIjW/yMNsJxg8YwDpK8WgcsmKH98lgLU3gx+hx4wCScXA4To2tWDkpzrzFUx31Op2h gzPfi86IGdClvfp3zvgq9nk7PBgThj5G4JlimUuF2oH7QlPIOXiDWqXwGdH0KZf2X1Qm iCaQ== X-Received: by 10.66.190.198 with SMTP id gs6mr2837180pac.49.1375859033623; Wed, 07 Aug 2013 00:03:53 -0700 (PDT) Received: from [192.168.1.17] (124-149-119-169.dyn.iinet.net.au. [124.149.119.169]) by mx.google.com with ESMTPSA id mr3sm6384119pbb.27.2013.08.07.00.03.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 00:03:52 -0700 (PDT) References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: James Winterbottom Date: Wed, 7 Aug 2013 17:03:49 +1000 To: Christer Holmberg Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding 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: Wed, 07 Aug 2013 07:03:55 -0000 Actually, I think that the requirement is more whether a single entity shoul= d be able to add multiple types if information. Cheers James Sent from my iPhone On 07/08/2013, at 4:32 PM, Christer Holmberg wrote: > Hi Brian, >=20 >> Not sure pictures in ascii art would help, but more words might. >=20 > I think some ascii art, showing the calling device (user or sensor), some i= ntermediary ("server") and the PSAP would help. >=20 >> My usual example is a medical sensor based device adds some, a specialize= d service provider who services the device adds some and a communications se= rvice provider adds some. all of thise go in the SIP message. then the acc= ess network sends some in the PIDF. >>=20 >> With respect to multiple entities adding data, proxies can't add bodies, b= ut B2BUAs can. =20 >=20 > Well, that is protocol/solution talk - the question is whether there is a R= EQUIREMENT that multiple entities should be able to add information :) >=20 > (If so, we then have to either mandate B2BUA functionality, or use some ot= her mechanism. For example, data that can be defined as capabilities could b= e indicated also using feature capability indicators.) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > However, you have pointed out a problem that arose in the evolution of the= mechanism. Originally, there was an outer envelope wit the blocks inside i= t. That would let us know the source of each block because the data provide= r block is required. The current mechanism doesn't have that. It's a prob= lem. >=20 > Brian >=20 > On Tuesday, August 6, 2013, Christer Holmberg wrote: > Hi, > =20 > The draft talks about all kind of different entities that might add additi= onal data to an emergency call. > =20 > First, I think it would be good to have some pictures showing a few differ= ent scenarios. > =20 > Second, the draft doesn't seem to describe the case where multiple entitie= s are adding data - for the same call. Will multiple MIMEs etc be used, are t= here restrictions, etc etc etc? OR, is it not allowed to begin with? > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Aug 7 05:52:50 2013 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 032D921E8115 for ; Wed, 7 Aug 2013 05:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dvHRrI7UpgR0 for ; Wed, 7 Aug 2013 05:52:41 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id B37F711E8124 for ; Wed, 7 Aug 2013 05:52:32 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so1361329pde.10 for ; Wed, 07 Aug 2013 05:52:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zDcNvT0MIPm02ZNyihiOGgIeaM/qbTibzP/pQtV6VIw=; b=cAOAmnBOPrfqwbBZExdwR8eAL3MZrTXTiI8DFIqKskrJ2GeBwl+APhfovXj+mgQ1Jx s6n9kXclgaAcfrwdoOUeymHFCSVmW1Hc6b+ZuxRUV/CdJwSp0yRzmddv1W7TZLxLEtua 27loFgN/YzClyiaowpLz9QqmyRaPQ0W9N3oOQf5ToRXCcVRilhDMDi+the5CkuibLMv4 TGfuesjWRhB0n2IMRLANOqoyKaj0wDvsfDphIY4BVb+9aDpxyZ8Yt9GABgGXax9IWLdB M70Y/YCFKk+md/kNR9+4qHtv5ay+hN6z4qeLd7kTTCiof+SLThv/Zhsm+R9LcCkXwqjn uw0g== X-Gm-Message-State: ALoCoQl56r5MZteihN3Q0kxpq2WlJl5f9AZx3nmDv54Yf9fq7nnCRo84bAtRXkf4K2gvZl3EUY+q MIME-Version: 1.0 X-Received: by 10.68.223.225 with SMTP id qx1mr379436pbc.157.1375879949722; Wed, 07 Aug 2013 05:52:29 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Wed, 7 Aug 2013 05:52:29 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> Date: Wed, 7 Aug 2013 08:52:29 -0400 Message-ID: From: Brian Rosen To: James Winterbottom Content-Type: multipart/alternative; boundary=047d7b160515a82b3f04e35b033d Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding 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: Wed, 07 Aug 2013 12:52:50 -0000 --047d7b160515a82b3f04e35b033d Content-Type: text/plain; charset=ISO-8859-1 There is a requirement for multiple entities to add information. I don't think there needs to be a requirement that it happen by value, but its at least desirable. James, it's perfectly clear that some blocks need to be repeated For example the block that says who provided the data. Others are more specialized. So generically, it's a requirement that at least some blocks are supplied by multiple enties. Brian On Wednesday, August 7, 2013, James Winterbottom wrote: > Actually, I think that the requirement is more whether a single entity > should be able to add multiple types if information. > > Cheers > James > > Sent from my iPhone > > On 07/08/2013, at 4:32 PM, Christer Holmberg < > christer.holmberg@ericsson.com > wrote: > > > Hi Brian, > > > >> Not sure pictures in ascii art would help, but more words might. > > > > I think some ascii art, showing the calling device (user or sensor), > some intermediary ("server") and the PSAP would help. > > > >> My usual example is a medical sensor based device adds some, a > specialized service provider who services the device adds some and a > communications service provider adds some. all of thise go in the SIP > message. then the access network sends some in the PIDF. > >> > >> With respect to multiple entities adding data, proxies can't add > bodies, but B2BUAs can. > > > > Well, that is protocol/solution talk - the question is whether there is > a REQUIREMENT that multiple entities should be able to add information :) > > > > (If so, we then have to either mandate B2BUA functionality, or use some > other mechanism. For example, data that can be defined as capabilities > could be indicated also using feature capability indicators.) > > > > Regards, > > > > Christer > > > > > > > > > > > > > > However, you have pointed out a problem that arose in the evolution of > the mechanism. Originally, there was an outer envelope wit the blocks > inside it. That would let us know the source of each block because the > data provider block is required. The current mechanism doesn't have that. > It's a problem. > > > > Brian > > > > On Tuesday, August 6, 2013, Christer Holmberg wrote: > > Hi, > > > > The draft talks about all kind of different entities that might add > additional data to an emergency call. > > > > First, I think it would be good to have some pictures showing a few > different scenarios. > > > > Second, the draft doesn't seem to describe the case where multiple > entities are adding data - for the same call. Will multiple MIMEs etc be > used, are there restrictions, etc etc etc? OR, is it not allowed to begin > with? > > > > Regards, > > > > Christer > > > > > > > > Sent from Windows using TouchDown (www.nitrodesk.com) > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > --047d7b160515a82b3f04e35b033d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is a requirement for multiple entities to add information. =A0I don&#= 39;t think there needs to be a requirement that it happen by value, but its= at least desirable.

James, it's perfectly clear tha= t some blocks need to be repeated =A0For example the block that says who pr= ovided the data. =A0Others are more specialized. =A0So generically, it'= s a requirement that at least some blocks are supplied by multiple enties.= =A0

Brian

On Wednesday, August 7= , 2013, James Winterbottom wrote:
Actual= ly, I think that the requirement is more whether a single entity should be = able to add multiple types if information.

Cheers
James

Sent from my iPhone

On 07/08/2013, at 4:32 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi Brian,
>
>> Not sure pictures in ascii art would help, but more words might. >
> I think some ascii art, showing the calling device (user or sensor), s= ome intermediary ("server") and the PSAP would help.
>
>> My usual example is a medical sensor based device adds some, a spe= cialized service provider who services the device adds some and a communica= tions service provider adds some. =A0all of thise go in the SIP message. = =A0then the access network sends some in the PIDF.
>>
>> With respect to multiple entities adding data, proxies can't a= dd bodies, but B2BUAs can.
>
> Well, that is protocol/solution talk - the question is whether there i= s a REQUIREMENT that multiple entities should be able to add information :)=
>
> (If so, we then have to either mandate B2BUA functionality, or use som= e other mechanism. For example, data that can be defined as capabilities co= uld be indicated also using feature capability indicators.)
>
> Regards,
>
> Christer
>
>
>
>
>
>
> However, you have pointed out a problem that arose in the evolution of= the mechanism. =A0Originally, there was an outer envelope wit the blocks i= nside it. =A0That would let us know the source of each block because the da= ta provider block is required. =A0 The current mechanism doesn't have t= hat. =A0It's a problem.
>
> Brian
>
> On Tuesday, August 6, 2013, Christer Holmberg wrote:
> Hi,
>
> The draft talks about all kind of different entities that might add ad= ditional data to an emergency call.
>
> First, I think it would be good to have some pictures showing a few di= fferent scenarios.
>
> Second, the draft doesn't seem to describe the case where multiple= entities are adding data - for the same call. Will multiple MIMEs etc be u= sed, are there restrictions, etc etc etc? OR, is it not allowed to begin wi= th?
>
> Regards,
>
> Christer
>
>
>
> Sent from Windows using TouchDown (www.nitrodesk.com)
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
--047d7b160515a82b3f04e35b033d-- From christer.holmberg@ericsson.com Thu Aug 8 15:00:16 2013 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 5862211E823E for ; Thu, 8 Aug 2013 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[AWL=-1.412, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqQsQi5hqIOe for ; Thu, 8 Aug 2013 14:59:11 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8F21F9B9F for ; Thu, 8 Aug 2013 14:58:12 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-97-52041461af9a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6F.6B.02664.16414025; Thu, 8 Aug 2013 23:57:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 23:57:53 +0200 From: Christer Holmberg To: ecrit_ietf.org Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 Thread-Index: Ac6Sss0vFs+I00HHTNynzH+gXjYA8QBz4d9t Date: Thu, 8 Aug 2013 21:57:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422BC7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW6iCEuQQfMSXYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVca3rL3vBR82KvWcOsTYwrlPtYuTkkBAwkVh/5DorhC0mceHe erYuRi4OIYGjjBLLmrZCOYsZJV7/ngFUxcHBJmAh0f1PG8QUEVCWOPVPHqRXWKBK4srfKYwg tohAtcSWo5sYIUqMJBrnGoGEWQRUJOZu+ga2ilfAV2LHlr9MILYQkL1r00qwVk4BP4neU9fY QWxGoHO+n1oDVsMsIC5x68l8JogzBSSW7DnPDGGLSrx8/I8VoiZfYtLVVkaI+YISJ2c+YZnA KDwLSfssJGWzkJRBxA0k3p+bzwxha0ssW/gaytaX2PjlLCOy+AJG9lWMHMWpxUm56UYGmxiB 0XBwy2+LHYyX/9ocYpTmYFES592idyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OlyLMs nT5Wxb4sS30Bs7UNz7dlfMtiCnE289JbuPfPk4dmF+5ocDFM+Xc1sNMpSO/J+h8Fum612zV1 dFWFNfIP2Zkf9JOVzDfadVv1R9iE+9uPrv5QeyvrtNU5hSCT7mVPtYOMst49dbhl6xnCEqC+ ts8rdcmTvisfxTUlnWeKRBYa79W2UGIpzkg01GIuKk4EAENmzMZUAgAA Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 08 Aug 2013 22:00:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422BC7ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I haven't seen any reply to this. Brian, do you have any opinion? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Christer Holmberg [christer.holmberg@ericsson.com] To: ecrit@ietf.org [ecrit@ietf.org] Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of = the Contact URI, defined in section 3.1.5 Hi, A question on the scope of the Contact URI, defined in section 3.1.5 of dra= ft-ietf-ecrit-additional-data-11.txt. Is the Contact URI supposed by the PSAP when making callbacks? If the value represents a =93service provider=94, should PSAP callbacks als= o be made to the service provider? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C422BC7ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I haven't seen any reply to this. Brian, do you have = any opinion?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Christer Holmberg [christer.holmberg@ericsson.com]
To: ecrit@ietf.org [ecrit@ietf.org]
Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on sc= ope of the Contact URI, defined in section 3.1.5

Hi,

 

A question on the scope of the Contact URI, defined in sect= ion 3.1.5 of draft-ietf-ecrit-additional-data-11.txt.

 

Is the Contact URI supposed by the PSAP when making callbac= ks?

 

If the value represents a =93service provider=94, should PS= AP callbacks also be made to the service provider?

&= nbsp;

R= egards,

&= nbsp;

C= hrister

 

--_000_7594FB04B1934943A5C02806D1A2204B1C422BC7ESESSMB209erics_-- From br@brianrosen.net Thu Aug 8 15:20:42 2013 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 B8C5211E8242 for ; Thu, 8 Aug 2013 15:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.754 X-Spam-Level: X-Spam-Status: No, score=-102.754 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KO-JkzZNlsV for ; Thu, 8 Aug 2013 15:20:37 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id C8B7211E8230 for ; Thu, 8 Aug 2013 15:20:32 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so3961714pbb.0 for ; Thu, 08 Aug 2013 15:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oSrhHf4DrIgQ+E+TqSHMYjc1ipZw44gb2tmimRCRD5I=; b=KxxAmhQsm/6olHnXrzQvWF21koSLWsXPkz/agGbnF08cQppKiBbB0kAre4GuFzw+SO jx6tF16wzY8GdV9dq8IwkkDQHIRQD+jyb5v/eSNBPy3V+Ctcm27KjTHKIDbnovPmPocV 4Orm1D3KyJqR9fP67mTRN8280Lmd//r2KHoW2gpnQfpXxYgxxEQIZhXGMwcRVjY6iIf2 bTWTNBklQefz3Om92EKwr25H8V7SMPaQaY0KLt6wHz+MYR+9FkehUyfrr8VFoT4gJpRh c+ijuE0xY/wlLmCq4CtahS4W7db3t4AUUM/qBkC7glHHoJDsoYYvuZV7s6Hs/ya28tXg gcdw== X-Gm-Message-State: ALoCoQmhFy+F5UHVmo6i/h9Foscct8l8JLFIx9uySQRpyX3xY/FUGv2V+5w1nGv/cOh8RKFbFlRV MIME-Version: 1.0 X-Received: by 10.68.194.104 with SMTP id hv8mr8242289pbc.168.1376000432528; Thu, 08 Aug 2013 15:20:32 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Thu, 8 Aug 2013 15:20:32 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 18:20:32 -0400 Message-ID: From: Brian Rosen To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b15af79fdf58b04e37710b1 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 08 Aug 2013 22:20:42 -0000 --047d7b15af79fdf58b04e37710b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Contact is how the PSAP contacts the service provider to get help from the SP. It's not a "call back" in the sense of an emergency call (the network doesn't treat it differently than a normal call), at least as far as I have considered it. I suppose it might be nice to know that it's important, but I don't think that is worth any big new mechanism. Brian On Thursday, August 8, 2013, Christer Holmberg wrote: > I haven't seen any reply to this. Brian, do you have any opinion? > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Christer Holmberg [christer.holmberg@ericsson.com > ] > *To:* ecrit@ietf.org [ > ecrit@ietf.org ] > *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope > of the Contact URI, defined in section 3.1.5 > > Hi, > > > > A question on the scope of the Contact URI, defined in section 3.1.5 of > draft-ietf-ecrit-additional-data-11.txt. > > > > Is the Contact URI supposed by the PSAP when making callbacks? > > > > If the value represents a =93service provider=94, should PSAP callbacks a= lso > be made to the service provider? > > > > Regards, > > > > Christer > > > --047d7b15af79fdf58b04e37710b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Contact is how the PSAP contacts the service provider to get help from = the SP.

It's not a "call back" in the sens= e of an emergency call (the network doesn't treat it differently than a= normal call), at least as far as I have considered it. =A0I suppose it mig= ht be nice to know that it's important, but I don't think that is w= orth any big new mechanism.

Brian


On Thursday, Augus= t 8, 2013, Christer Holmberg wrote:
I haven't seen any reply to this. Brian, do you have any opinio= n?
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Christer Holmberg [christer.ho= lmberg@ericsson.com]
To: ecrit@ietf.org [ecrit@ietf.o= rg]
Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on sc= ope of the Contact URI, defined in section 3.1.5

H= i,

= =A0

A= question on the scope of the Contact URI, defined in section 3.1.5 of draf= t-ietf-ecrit-additional-data-11.txt.

= =A0

I= s the Contact URI supposed by the PSAP when making callbacks?

= =A0

I= f the value represents a =93service provider=94, should PSAP callbacks also= be made to the service provider?

=A0

Regards,<= /p>

=A0

Christer<= /p>

=A0

--047d7b15af79fdf58b04e37710b1-- From christer.holmberg@ericsson.com Thu Aug 8 21:44:24 2013 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 E620021F9E62 for ; Thu, 8 Aug 2013 21:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSzl2RZKP5EI for ; Thu, 8 Aug 2013 21:44:19 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF121F9E47 for ; Thu, 8 Aug 2013 21:44:18 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-63-520473a14a2c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5F.DD.02664.1A374025; Fri, 9 Aug 2013 06:44:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 06:44:17 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 Thread-Index: Ac6Sss0vFs+I00HHTNynzH+gXjYA8QBz4d9t///kzQCAAIy+2Q== Date: Fri, 9 Aug 2013 04:44:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422DB7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7CYpYgg9vtchZP709js2hc9JTV gcnj/re/7B5LlvxkCmCK4rJJSc3JLEst0rdL4MpYvqyLvWCDTcXdW++YGhgfmHQxcnJICJhI 3Lr6nhXCFpO4cG89WxcjF4eQwFFGiaM7d0I5ixklpi75DlTFwcEmYCHR/U8bpEFEQFli561O dpAwM5B9ojMeJCwsUCWxeOJHJoiSaoktRzcxgpSICDhJLOoNBQmzCKhIrDx9gQkkzCvgK/Fo Si7EomuMEhf3bgQ7h1MgUGLFzFksIDYj0GnfT60BG8ksIC5x68l8JoiTBSSW7DnPDGGLSrx8 /I8VoiZf4sH9NjYQm1dAUOLkzCcsExhFZiFpn4WkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIb v5xlRBZfwMi+ipGjOLU4KTfdyGATIzByDm75bbGD8fJfm0OM0hwsSuK8W/TOBAoJpCeWpGan phakFsUXleakFh9iZOLglGpg1NwZEKO2ocqD6X9Wss2774wnrD6s2cETMmv9bv+Dr83y7poZ fPD1m7Uj+vbSz8leVk/OSs3q2tZvvK9lXozZWanSc8HKr2cm/Frws82k+oaK/5nu23t2ty/b 86iStXVT99f4kJice2JTX89bJCf9cuHi19yuLTnV4ZwcVvby7yIFJ+XMWvY7TYmlOCPRUIu5 qDgRAKpFjKRqAgAA Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 09 Aug 2013 04:44:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422DB7ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If the PSAP is not supposed to use the field when/if making a callback, I t= hink we shall explicitly state that in the document, and/or in general say = that the field must not be used for calls that are expected to be given pri= ority/special handling, and give callback as an example. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Brian Rosen [br@brianrosen.net] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: ecrit_ietf.org [ecrit@ietf.org] Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope= of the Contact URI, defined in section 3.1.5 The Contact is how the PSAP contacts the service provider to get help from = the SP. It's not a "call back" in the sense of an emergency call (the network doesn= 't treat it differently than a normal call), at least as far as I have cons= idered it. I suppose it might be nice to know that it's important, but I d= on't think that is worth any big new mechanism. Brian On Thursday, August 8, 2013, Christer Holmberg wrote: I haven't seen any reply to this. Brian, do you have any opinion? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Christer Holmberg [christer.holmberg@ericsson.com] To: ecrit@ietf.org [ecrit@ietf.org] Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of = the Contact URI, defined in section 3.1.5 Hi, A question on the scope of the Contact URI, defined in section 3.1.5 of dra= ft-ietf-ecrit-additional-data-11.txt. Is the Contact URI supposed by the PSAP when making callbacks? If the value represents a =93service provider=94, should PSAP callbacks als= o be made to the service provider? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C422DB7ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
 
If the PSAP is not supposed to use the field wh= en/if making a callback, I think we shall explicitly state that in the docu= ment, and/or in general say that the field must not be used for calls that = are expected to be given priority/special handling, and give callback as an example.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Brian Rosen [br@brianrosen.net]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: ecrit_ietf.org [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n scope of the Contact URI, defined in section 3.1.5
The Contact is how the PSAP contacts the service provider to get help = from the SP.

It's not a "call back" in the sense of an emergency call (th= e network doesn't treat it differently than a normal call), at least as far= as I have considered it.  I suppose it might be nice to know that it'= s important, but I don't think that is worth any big new mechanism.

Brian


On Thursday, August 8, 2013, Christer Holmberg wrote:
I haven't seen any reply to this. Brian, do you have any opinion?<= /span>
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Christer Holmberg [christer.hol= mberg@ericsson.com]
To: ecrit@ietf.org [ecrit@ietf.org]
Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on sc= ope of the Contact URI, defined in section 3.1.5

Hi,

 

A question on the scope of the Contact URI, defined in section 3.1.5 of = draft-ietf-ecrit-additional-data-11.txt.

 

Is the Contact URI supposed by the PSAP when making callbacks?

 

If the value represents a =93service provider=94, should PSAP callbacks = also be made to the service provider?

 <= /p>

Regards,

 <= /p>

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C422DB7ESESSMB209erics_-- From br@brianrosen.net Fri Aug 9 05:44:58 2013 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 D7AD321F9FE3 for ; Fri, 9 Aug 2013 05:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 1BJg8FNwrQcI for ; Fri, 9 Aug 2013 05:44:52 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52421F9FDE for ; Fri, 9 Aug 2013 05:44:52 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so504439pdi.5 for ; Fri, 09 Aug 2013 05:44:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RIl9GcVus9e7MLjW3xytLWD2NFmK/e8UDcuTOT5Vi5s=; b=pQv/efpT0tFGtfGafHEeK3fVBLLLrFYbPeC+n9EJ1KCccqsegotG33SoQRCy4hV/Fy N81pGcCvVB4WyTr2pHzCoAGhWjshn0mPtaCQ+DSOzrpXqlMwCMsrefkFywYjFsYbEy/Y 6wVNKjuy/1F77Ue3+8p/C5NOnYE65P8FumhqLOF8YJFKdtxq7g4i3ShXd2slvn8Oj+6f CT6sMGijwmH0lr0ryjMqWxR1Xxi3+QKmZvDkrfxKq3SYEN0PCPFedi0AyfKlJ+TENn8+ ALve/tN68S8xi7+4J3XKrLc12g8pXZy62KIMhk3n7hpDxOtTjwsu0Jp+i4Mg83Lpzx7H tTJw== X-Gm-Message-State: ALoCoQkBryMlIXl7nWkUh5OCOd/9ccFNjuMPUhFlVlgcguhHYEmGbRmRtz80DG0XP1uboeE6fQd+ MIME-Version: 1.0 X-Received: by 10.66.227.39 with SMTP id rx7mr11481825pac.44.1376052291932; Fri, 09 Aug 2013 05:44:51 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Fri, 9 Aug 2013 05:44:51 -0700 (PDT) X-Originating-IP: [24.112.236.47] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> Date: Fri, 9 Aug 2013 08:44:51 -0400 Message-ID: From: Brian Rosen To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b111f3f0da79c04e383246b Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 09 Aug 2013 12:44:58 -0000 --047d7b111f3f0da79c04e383246b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm okay adding that text. Brian On Friday, August 9, 2013, Christer Holmberg wrote: > Hi, > > If the PSAP is not supposed to use the field when/if making a callback, I > think we shall explicitly state that in the document, and/or in general s= ay > that the field must not be used for calls that are expected to be given > priority/special handling, and give callback as an example. > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Brian Rosen [br@brianrosen.net 'br@brianrosen.net');>] > *To:* Christer Holmberg [christer.holmberg@ericsson.com > ] > *CC:* ecrit_ietf.org [ecrit@ietf.org 'ecrit@ietf.org');>] > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > The Contact is how the PSAP contacts the service provider to get help fro= m > the SP. > > It's not a "call back" in the sense of an emergency call (the network > doesn't treat it differently than a normal call), at least as far as I ha= ve > considered it. I suppose it might be nice to know that it's important, b= ut > I don't think that is worth any big new mechanism. > > Brian > > > On Thursday, August 8, 2013, Christer Holmberg wrote: > >> I haven't seen any reply to this. Brian, do you have any opinion? >> >> Regards, >> >> Christer >> >> >> >> Sent from *Windows* using *TouchDown* (www.nitrodesk.com) >> >> -----Original Message----- >> *From:* Christer Holmberg [christer.holmberg@ericsson.com] >> *To:* ecrit@ietf.org [ecrit@ietf.org] >> *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on >> scope of the Contact URI, defined in section 3.1.5 >> >> Hi, >> >> >> >> A question on the scope of the Contact URI, defined in section 3.1.5 of >> draft-ietf-ecrit-additional-data-11.txt. >> >> >> >> Is the Contact URI supposed by the PSAP when making callbacks? >> >> >> >> If the value represents a =93service provider=94, should PSAP callbacks = also >> be made to the service provider? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> > --047d7b111f3f0da79c04e383246b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm okay adding that text.

Brian
On Friday, August 9, 2013, Christer Holmberg wrote:
Hi,
=A0
If the PSAP is not supposed to use the field wh= en/if making a callback, I think we shall explicitly state that in the docu= ment, and/or in general say that the field must not be used for calls that = are expected to be given priority/special handling, and give callback as an example.
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Brian Rosen [br@brianrosen.net]
To: Christer Holmberg [christer.holm= berg@ericsson.com]
CC: ecrit_ietf.o= rg [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n scope of the Contact URI, defined in section 3.1.5
The Contact is how the PSAP contacts the service provider to get help = from the SP.

It's not a "call back" in the sense of an emergency call= (the network doesn't treat it differently than a normal call), at leas= t as far as I have considered it. =A0I suppose it might be nice to know tha= t it's important, but I don't think that is worth any big new mechanism.

Brian


On Thursday, August 8, 2013, Christer Holmberg wrote:
I haven't seen any reply to this. Brian, do you have any opinio= n?
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Christer Holmberg [christer.holmberg@ericsson.com]
To: ecrit@ietf.org [ecrit@ietf.org]
Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on sc= ope of the Contact URI, defined in section 3.1.5

H= i,

= =A0

A= question on the scope of the Contact URI, defined in section 3.1.5 of draf= t-ietf-ecrit-additional-data-11.txt.

= =A0

I= s the Contact URI supposed by the PSAP when making callbacks?

= =A0

I= f the value represents a =93service provider=94, should PSAP callbacks also= be made to the service provider?

=A0

Regards,<= /p>

=A0

Christer<= /p>

=A0

--047d7b111f3f0da79c04e383246b-- From RMarshall@telecomsys.com Mon Aug 26 13:33:19 2013 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 7E0EE21F9D80 for ; Mon, 26 Aug 2013 13:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 jhz38JvsywGf for ; Mon, 26 Aug 2013 13:33:15 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC821F9D69 for ; Mon, 26 Aug 2013 13:33:15 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r7QKX5tj006954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 26 Aug 2013 13:33:06 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.145]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Mon, 26 Aug 2013 13:33:05 -0700 From: Roger Marshall To: "'Christer Holmberg'" , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 Thread-Index: Ac6Sss0vFs+I00HHTNynzH+gXjYA8QBz4d9tAA91owAADWbXAANpY92g Date: Mon, 26 Aug 2013 20:33:05 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01SEAEXMB1telecomsy_" MIME-Version: 1.0 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 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, 26 Aug 2013 20:33:19 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Christer's suggestion to add caution text. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Thursday, August 08, 2013 9:44 PM To: Brian Rosen Cc: ecrit_ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope= of the Contact URI, defined in section 3.1.5 Hi, If the PSAP is not supposed to use the field when/if making a callback, I t= hink we shall explicitly state that in the document, and/or in general say = that the field must not be used for calls that are expected to be given pri= ority/special handling, and give callback as an example. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Brian Rosen [br@brianrosen.net] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: ecrit_ietf.org [ecrit@ietf.org] Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope= of the Contact URI, defined in section 3.1.5 The Contact is how the PSAP contacts the service provider to get help from = the SP. It's not a "call back" in the sense of an emergency call (the network doesn= 't treat it differently than a normal call), at least as far as I have cons= idered it. I suppose it might be nice to know that it's important, but I d= on't think that is worth any big new mechanism. Brian On Thursday, August 8, 2013, Christer Holmberg wrote: I haven't seen any reply to this. Brian, do you have any opinion? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Christer Holmberg [christer.holmberg@ericsson.com] To: ecrit@ietf.org [ecrit@ietf.org] Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of = the Contact URI, defined in section 3.1.5 Hi, A question on the scope of the Contact URI, defined in section 3.1.5 of dra= ft-ietf-ecrit-additional-data-11.txt. Is the Contact URI supposed by the PSAP when making callbacks? If the value represents a "service provider", should PSAP callbacks also be= made to the service provider? Regards, Christer CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with ChristerR= 17;s suggestion to add caution text.

 <= /p>

-roger.=

 <= /p>

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, August 08, 2013 9:44 PM
To: Brian Rosen
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n scope of the Contact URI, defined in section 3.1.5

 

Hi,

 

If the PSAP is not supposed to use the field when/if mak= ing a callback, I think we shall explicitly state that in the document, and= /or in general say that the field must not be used for calls that are expected to be given priority/special handling, and give callback= as an example.

 

Regards,

 

Christer

 



Sent from Windows using Tou= chDown (www.nitrodesk.com)


-----Original Message-----
From: Brian Rosen [br@brianrosen.net]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: ecrit_ietf.org [ecrit@ietf.org]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n scope of the Contact URI, defined in section 3.1.5

The Contact is how the PSAP contacts the service pro= vider to get help from the SP.

 

It's not a "call back" in the sense of an = emergency call (the network doesn't treat it differently than a normal call= ), at least as far as I have considered it.  I suppose it might be nic= e to know that it's important, but I don't think that is worth any big new mechanism.

 

Brian



On Thursday, August 8, 2013, Christer Holmberg wrote:

I haven't seen any reply to= this. Brian, do you have any opinion?<= /span>

 

Regards,=

 

Christer=

 



Sent from Windows using TouchDo= wn (www.n= itrodesk.com)


-----Original Message-----
From: Christer Holmberg [christer.hol= mberg@ericsson.com]
To: ecrit@ietf.org [ecrit@ietf.org]
Subject: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on sc= ope of the Contact URI, defined in section 3.1.5

Hi,

 

A question on th= e scope of the Contact URI, defined in section 3.1.5 of draft-ietf-ecrit-ad= ditional-data-11.txt.

 

Is the Contact U= RI supposed by the PSAP when making callbacks?

 

If the value rep= resents a “service provider”, should PSAP callbacks also be mad= e to the service provider?

&nbs= p;

Rega= rds,

&nbs= p;

Chri= ster

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01SEAEXMB1telecomsy_--