From nobody Wed Jun 1 05:16:40 2016 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 B298C12D19B for ; Wed, 1 Jun 2016 05:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v9yB2d4cUlp for ; Wed, 1 Jun 2016 05:16:36 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB0112D190 for ; Wed, 1 Jun 2016 05:16:36 -0700 (PDT) Received: from [85.158.136.35] by server-4.bemta-5.messagelabs.com id 98/BA-10829-222DE475; Wed, 01 Jun 2016 12:16:34 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIKsWRWlGSWpSXmKPExsVybg1jsq7SJb9 wg6fTGS0aFz1ltdhw6huLxcJfv1gcmD2m/N7I6nFpSyu7x5IlP5kCmKNYM/OS8isSWDNmti5j KnhuVjH9QwdbA+Mjgy5GTg4JAT+Jv6uesYHYQgL7GCVeXSzuYuQCsq8zSlz4dZEdwjnFKLGv9 TJjFyMHB5uAnsTFVzYgDSICYRLd634ygdjMAqYS/fs/MYPYwgJ2ErO33GeFqLGXaJp+jB2kVU TASOLmVR+QMIuAisTP+zfZQWxeAR+Ja3vPMEHcECDx9v0ZsDinQKDEhO7FYCMZBWQlNkz8xgK xSlzi29GVzBD3C0gs2XMeyhaVePn4HyuEbSCxdek+FghbXuLWuzlsEL15EpNevWWC2CsocXLm E6gaSYmDK26wgJwpJCAjsXWLIsTnsxglpk7eCzXTXuLh5a9MExilZiE5YxaSsbOQjIWI60ncm DqFDcLWlli28DVUva7EjH+HWJDFFzCyr2LUKE4tKkst0jU000sqykzPKMlNzMzRNTQw1ctNLS 5OTE/NSUwq1kvOz93ECEwKDECwg/H8ac9DjJIcTEqivM2H/cKF+JLyUyozEosz4otKc1KLDzH KcHAoSfAevgCUEyxKTU+tSMvMAaYnmLQEB4+SCC/nRaA0b3FBYm5xZjpE6hSjopQ473SQPgGQ REZpHlwbLCVeYpSVEuZlBDpEiKcgtSg3swRV/hWjOAejkjDvfJApPJl5JXDTXwEtZgJaHJ/hA 7K4JBEhJdXAaHBEavOVvX7M+x07O4U2hp8XFp16cIVvyAK9u8XzNq507JWNE9hxeNMLPY+3GQ omk9lj3NYXfFNLaJlvcub+pbQnvD/YN83UjdCx+Vq7vtPWfOvEU2HpHpLnHFPSriTF88lP5+z eyWn31qfAQDryxLPFLEtZVy84+3PTkSb2B75mPVsO6IjMVGIpzkg01GIuKk4EAJjDpiiEAwAA X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-8.tower-125.messagelabs.com!1464783391!32083777!3 X-Originating-IP: [206.172.1.99] X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14030 invoked from network); 1 Jun 2016 12:16:33 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-8.tower-125.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 Jun 2016 12:16:33 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca Received: from DG2MBX01-WYN.bell.corp.bce.ca (198.235.121.231) by EX13EDGE02-DOR.bell.corp.bce.ca (198.235.121.55) with Microsoft SMTP Server id 15.0.1076.9; Wed, 1 Jun 2016 08:07:04 -0400 Received: from DG2MBX01-WYN.bell.corp.bce.ca (2002:8eb6:1213::8eb6:1213) by DG2MBX01-WYN.bell.corp.bce.ca (2002:8eb6:1213::8eb6:1213) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 08:16:30 -0400 Received: from DG2MBX01-WYN.bell.corp.bce.ca ([fe80::d91e:3e92:8922:f20e]) by DG2MBX01-WYN.bell.corp.bce.ca ([fe80::d91e:3e92:8922:f20e%21]) with mapi id 15.00.1104.000; Wed, 1 Jun 2016 08:16:30 -0400 From: "Caron, Guy (A162859)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] lost-planned-changes WG Adoption and WGLC Thread-Index: AdG7jb9W6zJ/gFcYRjaKpjsjL3wCCwAcX4FA Date: Wed, 1 Jun 2016 12:16:30 +0000 Message-ID: <44f5a1c6ba3c45d8bdc1834489baa254@DG2MBX01-WYN.bell.corp.bce.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.25.6] Content-Type: multipart/alternative; boundary="_000_44f5a1c6ba3c45d8bdc1834489baa254DG2MBX01WYNbellcorpbcec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-DOR.bell.corp.bce.ca: domain of transitioning g.caron@bell.ca discourages use of 198.235.121.231 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-DOR.bell.corp.bce.ca Archived-At: Cc: "marc.linsner@cisco.com" Subject: Re: [Ecrit] lost-planned-changes WG Adoption and WGLC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:16:40 -0000 --_000_44f5a1c6ba3c45d8bdc1834489baa254DG2MBX01WYNbellcorpbcec_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the adoption of this I-D as a work group item in ECRIT. Guy De : Ecrit [mailto:ecrit-bounces@ietf.org] De la part de Roger Marshall Envoy=E9 : 31 mai 2016 18:53 =C0 : ecrit@ietf.org Cc : marc.linsner@cisco.com Objet : [Ecrit] lost-planned-changes WG Adoption and WGLC At our ECRIT meeting in BA, the work group agreed with the chairs' action t= o request of the list, adoption of this ID as an official WG item, with the= intention of submitting it for WGLC, once adopted. This is reflected in t= he posted meeting notes. Does anyone object to adopting this draft as an ECRIT working group item? https://www.ietf.org/archive/id/draft-rosen-ecrit-lost-planned-changes-03.t= xt Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_44f5a1c6ba3c45d8bdc1834489baa254DG2MBX01WYNbellcorpbcec_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I suppo= rt the adoption of this I-D as a work group item in ECRIT.

&n= bsp;

Guy

&n= bsp;

De : Ecri= t [mailto:ecrit-bounces@ietf.org] De la part de Roger Marshall
Envoy=E9 : 31 mai 2016 18:53
=C0 : ecrit@ietf.org
Cc : marc.linsner@cisco.com
Objet : [Ecrit] lost-planned-changes WG Adoption and WGLC<= /o:p>

 

At our ECRIT meeting in BA, the= work group agreed with the chairs’ action to request of the list, ad= option of this ID as an official WG item, with the intention of submitting = it for WGLC, once adopted.  This is reflected in the posted meeting notes.

 

Does anyone object to adopting = this draft as an ECRIT working group item?

 

https://www.ietf= .org/archive/id/draft-rosen-ecrit-lost-planned-changes-03.txt

 

Roger Marshall & Marc Linsn= er

ECRIT Chairs<= /p>

 

NOTICE TO REC= IPIENT: This email, including attachments, may contain information which is= confidential, proprietary, attorney-client privileged and/or controlled un= der U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law.= Nothing in this email shall create any legal binding agreement between the= parties unless expressly stated herein and provided by an authorized repre= sentative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this m= essage, be advised that any dissemination, distribution, or use of the cont= ents of this message is strictly prohibited. If you received this message i= n error, please notify us immediately by return email and permanently delete all copies of the original email an= d any attached documentation from any computer or other media.

--_000_44f5a1c6ba3c45d8bdc1834489baa254DG2MBX01WYNbellcorpbcec_-- From nobody Wed Jun 1 05:49:22 2016 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 0B9B312D1BA for ; Wed, 1 Jun 2016 05:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c6kXjFAB_Z1 for ; Wed, 1 Jun 2016 05:49:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3369612D184 for ; Wed, 1 Jun 2016 05:49:18 -0700 (PDT) Received: from [192.168.10.132] ([80.92.115.6]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LZiQy-1bmg8X3gs8-00lURZ; Wed, 01 Jun 2016 14:49:10 +0200 To: "Caron, Guy (A162859)" , Roger Marshall , "ecrit@ietf.org" References: <44f5a1c6ba3c45d8bdc1834489baa254@DG2MBX01-WYN.bell.corp.bce.ca> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <574ED9A9.6080109@gmx.net> Date: Wed, 1 Jun 2016 14:48:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <44f5a1c6ba3c45d8bdc1834489baa254@DG2MBX01-WYN.bell.corp.bce.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DEqRnbnHhSfCwbkd98RDOhkUAo0Qs4ro2" X-Provags-ID: V03:K0:2phnwkaY5wWyElwgqCrb+Q48g3HtORBVzyWdYw0NgLm+wbnYHG2 hfQW9MorQVw9fFxGeHbWNq/hzUg7C4F7vKm07smhrbMbEQFUkfWOIp+UBg7kBCWrGQB8M69 ei9B4K2ELEYEU/xYoLI/e4oHq3bCxD4YVMxezrgKokRZ/j4jGeGOEU9TE5tzy4CvGJ/6SCr tqtf2iUCtVT3AH3K69P8w== X-UI-Out-Filterresults: notjunk:1;V01:K0:0pgRXZkzgYE=:urUDrg+XQg12cdaCpJSO3S CFNhxY/Vp6NUtjCGDDC9TYnN6nicbMFPNPdOGZCr+hqJ7KSqiWYDDk6mVKmWSsLuwt3tAzFft DuwHJOHfZv1tKWglUYfUldf9GNvUfrOQdVkDprWwmbwYQrAnrfMU2QOJPGJ8zMkv10D4KyBiL oIprI+BPUpcFOsL+JpGBHWhV5pn+NVWchtaM9sDoRQHueH61i1EP+PUTTH6vHVmMl+52yOEJi fmM6SDbPkEd6so/PEbqe7IalpABNMFhEtb5JxsnFNitnNWhPIV/rD7+16jhrI0C3l+oAJmJ94 xLLiWj3za14Cwtca/EMs9XUfFth7YuHErbP4ZHu+xHZWxYIZO9XV8KqVv/eQr2pR4Ey7C+f5T tvn/yF/LWkD7f0hu3y1BepP7WGMrljqs2XDeSU8Rah1JdmjfOVcyktTqmHx98J6Sc2PwjN8+3 9iO5sTgA16DjoFPNgSzbtUrok+LBmSTEWq37ar9/ZUiXIzFhMi8t3G3YUia7M8oIICpehgUHY WQJB5TrbLCwgbttQH8DcFaB14XadSpvm609PtW9T/uZy3KCdFIFk43GPokBj2N3xQ3M3EUyhV 1WE5ewRCPzZ68RmJj+/jcuxB9RIWlgr1t7T9JOYwG0FQTqUbnvdeUWff8igzZmaIfj82ZUUYI wgJyEXQTY1wNCmCtYJ68jP0FXd16kKfULGE1hF5Y0y3P+LiS2btwcxlm3VredONBnQ1ORoE9b ldXIAvvQwiYCKfbHs3p89JVesVSE6VDs9MzMFA4aHzvBNyZmPmZkQnFta0zElaIjgeto1ZyFX KtrJz1R21Ye6wuO043QrS0av65IyA== Archived-At: Cc: "marc.linsner@cisco.com" Subject: Re: [Ecrit] lost-planned-changes WG Adoption and WGLC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:49:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DEqRnbnHhSfCwbkd98RDOhkUAo0Qs4ro2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is useful work. Brian has my support! On 06/01/2016 02:16 PM, Caron, Guy (A162859) wrote: > I support the adoption of this I-D as a work group item in ECRIT. >=20 > =20 >=20 > Guy >=20 > =20 >=20 > *De :*Ecrit [mailto:ecrit-bounces@ietf.org] *De la part de* Roger Marsh= all > *Envoy=E9 :* 31 mai 2016 18:53 > *=C0 :* ecrit@ietf.org > *Cc :* marc.linsner@cisco.com > *Objet :* [Ecrit] lost-planned-changes WG Adoption and WGLC >=20 > =20 >=20 > At our ECRIT meeting in BA, the work group agreed with the chairs=92 > action to request of the list, adoption of this ID as an official WG > item, with the intention of submitting it for WGLC, once adopted. This= > is reflected in the posted meeting notes. >=20 > =20 >=20 > Does anyone object to adopting this draft as an ECRIT working group ite= m? >=20 > =20 >=20 > https://www.ietf.org/archive/id/draft-rosen-ecrit-lost-planned-changes-= 03.txt >=20 > =20 >=20 > Roger Marshall & Marc Linsner >=20 > ECRIT Chairs >=20 > =20 >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain > information which is confidential, proprietary, attorney-client > privileged and/or controlled under U.S. export laws and regulations and= > may be restricted from disclosure by applicable State and Federal law. > Nothing in this email shall create any legal binding agreement between > the parties unless expressly stated herein and provided by an authorize= d > representative of Comtech Telecommunications Corp. or its subsidiaries.= > If you are not the intended recipient of this message, be advised that > any dissemination, distribution, or use of the contents of this message= > is strictly prohibited. If you received this message in error, please > notify us immediately by return email and permanently delete all copies= > of the original email and any attached documentation from any computer > or other media. >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --DEqRnbnHhSfCwbkd98RDOhkUAo0Qs4ro2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXTtmpAAoJEGhJURNOOiAtRDYH/0ntqdg4HUzz5AA1XAb7AJae RxdhjtwpZiDsz0udhrHS94pd8QzQl1MS43P3r13OknVm/rYkqZAn00ytiSUj2/5Y sesz+/oQ240XFg1WyJ2zYMPk0O+2O8t3zi/3W6wWtz+/QZVekGRRs5OJrDaxvCbr 5Ldx/PVtPMD3etm3s5J5vjRZQ8vdbGc3XE80EUEQ1VSAViPHSM1cGw6N7mvUCACn UHPObdKG4tp4QUW9yskIziz2ztvdC8i6Tqn8ymSUE6HG+fT9KRoUcR9aPArVMc20 obz5dL2yiWjK88L48ByOvzNunuqzCItx3/cpEgYWgEFCs45ws1Qsd7I3cJTfNik= =10nc -----END PGP SIGNATURE----- --DEqRnbnHhSfCwbkd98RDOhkUAo0Qs4ro2-- From nobody Wed Jun 1 06:49:48 2016 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 CB5F212D1E7 for ; Wed, 1 Jun 2016 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dss-corp-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyQs_JG06fK1 for ; Wed, 1 Jun 2016 06:49:29 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F138912B074 for ; Wed, 1 Jun 2016 06:49:28 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id z123so19978573itg.0 for ; Wed, 01 Jun 2016 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dss-corp-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=dkWbQ4nlGIuox2Clcob9xrgtXS0eVpnWSXjMq0W9sqU=; b=k0EPlxm3FdgQnkPPRR+nV0cD9YDMC6oDzoUGKlhSAj+4TBawuRA5Lri6WB8wZESvcX kjHFd4IunOASe80+/jtgnvhbJyKbx5cqaGi2fzujPXngatqKTZxw3S7CcsI3yixcxxpv X/0BCYckg3HDCqUIULz2adY0la/lZv/TI/6egXak0zot/4krXb+qvUvgU+Dg4ZkGnYnW 3J2mlsqAkmEIybhedohlW12Vjo4Ns0lhLRDL3a5cyDwwT8dno/KGFw9rAKRigMqWIyEf llrbNuOo+/Nk63PGoQZsNxGb9KCWmXnHGxglInCc+a50ObRycU6JLjcv8RR95W6061nw 2oxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=dkWbQ4nlGIuox2Clcob9xrgtXS0eVpnWSXjMq0W9sqU=; b=nG2spW1uGxHA45wouT1/ocJCkM/yCvcfG0pj/fyi7NUhnG2cGBmadss+pHwE67/cV1 tMEnHA0MTzLiQ0/wGrfa6DiqTYQJBuMAAFOsgpAKdQcXy/jH+pnZBy8JcEGIAP5Zwsxk CrFtoI6WhRq5nwqG16fK7y8sxRIV6SK3t2drGMmGipaTB/wLIAv0kalxElB1pva9IbUM pc/wuMYIdKM0q7fmEI3tUHR2g0W9ZsBJnb5hNki9J1XuVR4tMWpKDzN44jtPBSkE55rF NUPYpU5Vzu/2ZmKsaWV3gU55ryFvs1UWKuhEo9lQqt3BRICJ09TZAAqh5fN2UOhdH3Xd LPBw== X-Gm-Message-State: ALyK8tLT0OEQkI5xFeLH5Ebp4xwLxQSwqVRk9zGcH98COoKwNX5B5rB4OqN5rsJmrxrcUSs3 X-Received: by 10.36.74.199 with SMTP id k190mr6085195itb.36.1464788968181; Wed, 01 Jun 2016 06:49:28 -0700 (PDT) Received: from mlsprecision (cpe-74-136-170-54.kya.res.rr.com. [74.136.170.54]) by smtp.gmail.com with ESMTPSA id e65sm12151575ith.11.2016.06.01.06.49.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 06:49:27 -0700 (PDT) From: "Michael Smith" To: "'Roger Marshall'" , References: In-Reply-To: Date: Wed, 1 Jun 2016 09:49:23 -0400 Message-ID: <005901d1bc0c$68ccb290$3a6617b0$@dss-corp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01D1BBEA.E1BB1290" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI/IJAohLLS80gTyMaGLAVqnEiih57514pQ Content-Language: en-us Archived-At: Cc: marc.linsner@cisco.com Subject: Re: [Ecrit] lost-planned-changes WG Adoption and WGLC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 13:49:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01D1BBEA.E1BB1290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support adopting the draft as an ECRIT WG item. Michael Smith Chief Technologist, DSS Corp. Ph: 606.877.2788 | Mobile: 606.231.0243 From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, May 31, 2016 6:53 PM To: ecrit@ietf.org Cc: marc.linsner@cisco.com Subject: [Ecrit] lost-planned-changes WG Adoption and WGLC At our ECRIT meeting in BA, the work group agreed with the chairs' action to request of the list, adoption of this ID as an official WG item, with the intention of submitting it for WGLC, once adopted. This is reflected in the posted meeting notes. Does anyone object to adopting this draft as an ECRIT working group item? https://www.ietf.org/archive/id/draft-rosen-ecrit-lost-planned-changes-03.tx t Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and/or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media. ------=_NextPart_000_005A_01D1BBEA.E1BB1290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adopting the draft as an ECRIT WG = item.

 

Michael Smith

Chief Technologist, DSS = Corp.

Ph: 606.877.2788 | Mobile: = 606.231.0243

 

From: Ecrit = [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger = Marshall
Sent: Tuesday, May 31, 2016 6:53 PM
To: = ecrit@ietf.org
Cc: marc.linsner@cisco.com
Subject: = [Ecrit] lost-planned-changes WG Adoption and = WGLC

 

At our ECRIT = meeting in BA, the work group agreed with the chairs’ action to = request of the list, adoption of this ID as an official WG item, with = the intention of submitting it for WGLC, once adopted.  This is = reflected in the posted meeting notes.

 

Does anyone = object to adopting this draft as an ECRIT working group item? =

 

https://www.ietf.org/archive/id/draft-rosen-ecrit-lost-plan= ned-changes-03.txt

 

Roger = Marshall & Marc Linsner

ECRIT = Chairs

 

NOTICE TO RECIPIENT: This email, = including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. = export laws and regulations and may be restricted from disclosure by = applicable State and Federal law. Nothing in this email shall create any = legal binding agreement between the parties unless expressly stated = herein and provided by an authorized representative of Comtech = Telecommunications Corp. or its subsidiaries. If you are not the = intended recipient of this message, be advised that any dissemination, = distribution, or use of the contents of this message is strictly = prohibited. If you received this message in error, please notify us = immediately by return email and permanently delete all copies of the = original email and any attached documentation from any computer or other = media.

------=_NextPart_000_005A_01D1BBEA.E1BB1290-- From nobody Wed Jun 1 16:04:06 2016 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 E3D1112B005 for ; Wed, 1 Jun 2016 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNR_vQ3ODcEu for ; Wed, 1 Jun 2016 16:04:03 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1220B12B05D for ; Wed, 1 Jun 2016 16:04:02 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id u51N3u5H004578 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2016 16:03:56 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.16]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Wed, 1 Jun 2016 16:03:55 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYA== Date: Wed, 1 Jun 2016 23:03:55 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC398C2EBESEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 23:04:05 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C2EBESEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C2EBESEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

=0A

<= span style=3D"font-family: ;">NOTICE TO RECIPIENT: This e= mail, including=0Aattachments, may contain information which is confidentia= l, proprietary,=0Aattorney-client privileged and/or controlled under U.S. e= xport laws and=0Aregulations and may be restricted from disclosure by appli= cable State and=0AFederal law. Nothing in this email shall create any legal= binding agreement=0Abetween the parties unless expressly stated herein and= provided by an authorized=0Arepresentative of Comtech Telecommunications C= orp. or its subsidiaries. If you=0Aare not the intended recipient of this m= essage, be advised that any=0Adissemination, distribution, or use of the co= ntents of this message is strictly=0Aprohibited. If you received this messa= ge in error, please notify us immediately=0Aby return email and permanently= delete all copies of the original email and any=0Aattached documentation f= rom any computer or other media.

=0A=0A=0A --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C2EBESEAEXMB2telecom_-- From nobody Thu Jun 2 11:35:09 2016 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 B591A12B01E for ; Thu, 2 Jun 2016 11:35: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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehHhHqnkxIQh for ; Thu, 2 Jun 2016 11:35:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA812D09A for ; Thu, 2 Jun 2016 11:35:05 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 2 Jun 2016 11:35:04 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jun 2016 11:35:02 -0700 To: "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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:35:08 -0000 Hi Everyone, A few weeks ago, Brian and I had discussions with Paul Kyzivat and Robert Sparks, and came to the conclusion that the draft should be modified slightly so that the reply to a mid-call request for an updated MSD (ecall) or VEDS (car-crash) goes in a new INFO message, and that for consistency, the INFO package registration will say that no body type is associated with it, and it is restricted to be used only when emergency call data is being sent using the Call-Info header field mechanism per additional-data. The result is that the draft will change so that all body parts are sent per the additional-data Call-Info header field mechanism, and if the PSAP sends a mid-call request for updated crash data, the vehicle sends a response message to that INFO and a new INFO request message containing the data (simultaneously). Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a preference by several representatives that when there is a mid-call request for an updated MSD, the updated MSD is sent in its own INFO rather than the response to the requesting INFO, so this is in alignment with the change the authors agreed with neutral SIP experts. Further, 3GPP indicated they want the MSD to be encoded in ASN.1 rather than XML (both encodings are specified by CEN in EN 15722). When this was previously discussed within the IETF, participants expressed concern over using ASN.1, but in light of 3GPP's preference, and because SIP can use binary content-transfer-encoding for body parts, I will make this change unless the group objects. Because of this, I don't see a need to have an interim call. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You never finish a program, you just stop working on it. From nobody Thu Jun 2 13:54:53 2016 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 EE31D12D831 for ; Thu, 2 Jun 2016 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbO1XBluWtYR for ; Thu, 2 Jun 2016 13:54:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6298E12D82F for ; Thu, 2 Jun 2016 13:54:46 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-ec-57509d142ff2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.F4.27088.41D90575; Thu, 2 Jun 2016 22:54:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 22:54:44 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBA= Date: Thu, 2 Jun 2016 20:54:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7iq7I3IBwgzf79CwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4Mpo/vyZtWCDcMW9qa3MDYyH+LsYOTkkBEwk pk4+zwhhi0lcuLeerYuRi0NI4AijxItdz5khnMWMEg1XNgE5HBxsAhYS3f+0QUwRgRCJlvdc IKawgKHE98nlIGNEBIwk9jbsZoKwrSQ+XrnCBmKzCKhI3Hz/lgmknFfAV6JhqhCIKSRQJXFl Xy1IBSfQMY+2nmEHsRmBjvl+ag3YFGYBcYlbT+YzQRwpILFkz3lmCFtU4uXjf6wQtpLEiu2X GCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyU m25kpJdalJlcXJyfp5eXWrKJERgfB7f8NtjB+PK54yFGAQ5GJR7eB1H+4UKsiWXFlbmHGCU4 mJVEeF/OCAgX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnV wDjD8YiR7L8f7K8+12TH/9jfFnD3wrurL88ZRWfekv1wtS2vv623YE+iXrOEyt3nYc7WNns6 4/uyhU89yVHXn19pV+tQ3RX040XLAbYJLE+5mXvXnM3hPya4t0b44bXFgR93xL5VK3Fv9ZJ6 ulltkozW45eVK25ZLbJUPKzUK8e6bfHZrEti15VYijMSDbWYi4oTAdUSageLAgAA Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:54:51 -0000 Hi, >A few weeks ago, Brian and I had discussions with Paul Kyzivat and Robert = Sparks, and came to the conclusion that the draft should be modified slight= ly so that the reply to a mid-call request for an >updated MSD (ecall) or V= EDS (car-crash) goes in a new INFO message, and that for consistency, the I= NFO package registration will say that no body type is associated with it, = and it is restricted to be used >only when emergency call data is being sen= t using the Call-Info header field mechanism per additional-data.=20 I am not sure I understand. The main purpose of the INFO package is for car= rying ecall information, and that ecall information is carried as a message= body, so how can one claim that the message body is not associated with th= e INFO package??? If the INFO package is supposed to be able to carry additional data you nee= d to fix draft-additional-data instead, and allow the information to be ass= ociated with an INFO package. >The result is that the draft will change so that all body parts are sent p= er the additional-data Call-Info header field mechanism, and if the PSAP se= nds a mid-call request for updated crash data, the vehicle >sends a respons= e message to that INFO and a new INFO request message containing the data (= simultaneously). > >Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a prefer= ence by several representatives that when there is a mid-call request for a= n updated MSD, the updated MSD is sent in its own >INFO rather than the res= ponse to the requesting INFO, so this is in alignment with the change the a= uthors agreed with neutral SIP experts. Note that this is related to the issue raised in ECRIT earlier, that you ca= nnot not send *ANY* INFO package related information in an INFO response, a= s per RFC 6086. >Further, 3GPP indicated they want the MSD to be encoded in ASN.1 rather th= an XML (both encodings are specified by CEN in EN 15722).=20 >When this was previously discussed within the IETF, participants expressed= concern over using ASN.1, but in light of 3GPP's preference, and because S= IP can use binary content-transfer-encoding for=20 > body parts, I will make this change unless the group objects. > > Because of this, I don't see a need to have an interim call. I'll let others decide on that, but I don't agree with the Call-Info thing = - unless I've misunderstood something. Regards, Christer From nobody Thu Jun 2 20:50:44 2016 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 2CC9812B025 for ; Thu, 2 Jun 2016 20:50:41 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdHq3ll9W-Lw for ; Thu, 2 Jun 2016 20:50:39 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 34DA412D0EA for ; Thu, 2 Jun 2016 20:50:39 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 2 Jun 2016 20:50:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jun 2016 20:50:36 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 03:50:41 -0000 Hi Christer, At 8:54 PM +0000 6/2/16, Christer Holmberg wrote: > Hi, > >>A few weeks ago, Brian and I had discussions with Paul Kyzivat and >> Robert Sparks, and came to the conclusion that the draft should be >> modified slightly so that the reply to a mid-call request for >> an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >> message, and that for consistency, the INFO package registration >> will say that no body type is associated with it, and it is >> restricted to be used >only when emergency call data is being sent >> using the Call-Info header field mechanism per additional-data. > > I am not sure I understand. The main purpose of the INFO package is > for carrying ecall information, and that ecall information is > carried as a message body, so how can one claim that the message > body is not associated with the INFO package??? As I understand it after the discussions with Paul and Robert, the INFO package registration provides a way to authorize sending body parts that are associated with the INFO package, but that means that the draft has two ways of authorizing sending the same body parts: the base way from additional-data / Call-Info, and the INFO package registration. So, this is a very minor change that means that the authorization to send body parts is always per additional-data (using Call-Info), and the INFO package registration says that INFO can be used to send data per additional-data. > > If the INFO package is supposed to be able to carry additional data > you need to fix draft-additional-data instead, and allow the > information to be associated with an INFO package. Only the ecall draft (and by extension car-crash) needs to use INFO. > >>The result is that the draft will change so that all body parts are >> sent per the additional-data Call-Info header field mechanism, and >> if the PSAP sends a mid-call request for updated crash data, the >> vehicle >sends a response message to that INFO and a new INFO >> request message containing the data (simultaneously). >> >>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >> preference by several representatives that when there is a >> mid-call request for an updated MSD, the updated MSD is sent in >> its own >INFO rather than the response to the requesting INFO, so >> this is in alignment with the change the authors agreed with >> neutral SIP experts. > > Note that this is related to the issue raised in ECRIT earlier, > that you cannot not send *ANY* INFO package related information in > an INFO response, as per RFC 6086. Yes, and the draft currently says that the info that is sent is not INFO package related, but additional-data related, however, the change will be that the data will be sent in a new INFO message, which is exactly what you have been asking for. > >>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 >> rather than XML (both encodings are specified by CEN in EN 15722). >>When this was previously discussed within the IETF, participants >> expressed concern over using ASN.1, but in light of 3GPP's >> preference, and because SIP can use binary >> content-transfer-encoding for >> body parts, I will make this change unless the group objects. >> >> Because of this, I don't see a need to have an interim call. > > I'll let others decide on that, but I don't agree with the > Call-Info thing - unless I've misunderstood something. > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The well-bred contradict other people. The wise contradict themselves. --Oscar Wilde From nobody Thu Jun 2 23:32:42 2016 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 5594412D0DE for ; Thu, 2 Jun 2016 23:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7nzY6PgjwUx for ; Thu, 2 Jun 2016 23:32:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A25B12B020 for ; Thu, 2 Jun 2016 23:32:38 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-d0-57512485291c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.A2.12926.58421575; Fri, 3 Jun 2016 08:32:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 08:32:37 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAMDD4A Date: Fri, 3 Jun 2016 06:32:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3D00242334FDEB429B9733FA3D6AFBEA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7qG6rSmC4wfvLkhaNi56yWnx/3sXo wOSxZMlPJo+tdx6zBDBFcdmkpOZklqUW6dslcGUc/7SNsaBLqmLjt7AGxlciXYycHBICJhIP Nvxgg7DFJC7cWw9kc3EICRxhlHh66hqUs5hRYu+lR4xdjBwcbAIWEt3/tEFMEYEQiZb3XCC9 wgKGEr+uLAebIyJgJLG3YTcThO0m8X7iLGYQm0VAReLci+9gU3gFrCR+t2hBTH/BKHHywDyw Xk6ge86v62IHsRmB7vl+ag3YHGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wgtqiAnsSXe/PA 5ksIKElM25oG0Wog8f7cfGYI21pi1dy37BC2tsSyha/B4rwCghInZz5hmcAoPgvJtllI2mch aZ+FpH0WkvYFjKyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQIj7eCW36o7GC+/cTzEKMDB qMTDm7AmIFyINbGsuDL3EKMEB7OSCO8DocBwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXD hQTSE0tSs1NTC1KLYLJMHJxSDYxm9ptsp4jdKn3Dp3isOfzIiqXXV8QsCLYxl7r133a76lud WdOeWySf2L911b9PqRpK/5R3MPyXf61ULV125Yyoc8DGErHe9JOX3evsrasrPLU1zSq6tdW8 J4kc2xmmnF0tucc0wXGZg87cC4u8j/3Stf705shBPb2vjRd3zlul5fVBUfvHMx0lluKMREMt 5qLiRABOrA+1sAIAAA== Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 06:32:41 -0000 Hi, >>>A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>> Robert Sparks, and came to the conclusion that the draft should be >>> modified slightly so that the reply to a mid-call request for >>> an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>> message, and that for consistency, the INFO package registration >>> will say that no body type is associated with it, and it is >>> restricted to be used >only when emergency call data is being sent >>> using the Call-Info header field mechanism per additional-data. >> >> I am not sure I understand. The main purpose of the INFO package is >> for carrying ecall information, and that ecall information is >> carried as a message body, so how can one claim that the message >> body is not associated with the INFO package??? > >As I understand it after the discussions with Paul and Robert, the >INFO package registration provides a way to authorize sending body >parts that are associated with the INFO package, Correct. > but that means that >the draft has two ways of authorizing sending the same body parts: >the base way from additional-data / Call-Info, and the INFO package >registration. That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO package mechanism. >So, this is a very minor change that means that the >authorization to send body parts is always per additional-data (using >Call-Info), and the INFO package registration says that INFO can be >used to send data per additional-data. Again, that is wrong. Information in INFO must be carried using the INFO package mechanism. Note, though, that I am only talking about INFO. How you carry information in e.g. INVITE is a separate issue. >>If the INFO package is supposed to be able to carry additional data >> you need to fix draft-additional-data instead, and allow the >> information to be associated with an INFO package. > >Only the ecall draft (and by extension car-crash) needs to use INFO. That makes me even more confused why you would want to use something else than an INFO package=8A >>>The result is that the draft will change so that all body parts are >>> sent per the additional-data Call-Info header field mechanism, and >>> if the PSAP sends a mid-call request for updated crash data, the >>> vehicle >sends a response message to that INFO and a new INFO >>> request message containing the data (simultaneously). >>> >>>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >>> preference by several representatives that when there is a >>> mid-call request for an updated MSD, the updated MSD is sent in >>> its own >INFO rather than the response to the requesting INFO, so >>> this is in alignment with the change the authors agreed with >>> neutral SIP experts. >> >> Note that this is related to the issue raised in ECRIT earlier, >> that you cannot not send *ANY* INFO package related information in >> an INFO response, as per RFC 6086. > >Yes, and the draft currently says that the info that is sent is not >INFO package related, but additional-data related, however, the >change will be that the data will be sent in a new INFO message, >which is exactly what you have been asking for. And I appreciate that :) Regards, Christer From nobody Fri Jun 3 03:59:40 2016 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 B469812D0EF for ; Fri, 3 Jun 2016 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJBY95nYr9hE for ; Fri, 3 Jun 2016 03:59:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769FF12B008 for ; Fri, 3 Jun 2016 03:59:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-e9-57516316762f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.A6.18043.61361575; Fri, 3 Jun 2016 12:59:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 12:59:33 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAMDD4AAAbjr6A= Date: Fri, 3 Jun 2016 10:59:33 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011641B384@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011641B384ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdQFcsOTDc4OYrQYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0d/zgqVgjVzFtn8KDYzLpLsYOTkkBEwk/h58zgphi0lcuLee DcQWEjjCKLHtp2MXIxeQvZhR4lhPDwtIgk1AT2LiliNgDSICqhIbzqxk7GLk4BAWMJT4Prkc ImwksbdhNxOE7SexdOJjsJksAioSfXuOMoPYvAK+EgfWHWSDmD+TSWL5oTawIk4Ba4mFq9vA ihgFZCWu/ullBLGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9BPaAk0bjkCStEfb7EpIajrBDL BCVOznzCMoFRZBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX 56YbGemlFmUmFxfn5+nlpZZsYgRG0MEtv612MB587niIUYCDUYmHN2FNQLgQa2JZcWXuIUYJ DmYlEd6dIYHhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODil GhhZ9r5wOju3qNVPc86yP1P9eM2f1ZVzHzs9f2XJSTaeu7vP/mf5a3Fs2/f/ac83cbybWqbv Hs7+YMWqTXNml7RNn/uGb2H2zu8vLOZfvf0jf+PvgGe7FFZYiXHkP5pSrxPwehurxZe+HvF7 OuVx2o8mTXxZuCvUVWPP7MOH/dY+03+V3PfK/tqDFCWW4oxEQy3mouJEAKVSfjycAgAA Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 10:59:39 -0000 --_000_39B5E4D390E9BD4890E2B310790061011641B384ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, FYI - 3GPP CT WG1 so far agreed the following eCall related CRs: - http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1= -163032.zip - http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1= -163060.zip Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B310790061011641B384ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

FYI  - 3GPP CT W= G1 so far agreed the following eCall related CRs:

- http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1-1= 63032.zip

- http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1-1= 63060.zip

 

Kind regards

 

Ivo Sedlacek

 

 

--_000_39B5E4D390E9BD4890E2B310790061011641B384ESESSMB301erics_-- From nobody Fri Jun 3 04:35:17 2016 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 E075412D0BE for ; Fri, 3 Jun 2016 04:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3byg8KabRYTb for ; Fri, 3 Jun 2016 04:35:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C3312D10A for ; Fri, 3 Jun 2016 04:35:13 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-92-57516b6f5bc5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.95.12516.F6B61575; Fri, 3 Jun 2016 13:35:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 13:35:11 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRvYv8jpdjlfHy+k2dXgDBH4NmkQ== Date: Fri, 3 Jun 2016 11:35:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7nG5+dmC4wfGXChaNi56yOjB6LFny kymAMYrLJiU1J7MstUjfLoEr497i1SwFR9kqvjx+xNTAOJO1i5GTQ0LAROLdzkuMELaYxIV7 69m6GLk4hASOMEo0zWtkh3AWM0os3PEZKMPBwSZgIdH9TxukQURAVWLDmZVgzcIC3hLH2v8y QsSDJDYffMQIUi4ioCcx85gkiMkioCLxeXE1SAWvgJXEtxnPmEBsRqC130+tAbOZBcQlbj2Z zwRxjoDEkj3nmSFsUYmXj/+BnSwKNPHLvXlQJytKtD9tYITo1ZO4MXUKG4RtLbFkehcLhK0t sWzha2aIvYISJ2c+YZnAKDoLybpZSNpnIWmfhaR9FpL2BYysqxhFi1OLi3PTjYz1Uosyk4uL 8/P08lJLNjEC4+Tglt+6OxhXv3Y8xCjAwajEw5uwJiBciDWxrLgy9xCjBAezkgjvlPTAcCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M7qzJF18pCPmf O87kXKi6+9ia10Y+FhP0+/OMP2gsM5E3MRUt9fqSleESuWrmW/6nBo7Hfs2cXy5vqhJtcsL9 ibGW08paI6/zr3vVnq24dmDemo21NxfIaTHtWzkt8JXAh9dekjeCnzmfSA3n/XHJT3/eTKbb hnf/dEe+bXzj01kgrH++m7FPiaU4I9FQi7moOBEAhWVHbY8CAAA= Archived-At: Subject: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:35:16 -0000 Hi, 3GPP agreed that, when communicating with a PSTN PSAP, it shall be possible to transport MSD using a legacy modem on the media plane. The reason is for not mandating the network to perform =B3interworking between MSD transported in INVITE/INFO and MSD transported using a legacy modem on the media plane=B2. I don=B9t think the ecall draft needs to consider WHEN the MSD will be transported using a legacy modem on the media plane, but I think the draft should describe the possibility, so that PSAPs are aware of it. Also, as the same eCall URNs will be used for calls where the MSD is transported using a legacy modem on the media plane, the draft must enable usage of the eCall URNs in setup of an IMS emergency call where MSD is transported using the legacy modem on the media plane. Regards, Christer From nobody Fri Jun 3 04:39:05 2016 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 E37AF12D14C for ; Fri, 3 Jun 2016 04:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L86jnUoI4f_7 for ; Fri, 3 Jun 2016 04:39:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A07512D117 for ; Fri, 3 Jun 2016 04:39:02 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-c2-57516c53568b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.CD.27088.35C61575; Fri, 3 Jun 2016 13:39:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 13:38:55 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: 3GPP impact on draft-ecall: max MSD size Thread-Index: AQHRvYyCuKnlNwmQdEOpxT17mnWaKw== Date: Fri, 3 Jun 2016 11:38:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D37747B09B2Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdSTckJzDc4PpyBYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XqnRcEUwYqe3RfYGhhP83UxcnJICJhI7Jv4gg3CFpO4cG89 kM3FISRwhFHi9J0LjBDOYkaJlodvWLoYOTjYBCwkuv9pgzSICKhKbDizkhHEFhYwknhydgM7 RNxc4tarrYwQtp5E775ZTCA2i4CKxJ6dD5lBbF4BK4lNay+AxRmBFn8/tQbMZhYQl7j1ZD4T xEECEkv2nGeGsEUlXj7+xwpiiwLN/HJvHiNEXFHi46t9jBC98RITz61jh5gvKHFy5hOWCYzC s5CMnYWkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCtJX7+PsWCrGYBI8cqRtHi1OKk 3HQjI73Uoszk4uL8PL281JJNjMAIOrjlt8EOxpfPHQ8xCnAwKvHwJqwJCBdiTSwrrsw9xCjB wawkwjslPTBciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dU A2M944E9ud+V7xr3NSoxnWj8d/y91OGWnTEBVXNXOn4WejjjxYn2iruzLSoyLpQ82n79mITK 292hBw1iNr4pYIif1NGSqrZHmWl5ScfSFy7SDUcV6l7mC53YIurJ+6xQifu83RSNZ9oTXl+6 +txd7Lv2Zr4nlVucKpbsd7ovoPClWO1b83X1f2lKLMUZiYZazEXFiQBkTkJnnAIAAA== Archived-At: Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:39:04 -0000 --_000_D37747B09B2Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has specified a maximum size of 140 bytes for the MSD. We either need = to make that a general limit for the info package, or we need to have a mec= hanism to indicate the max size. Indicating the max size can be done e.g. b= y defining an Recv-Info header field info package parameter. Example: Recv-Info: emergencyCallData.eCall; max-msd-size=3D140 Note that the size represents the size of the MSD in raw binary format =96 = depending on the encoding the size may be bigger =93on the wire=94. Regards, Christer --_000_D37747B09B2Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <34DCA62C07D98D4BA18353F61438814B@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

3GPP has specified a maximum size of 140 bytes for the MSD. We either = need to make that a general limit for the info package, or we need to have = a mechanism to indicate the max size. Indicating the max size can be done e= .g. by defining an Recv-Info header field info package parameter.

Example:

Recv-Info: = ;emergencyCallData.eCall;= max-msd-size=3D140

Note that the size represents the size of the MSD in raw binary format= =96 depending on the encoding the size may be bigger =93on the wire=94.

Regards,

Christer
--_000_D37747B09B2Dchristerholmbergericssoncom_-- From nobody Fri Jun 3 05:07:52 2016 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 3379C12D12A for ; Fri, 3 Jun 2016 05:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In3ioJ7wzSw0 for ; Fri, 3 Jun 2016 05:07:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3833912D161 for ; Fri, 3 Jun 2016 05:07:49 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-3d-575173138b90 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.D2.27088.31371575; Fri, 3 Jun 2016 14:07:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 14:07:47 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: MSD ASN.1 encoding (was: [Ecrit] ECRIT Interim meeting - June) Thread-Index: AQHRvZCKLTz3YMrTTUWDi4YaYdz44Q== Date: Fri, 3 Jun 2016 12:07:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdTFe4ODDc4PIbZYvGRU9ZLb4/72J0 YPJYsuQnk8fWO49ZApiiuGxSUnMyy1KL9O0SuDKeflzDUvCFuWLSrSbmBsaJzF2MnBwSAiYS s3efZoWwxSQu3FvP1sXIxSEkcIRRYkLXJyhnMaPEx84VLF2MHBxsAhYS3f+0QUwRgRCJlvdc IL3CAu4Si7ZsYwKxRQR8JOZc+cEOYetJ7H8/iw3EZhFQkViwtR9sL6+AlcS9pzfB6hmB9n4/ tQbMZhYQl7j1ZD4TxD0CEkv2nIe6U1Ti5eN/YHeKAs38cm8eI8gJEgJKEtO2pkG06kgs2P2J DcK2ltjccBHK1pZYtvA11FpBiZMzn7BMYBSdhWTbLCTts5C0z0LSPgtJ+wJG1lWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgbFzcMtvgx2ML587HmIU4GBU4uFNWBMQLsSaWFZcmXuIUYKD WUmE909BYLgQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkG RqF3Mkc4Ap8wB9geb+xZvSa8XunTlHqVE/tVnqjXJvoofNuVqqF79VjZvKzcrKW3bhRfXDhj dfO+XedTHnuwOzIKtCaxTIw8WT5ha2wa3/m62+mv/i559074zpreEy8n2U3WehQ8ZZ7BQtmc l5ILgl83l8me833WydW0OYshZdJci2n7D8kwCyuxFGckGmoxFxUnAgCOK17ymQIAAA== Archived-At: Subject: [Ecrit] MSD ASN.1 encoding (was: ECRIT Interim meeting - June) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:07:51 -0000 Hi, ... >Further, 3GPP indicated they want the MSD to be encoded in ASN.1 >rather than XML (both encodings are specified by CEN in EN 15722). >When this was previously discussed within the IETF, participants >expressed concern over using ASN.1, but in light of 3GPP's >preference, and because SIP can use binary content-transfer-encoding >for body parts, I will make this change unless the group objects. Could you describe example what you intend to change? Regards, Christer From nobody Fri Jun 3 06:57:16 2016 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 7575F12B029 for ; Fri, 3 Jun 2016 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu2lpGyyIU77 for ; Fri, 3 Jun 2016 06:57:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9217212D581 for ; Fri, 3 Jun 2016 06:57:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 27080BFD8A26C; Fri, 3 Jun 2016 13:57:07 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53Dv9o0027298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 13:57:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53Dv69W024317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 15:57:07 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 15:57:07 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: max MSD size Thread-Index: AQHRvYyCuKnlNwmQdEOpxT17mnWaK5/XpenQ Date: Fri, 3 Jun 2016 13:57:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0DD72@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.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF0DD72FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:57:14 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF0DD72FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe this is playing with words, but the MSD always has a maximum size of = 140 octets, and has a standard content defined by the existing CEN document= . If there is data beyond this existing data content definition, it is no lon= ger the MSD, but some other data set, that needs to be called something els= e. I wonder if we actually have two different info packages, rather than some = package parameter, i.e. package v1 with MSD only, package v2 etc with addit= ional data beyond MSD. 3GPP release 14 only requires v1 at the moment. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 03 June 2016 12:39 To: ecrit@ietf.org Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size Hi, 3GPP has specified a maximum size of 140 bytes for the MSD. We either need = to make that a general limit for the info package, or we need to have a mec= hanism to indicate the max size. Indicating the max size can be done e.g. b= y defining an Recv-Info header field info package parameter. Example: Recv-Info: emergencyCallData.eCall; max-msd-size=3D140 Note that the size represents the size of the MSD in raw binary format - de= pending on the encoding the size may be bigger "on the wire". Regards, Christer --_000_949EF20990823C4C85C18D59AA11AD8BADF0DD72FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe this is playing wit= h words, but the MSD always has a maximum size of 140 octets, and has a sta= ndard content defined by the existing CEN document.

 <= /p>

If there is data beyond t= his existing data content definition, it is no longer the MSD, but some oth= er data set, that needs to be called something else.

 <= /p>

I wonder if we actually h= ave two different info packages, rather than some package parameter, i.e. p= ackage v1 with MSD only, package v2 etc with additional data beyond MSD. 3GPP release 14 only requires v1 at the moment.

 <= /p>

 <= /p>

Keith

 <= /p>

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 03 June 2016 12:39
To: ecrit@ietf.org
Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size=

 

Hi,

 

3GPP has specified a maximu= m size of 140 bytes for the MSD. We either need to make that a general limi= t for the info package, or we need to have a mechanism to indicate the max size. Indicating the max size can be done e.g. by definin= g an Recv-Info header field info package parameter.

 

Example:<= /p>

 

Recv-Info: emergencyCa= llData.eCall; max-msd-size=3D140

 

Note that the size represen= ts the size of the MSD in raw binary format – depending on the encodi= ng the size may be bigger “on the wire”.

 

Regards,<= /p>

 

Christer<= /p>

--_000_949EF20990823C4C85C18D59AA11AD8BADF0DD72FR712WXCHMBA11z_-- From nobody Fri Jun 3 06:57:28 2016 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 34E4E12D581 for ; Fri, 3 Jun 2016 06:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWqFPk_wxoC7 for ; Fri, 3 Jun 2016 06:57:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556D612D69E for ; Fri, 3 Jun 2016 06:57:21 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 46CD269AC8B79; Fri, 3 Jun 2016 13:57:17 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53DvJEn027968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 13:57:19 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53DvFEE024612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 15:57:18 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 15:57:14 +0200 From: "Drage, Keith (Nokia - GB)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABOcQ8Q Date: Fri, 3 Jun 2016 13:57:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0ED7B@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.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF0ED7BFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:57:25 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF0ED7BFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would be nice to see some response to the extensive comments I have made= before we fix such a meeting. Regards Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 02 June 2016 00:04 To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_949EF20990823C4C85C18D59AA11AD8BADF0ED7BFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would be nice to se= e some response to the extensive comments I have made before we fix such a = meeting.

 

Regards

 

Keith

 

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 02 June 2016 00:04
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

NOTICE TO RECIPIENT: This em= ail, including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. export= laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email= shall create any legal binding agreement between the parties unless expres= sly stated herein and provided by an authorized representative of Comtech T= elecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any= dissemination, distribution, or use of the contents of this message is str= ictly prohibited. If you received this message in error, please notify us i= mmediately by return email and permanently delete all copies of the original email and any attached documentation fro= m any computer or other media.

--_000_949EF20990823C4C85C18D59AA11AD8BADF0ED7BFR712WXCHMBA11z_-- From nobody Fri Jun 3 07:17:03 2016 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 B882C12D1A9 for ; Fri, 3 Jun 2016 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj_ZFwIp88Al for ; Fri, 3 Jun 2016 07:17:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD03212B029 for ; Fri, 3 Jun 2016 07:16:59 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BB8BE6AF73ADB; Fri, 3 Jun 2016 14:16:55 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53EGvbc024563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 14:16:58 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53EGrMX000835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 16:16:57 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 16:16:56 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAW9NCg Date: Fri, 3 Jun 2016 14:16:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0EDC8@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> 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.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:17:03 -0000 I would note that as one of the major commenters on this document, I have n= ot been involved in this discussion, not has it appeared prior to this on t= he WG list. I think you absolutely need to separate what goes in the INFO mechanism as = an attached body, and what goes in other messages. The additional-data mech= anism should not be used to regulate the transfer of INFO packages. That comment also probably applies to other messages designed for transferr= ing packages, e.g. SUBSCRIBE/NOTIFY as well. Regards Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 03 June 2016 04:51 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Hi Christer, At 8:54 PM +0000 6/2/16, Christer Holmberg wrote: > Hi, > >>A few weeks ago, Brian and I had discussions with Paul Kyzivat and =20 >>Robert Sparks, and came to the conclusion that the draft should be =20 >>modified slightly so that the reply to a mid-call request for an=20 >>>updated MSD (ecall) or VEDS (car-crash) goes in a new INFO message,=20 >>and that for consistency, the INFO package registration will say that=20 >>no body type is associated with it, and it is restricted to be used=20 >>>only when emergency call data is being sent using the Call-Info=20 >>header field mechanism per additional-data. > > I am not sure I understand. The main purpose of the INFO package is=20 > for carrying ecall information, and that ecall information is carried=20 > as a message body, so how can one claim that the message body is not=20 > associated with the INFO package??? As I understand it after the discussions with Paul and Robert, the INFO pac= kage registration provides a way to authorize sending body parts that are a= ssociated with the INFO package, but that means that the draft has two ways= of authorizing sending the same body parts:=20 the base way from additional-data / Call-Info, and the INFO package registr= ation. So, this is a very minor change that means that the authorization t= o send body parts is always per additional-data (using Call-Info), and the = INFO package registration says that INFO can be used to send data per addit= ional-data. > > If the INFO package is supposed to be able to carry additional data=20 > you need to fix draft-additional-data instead, and allow the=20 > information to be associated with an INFO package. Only the ecall draft (and by extension car-crash) needs to use INFO. > >>The result is that the draft will change so that all body parts are =20 >>sent per the additional-data Call-Info header field mechanism, and if=20 >>the PSAP sends a mid-call request for updated crash data, the vehicle=20 >>>sends a response message to that INFO and a new INFO request message=20 >>containing the data (simultaneously). >> >>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a =20 >>preference by several representatives that when there is a mid-call=20 >>request for an updated MSD, the updated MSD is sent in its own >INFO=20 >>rather than the response to the requesting INFO, so this is in=20 >>alignment with the change the authors agreed with neutral SIP=20 >>experts. > > Note that this is related to the issue raised in ECRIT earlier, that=20 > you cannot not send *ANY* INFO package related information in an INFO=20 > response, as per RFC 6086. Yes, and the draft currently says that the info that is sent is not INFO pa= ckage related, but additional-data related, however, the change will be tha= t the data will be sent in a new INFO message, which is exactly what you ha= ve been asking for. > >>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 =20 >>rather than XML (both encodings are specified by CEN in EN 15722). >>When this was previously discussed within the IETF, participants =20 >>expressed concern over using ASN.1, but in light of 3GPP's =20 >>preference, and because SIP can use binary content-transfer-encoding=20 >>for >> body parts, I will make this change unless the group objects. >> >> Because of this, I don't see a need to have an interim call. > > I'll let others decide on that, but I don't agree with the Call-Info=20 > thing - unless I've misunderstood something. > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The well-bred contrad= ict other people. The wise contradict themselves. --Oscar Wilde _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Jun 3 08:11:08 2016 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 C76C6128E19 for ; Fri, 3 Jun 2016 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF0d1t8edFHA for ; Fri, 3 Jun 2016 08:10:50 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7110412D6C7 for ; Fri, 3 Jun 2016 08:10:48 -0700 (PDT) X-AuditID: 1207440d-bb3ff7000000090b-13-57519df75ac3 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 72.7A.02315.7FD91575; Fri, 3 Jun 2016 11:10:47 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u53FAkFK014257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2016 11:10:47 -0400 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> Date: Fri, 3 Jun 2016 11:10:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixO6iqPt9bmC4wadFuhaNi56yOjB6LFny kymAMYrbJimxpCw4Mz1P3y6BO2NRzxPGgikaFQ/mfWVqYGxW6GLk5JAQMJH4+HgPYxcjF4eQ wFZGiW1ts5ggnJ9MEj2vmplAqoQFDCV+XVnOBmKLCAhJvLv1lwWiaCaTxPJDbWAJNgEtiTmH /rOA2LwC9hJH3+wBa2YRUJHYd/0EM4gtKpAmcfYahM0rIChxcuYTsHpOAWuJhavbwOLMArYS d+buhrLlJZq3zmaewMg3C0nLLCRls5CULWBkXsUol5hTmqubm5iZU5yarFucnJiXl1qka6SX m1mil5pSuokREmq8Oxj/r5M5xCjAwajEw8uwOCBciDWxrLgy9xCjJAeTkijv+bNAIb6k/JTK jMTijPii0pzU4kOMEhzMSiK80bMDw4V4UxIrq1KL8mFS0hwsSuK8akvU/YQE0hNLUrNTUwtS i2CyMhwcShK86XOAGgWLUtNTK9Iyc0oQ0kwcnCDDuaREilPzUlKLEktLMuJB0RdfDIw/kBQP 0N5EkHbe4oLEXKAoROspRkUpcV5nkIMEQBIZpXlwY2EJ5BWjONCXwrxXQdp5gMkHrvsV0GAm oMEFj/xBBpckIqSkGhjbZ81s6zIN3fQjtOpg26N/nyznWdar/r3TIa/nKnQjzD9bOMHO+8Di Irejthv/JDdeuFh8wHeFzoHg1zk9VTUHNhafUD3IpzQvzyF6+xrpD93zmbg2fxJb+uiM3nrv HwEx3G/qda8wFwSn+86avlc3/43/F9XdjEn94oYz/sme98q2rd+/8bASS3FGoqEWc1FxIgCk vU4m+wIAAA== Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:11:06 -0000 My preferred approach to this was, after the completion of the initial INVITE, to carry the data in real INFO package bodies, using INFO as designed. I was ok with using additional-data call-info with a referenced body part to convey initial info in the INVITE. That *might* mean that some information might need to have two different representations - one via call-info and one via INFO. But some careful redesign could probably avoid the duplication. In passing I mentioned that body parts *can* be attached to pretty much any message. So another way to do what was proposed would be to use additional-data call-info for all, and find some message to piggyback on when there is a need to send something. This could be another message that was going anyway. Or one could find a benign message to send, simply as a vehicle to attach the call-info. This could be a reINVITE or UPDATE, or it could even be an INFO. To use INFO that way there would need to be some validly constructed INFO to send, and then the call-info and its additional-data body part attached to it. Somebody suggested defining an INFO package that has no body. (I was a bit dubious of that. Alternatively one could define a very tiny package body part of no significance.) I think such an approach is *technically* valid. But I find it quite a hack. I think using INFO with a new package that conveys the required data to be a much cleaner, more elegant, approach. Thanks, Paul On 6/3/16 2:32 AM, Christer Holmberg wrote: > Hi, > >>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>>> Robert Sparks, and came to the conclusion that the draft should be >>>> modified slightly so that the reply to a mid-call request for >>>> an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>>> message, and that for consistency, the INFO package registration >>>> will say that no body type is associated with it, and it is >>>> restricted to be used >only when emergency call data is being sent >>>> using the Call-Info header field mechanism per additional-data. >>> >>> I am not sure I understand. The main purpose of the INFO package is >>> for carrying ecall information, and that ecall information is >>> carried as a message body, so how can one claim that the message >>> body is not associated with the INFO package??? >> >> As I understand it after the discussions with Paul and Robert, the >> INFO package registration provides a way to authorize sending body >> parts that are associated with the INFO package, > > Correct. > > >> but that means that >> the draft has two ways of authorizing sending the same body parts: >> the base way from additional-data / Call-Info, and the INFO package >> registration. > > That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO > package mechanism. > > >> So, this is a very minor change that means that the >> authorization to send body parts is always per additional-data (using >> Call-Info), and the INFO package registration says that INFO can be >> used to send data per additional-data. > > Again, that is wrong. Information in INFO must be carried using the INFO > package mechanism. > > Note, though, that I am only talking about INFO. How you carry information > in e.g. INVITE is a separate issue. > > >>> If the INFO package is supposed to be able to carry additional data >>> you need to fix draft-additional-data instead, and allow the >>> information to be associated with an INFO package. >> >> Only the ecall draft (and by extension car-crash) needs to use INFO. > > That makes me even more confused why you would want to use something else > than an INFO packageŠ > > >>>> The result is that the draft will change so that all body parts are >>>> sent per the additional-data Call-Info header field mechanism, and >>>> if the PSAP sends a mid-call request for updated crash data, the >>>> vehicle >sends a response message to that INFO and a new INFO >>>> request message containing the data (simultaneously). >>>> >>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >>>> preference by several representatives that when there is a >>>> mid-call request for an updated MSD, the updated MSD is sent in >>>> its own >INFO rather than the response to the requesting INFO, so >>>> this is in alignment with the change the authors agreed with >>>> neutral SIP experts. >>> >>> Note that this is related to the issue raised in ECRIT earlier, >>> that you cannot not send *ANY* INFO package related information in >>> an INFO response, as per RFC 6086. >> >> Yes, and the draft currently says that the info that is sent is not >> INFO package related, but additional-data related, however, the >> change will be that the data will be sent in a new INFO message, >> which is exactly what you have been asking for. > > And I appreciate that :) > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Jun 3 08:45:27 2016 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 EE4C012D519 for ; Fri, 3 Jun 2016 08:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuCQCORrouRX for ; Fri, 3 Jun 2016 08:45:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829CC12D14A for ; Fri, 3 Jun 2016 08:45:23 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E1CEB6F80D62A; Fri, 3 Jun 2016 15:45:18 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53FjLb8020597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 15:45:21 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53FjKXw006225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 17:45:20 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 17:45:20 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAMDD4AAAu0xoAABVRikA== Date: Fri, 3 Jun 2016 15:45:20 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0EF84@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> In-Reply-To: <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 15:45:26 -0000 I don't think there is anything such as a benign message in SIP. All the methods are there for a defined purpose and carry semantics. So I don't think attaching this to another message is appropriate, except f= or the proper use of that message, i.e. INFO to carry an INFO package, SUBS= CRIBE/NOTIFY to carry an event package and so on.=20 Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 03 June 2016 16:11 To: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June My preferred approach to this was, after the completion of the initial INVI= TE, to carry the data in real INFO package bodies, using INFO as designed. = I was ok with using additional-data call-info with a referenced body part t= o convey initial info in the INVITE. That *might* mean that some informatio= n might need to have two different representations - one via call-info and = one via INFO. But some careful redesign could probably avoid the duplicatio= n. In passing I mentioned that body parts *can* be attached to pretty much any= message. So another way to do what was proposed would be to use additional= -data call-info for all, and find some message to piggyback on when there i= s a need to send something. This could be another message that was going an= yway. Or one could find a benign message to send, simply as a vehicle to at= tach the call-info. This could be a reINVITE or UPDATE, or it could even be= an INFO. To use INFO that way there would need to be some validly constructed INFO t= o send, and then the call-info and its additional-data body part attached t= o it. Somebody suggested defining an INFO package that has no body. (I was = a bit dubious of that. Alternatively one could define a very tiny package b= ody part of no significance.) I think such an approach is *technically* valid. But I find it quite a hack= . I think using INFO with a new package that conveys the required data to b= e a much cleaner, more elegant, approach. Thanks, Paul On 6/3/16 2:32 AM, Christer Holmberg wrote: > Hi, > >>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and=20 >>>> Robert Sparks, and came to the conclusion that the draft should be=20 >>>> modified slightly so that the reply to a mid-call request for an=20 >>>> >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO=20 >>>> message, and that for consistency, the INFO package registration=20 >>>> will say that no body type is associated with it, and it is=20 >>>> restricted to be used >only when emergency call data is being sent=20 >>>> using the Call-Info header field mechanism per additional-data. >>> >>> I am not sure I understand. The main purpose of the INFO package is=20 >>> for carrying ecall information, and that ecall information is=20 >>> carried as a message body, so how can one claim that the message=20 >>> body is not associated with the INFO package??? >> >> As I understand it after the discussions with Paul and Robert, the=20 >> INFO package registration provides a way to authorize sending body=20 >> parts that are associated with the INFO package, > > Correct. > > >> but that means that >> the draft has two ways of authorizing sending the same body parts: >> the base way from additional-data / Call-Info, and the INFO package=20 >> registration. > > That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO=20 > package mechanism. > > >> So, this is a very minor change that means that the authorization to=20 >> send body parts is always per additional-data (using Call-Info), and=20 >> the INFO package registration says that INFO can be used to send data=20 >> per additional-data. > > Again, that is wrong. Information in INFO must be carried using the=20 > INFO package mechanism. > > Note, though, that I am only talking about INFO. How you carry=20 > information in e.g. INVITE is a separate issue. > > >>> If the INFO package is supposed to be able to carry additional data=20 >>> you need to fix draft-additional-data instead, and allow the=20 >>> information to be associated with an INFO package. >> >> Only the ecall draft (and by extension car-crash) needs to use INFO. > > That makes me even more confused why you would want to use something=20 > else than an INFO package=A9 > > >>>> The result is that the draft will change so that all body parts are=20 >>>> sent per the additional-data Call-Info header field mechanism, and=20 >>>> if the PSAP sends a mid-call request for updated crash data, the=20 >>>> vehicle >sends a response message to that INFO and a new INFO=20 >>>> request message containing the data (simultaneously). >>>> >>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a=20 >>>> preference by several representatives that when there is a mid-call=20 >>>> request for an updated MSD, the updated MSD is sent in its own=20 >>>> >INFO rather than the response to the requesting INFO, so this is=20 >>>> in alignment with the change the authors agreed with neutral SIP=20 >>>> experts. >>> >>> Note that this is related to the issue raised in ECRIT earlier,=20 >>> that you cannot not send *ANY* INFO package related information in=20 >>> an INFO response, as per RFC 6086. >> >> Yes, and the draft currently says that the info that is sent is not=20 >> INFO package related, but additional-data related, however, the=20 >> change will be that the data will be sent in a new INFO message,=20 >> which is exactly what you have been asking for. > > And I appreciate that :) > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Jun 3 09:41:00 2016 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 70D9B12D51B for ; Fri, 3 Jun 2016 09:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAz7c1-LNVFk for ; Fri, 3 Jun 2016 09:40:55 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBCF12B00C for ; Fri, 3 Jun 2016 09:40:55 -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.7/8.14.7) with ESMTP id u53GehKe024908 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 09:40:43 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.16]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Fri, 3 Jun 2016 09:40:43 -0700 From: Roger Marshall To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABW0UVw Date: Fri, 3 Jun 2016 16:40:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4CFASEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:40:58 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4CFASEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given a variety of factors, including individuals' availability, the chairs= have decided to Not schedule an interim meeting at this time. We look for= ward to seeing continued list discussion in order to work through the curre= nt issues, and it seems like progress is being made. We also look forward = to getting an updated draft soon, so that folks can see the proposed text c= hanges being discussed. Roger Marshall & Marc Linsner ECRIT Chairs From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, June 01, 2016 4:04 PM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4CFASEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given a variety of fac= tors, including individuals’ availability, the chairs have decided to= Not schedule an interim meeting at this time.  We look forward to see= ing continued list discussion in order to work through the current issues, and it seems like progress is being made. = ; We also look forward to getting an updated draft soon, so that folks can = see the proposed text changes being discussed. 

 

Roger Marshall & M= arc Linsner

ECRIT Chairs

 

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

NOTICE TO RECIPIENT: This em= ail, including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. export= laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email= shall create any legal binding agreement between the parties unless expres= sly stated herein and provided by an authorized representative of Comtech T= elecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any= dissemination, distribution, or use of the contents of this message is str= ictly prohibited. If you received this message in error, please notify us i= mmediately by return email and permanently delete all copies of the original email and any attached documentation fro= m any computer or other media.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4CFASEAEXMB2telecom_-- From nobody Fri Jun 3 09:44:40 2016 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 3B66B12D632 for ; Fri, 3 Jun 2016 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnF-dcL26ub7 for ; Fri, 3 Jun 2016 09:44:36 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5962312D5BA for ; Fri, 3 Jun 2016 09:44:36 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id 8sCaba3QDjuYR8sD5beneR; Fri, 03 Jun 2016 16:44:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464972275; bh=aHO9VimS7VDMrCVD6fajjwXFcPoV5GESMoWA23Wc6m4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=govDjAgqArX4wIuOQgTFACPqkcg5FGIczmL9MiiiOmEx7dmqUO4bYN8tQldS6VfLw 5oc2sl8ovHclz/wpQZh0n5zV3HV5CKASnSy6/UwGfiXOBt7Qa4bER1HsORZ66KrJEM VpRKGDkDJRlTjVgSRlXxHsaJzQ7d0PX0r97jgBt5MvZsVQ7afEgq9bKgRnC4Y7m49t 2FDisEkwhkZ3tV79KURa2JDWSTaJA1TT5K7ILXgGJzKCfQeCyKgntByuG5FpUNMLQ4 QXOwrAK/AbzYpIu8OrRulDyYT+0am7kwWD5CgzIDoI3RgVsyY4S8mjDbHvNfgi3iix kw9v7umCrUokg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id 2Gkb1t0033KdFy101Gkbie; Fri, 03 Jun 2016 16:44:35 +0000 To: "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF0EF84@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Fri, 3 Jun 2016 12:44:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0EF84@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:44:38 -0000 On 6/3/16 11:45 AM, Drage, Keith (Nokia - GB) wrote: > I don't think there is anything such as a benign message in SIP. Point taken. But some can be used in ways that are close to benign. For instance, an UPDATE without an offer is mostly benign. (It can have an effect on session timers, so that needs to be dealt with.) And of course it is possible to define an INFO package that is benign. > All the methods are there for a defined purpose and carry semantics. > > So I don't think attaching this to another message is appropriate, except for the proper use of that message, i.e. INFO to carry an INFO package, SUBSCRIBE/NOTIFY to carry an event package and so on. Note that I agree with you in that I don't think this is the best answer. I prefer using an INFO package in a straightforward way. Thanks, Paul > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 03 June 2016 16:11 > To: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > My preferred approach to this was, after the completion of the initial INVITE, to carry the data in real INFO package bodies, using INFO as designed. I was ok with using additional-data call-info with a referenced body part to convey initial info in the INVITE. That *might* mean that some information might need to have two different representations - one via call-info and one via INFO. But some careful redesign could probably avoid the duplication. > > In passing I mentioned that body parts *can* be attached to pretty much any message. So another way to do what was proposed would be to use additional-data call-info for all, and find some message to piggyback on when there is a need to send something. This could be another message that was going anyway. Or one could find a benign message to send, simply as a vehicle to attach the call-info. This could be a reINVITE or UPDATE, or it could even be an INFO. > > To use INFO that way there would need to be some validly constructed INFO to send, and then the call-info and its additional-data body part attached to it. Somebody suggested defining an INFO package that has no body. (I was a bit dubious of that. Alternatively one could define a very tiny package body part of no significance.) > > I think such an approach is *technically* valid. But I find it quite a hack. I think using INFO with a new package that conveys the required data to be a much cleaner, more elegant, approach. > > Thanks, > Paul > > On 6/3/16 2:32 AM, Christer Holmberg wrote: >> Hi, >> >>>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>>>> Robert Sparks, and came to the conclusion that the draft should be >>>>> modified slightly so that the reply to a mid-call request for an >>>>>> updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>>>> message, and that for consistency, the INFO package registration >>>>> will say that no body type is associated with it, and it is >>>>> restricted to be used >only when emergency call data is being sent >>>>> using the Call-Info header field mechanism per additional-data. >>>> >>>> I am not sure I understand. The main purpose of the INFO package is >>>> for carrying ecall information, and that ecall information is >>>> carried as a message body, so how can one claim that the message >>>> body is not associated with the INFO package??? >>> >>> As I understand it after the discussions with Paul and Robert, the >>> INFO package registration provides a way to authorize sending body >>> parts that are associated with the INFO package, >> >> Correct. >> >> >>> but that means that >>> the draft has two ways of authorizing sending the same body parts: >>> the base way from additional-data / Call-Info, and the INFO package >>> registration. >> >> That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO >> package mechanism. >> >> >>> So, this is a very minor change that means that the authorization to >>> send body parts is always per additional-data (using Call-Info), and >>> the INFO package registration says that INFO can be used to send data >>> per additional-data. >> >> Again, that is wrong. Information in INFO must be carried using the >> INFO package mechanism. >> >> Note, though, that I am only talking about INFO. How you carry >> information in e.g. INVITE is a separate issue. >> >> >>>> If the INFO package is supposed to be able to carry additional data >>>> you need to fix draft-additional-data instead, and allow the >>>> information to be associated with an INFO package. >>> >>> Only the ecall draft (and by extension car-crash) needs to use INFO. >> >> That makes me even more confused why you would want to use something >> else than an INFO package© >> >> >>>>> The result is that the draft will change so that all body parts are >>>>> sent per the additional-data Call-Info header field mechanism, and >>>>> if the PSAP sends a mid-call request for updated crash data, the >>>>> vehicle >sends a response message to that INFO and a new INFO >>>>> request message containing the data (simultaneously). >>>>> >>>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >>>>> preference by several representatives that when there is a mid-call >>>>> request for an updated MSD, the updated MSD is sent in its own >>>>>> INFO rather than the response to the requesting INFO, so this is >>>>> in alignment with the change the authors agreed with neutral SIP >>>>> experts. >>>> >>>> Note that this is related to the issue raised in ECRIT earlier, >>>> that you cannot not send *ANY* INFO package related information in >>>> an INFO response, as per RFC 6086. >>> >>> Yes, and the draft currently says that the info that is sent is not >>> INFO package related, but additional-data related, however, the >>> change will be that the data will be sent in a new INFO message, >>> which is exactly what you have been asking for. >> >> And I appreciate that :) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Jun 3 09:46:16 2016 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 3B5D112D727 for ; Fri, 3 Jun 2016 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xAjWppcTCFT for ; Fri, 3 Jun 2016 09:46:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5524212D722 for ; Fri, 3 Jun 2016 09:45:17 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 768067838AF89; Fri, 3 Jun 2016 16:45:12 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53GjEsP003799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 16:45:14 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53GjDNi031783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 18:45:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 18:45:14 +0200 From: "Drage, Keith (Nokia - GB)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABW0UVwAACHd1A= Date: Fri, 3 Jun 2016 16:45:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0F051@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.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF0F051FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:46:16 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF0F051FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can we see some response to the comments being made first. This is a WG document, and is meant to reflect the consensus of the working= group, and not the authors thoughts and considerations. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 03 June 2016 17:41 To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Given a variety of factors, including individuals' availability, the chairs= have decided to Not schedule an interim meeting at this time. We look for= ward to seeing continued list discussion in order to work through the curre= nt issues, and it seems like progress is being made. We also look forward = to getting an updated draft soon, so that folks can see the proposed text c= hanges being discussed. Roger Marshall & Marc Linsner ECRIT Chairs From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, June 01, 2016 4:04 PM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_949EF20990823C4C85C18D59AA11AD8BADF0F051FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can we see some respon= se to the comments being made first.

 

This is a WG document,= and is meant to reflect the consensus of the working group, and not the au= thors thoughts and considerations.

 

Keith

 

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT Interim meeting - June
<= /p>

 

Given a variety of fac= tors, including individuals’ availability, the chairs have decided to= Not schedule an interim meeting at this time.  We look forward to see= ing continued list discussion in order to work through the current issues, and it seems like progress is being made. = ; We also look forward to getting an updated draft soon, so that folks can = see the proposed text changes being discussed. 

 

Roger Marshall & M= arc Linsner

ECRIT Chairs

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

NOTICE TO RECIPIENT: This em= ail, including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. export= laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email= shall create any legal binding agreement between the parties unless expres= sly stated herein and provided by an authorized representative of Comtech T= elecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any= dissemination, distribution, or use of the contents of this message is str= ictly prohibited. If you received this message in error, please notify us i= mmediately by return email and permanently delete all copies of the original email and any attached documentation fro= m any computer or other media.

--_000_949EF20990823C4C85C18D59AA11AD8BADF0F051FR712WXCHMBA11z_-- From nobody Fri Jun 3 09:52:25 2016 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 6385D12D731 for ; Fri, 3 Jun 2016 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeT1GDb6nyzw for ; Fri, 3 Jun 2016 09:52:20 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EC412D712 for ; Fri, 3 Jun 2016 09:52:20 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id u53GqEfo007777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 09:52:15 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.16]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Fri, 3 Jun 2016 09:52:14 -0700 From: Roger Marshall To: "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABW0UVwAACHd1AAABvUwA== Date: Fri, 3 Jun 2016 16:52:14 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4DBDSEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:52:23 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4DBDSEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith: I think you mean that you want to see all of your comments addressed ahead = of an updated draft, right? I see comments being made and some responses. If you have comments that you believe haven't been addressed as part of the= list discussions, resend them. Be sure to offer proposed text to what you= believe may be deficiencies in the current draft. -roger. From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com] Sent: Friday, June 03, 2016 9:45 AM To: Roger Marshall; ecrit@ietf.org Subject: RE: ECRIT Interim meeting - June Can we see some response to the comments being made first. This is a WG document, and is meant to reflect the consensus of the working= group, and not the authors thoughts and considerations. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 03 June 2016 17:41 To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Given a variety of factors, including individuals' availability, the chairs= have decided to Not schedule an interim meeting at this time. We look for= ward to seeing continued list discussion in order to work through the curre= nt issues, and it seems like progress is being made. We also look forward = to getting an updated draft soon, so that folks can see the proposed text c= hanges being discussed. Roger Marshall & Marc Linsner ECRIT Chairs From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, June 01, 2016 4:04 PM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4DBDSEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith:

I think you mean that = you want to see all of your comments addressed ahead of an updated draft, r= ight?  I see comments being made and some responses. 

 

If you have comments t= hat you believe haven’t been addressed as part of the list discussion= s, resend them.  Be sure to offer proposed text to what you believe ma= y be deficiencies in the current draft.

 

-roger.

 

From: Drage, K= eith (Nokia - GB) [mailto:keith.drage@nokia.com]
Sent: Friday, June 03, 2016 9:45 AM
To: Roger Marshall; ecrit@ietf.org
Subject: RE: ECRIT Interim meeting - June

 

Can we see some respon= se to the comments being made first.

 

This is a WG document,= and is meant to reflect the consensus of the working group, and not the au= thors thoughts and considerations.

 

Keith

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; ecrit@ietf.org=
Subject: Re: [Ecrit] ECRIT Interim meeting - June
<= /p>

 

Given a variety of fac= tors, including individuals’ availability, the chairs have decided to= Not schedule an interim meeting at this time.  We look forward to see= ing continued list discussion in order to work through the current issues, and it seems like progress is being made. = ; We also look forward to getting an updated draft soon, so that folks can = see the proposed text changes being discussed. 

 

Roger Marshall & M= arc Linsner

ECRIT Chairs

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

NOTICE TO RECIPIENT: This em= ail, including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. export= laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email= shall create any legal binding agreement between the parties unless expres= sly stated herein and provided by an authorized representative of Comtech T= elecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any= dissemination, distribution, or use of the contents of this message is str= ictly prohibited. If you received this message in error, please notify us i= mmediately by return email and permanently delete all copies of the original email and any attached documentation fro= m any computer or other media.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC398C4DBDSEAEXMB2telecom_-- From nobody Fri Jun 3 10:09:25 2016 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 40C8812D542 for ; Fri, 3 Jun 2016 10:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG4eXRtj08R8 for ; Fri, 3 Jun 2016 10:09:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448EE12D579 for ; Fri, 3 Jun 2016 10:09:18 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 28E05A0B8C94E; Fri, 3 Jun 2016 17:09:13 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53H9FpQ002647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 17:09:16 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u53H9E4B001538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 19:09:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 19:09:14 +0200 From: "Drage, Keith (Nokia - GB)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABW0UVwAACHd1AAABvUwAAAN92w Date: Fri, 3 Jun 2016 17:09:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0F0A6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF0F0A6FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:09:23 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF0F0A6FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you even bothering to read the mailing list - give me an assessment of = the draft editor's response to all comments over the last month! I have seen zero response from the draft editor on any of the comments I ha= ve made. Some of these have been part of existing threads (comments on INFO usage an= d service URN semantics - so please do not forget my comments there), but t= here is two major sets of comments made on 19th May, which follow this mess= age to ensure they are not lost. Regards Keith Set 1 I did another read through of this document last night, and had the followi= ng comments. I have not reviewed the entire document. Note that this does not supercede any of the comments made in the last few = days: 1) s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and while the= re are some similarities, 3GPP emergency call does not fully comply with ei= ther RFC 6443 or RFC 6881. I am also not sure the references are relevant t= o the purpose of the draft in any case. 2) s. 2, 3rd and 4th para: These paragraphs seem to be going beyond docu= ment scope, and into a wish list. I suggest both these paragraphs are delet= ed. 3) s. 3, 4th paragraph: An eCall can be either user-initiated or automatically triggered. Automatically triggered eCalls indicate a car crash or some other serious incident and carry a greater presumption of risk of injury. Manually triggered eCalls might be reports of serious hazards and are likely to require a different response than an automatically triggered eCall. Manually triggered eCalls are also more likely to be false (e.g., accidental) calls and so might be subject to different operational handling by the PSAP. The distinction between seriousness and impact of manual versus automatic i= s highly subjective, and will depend on the underlying philosophy of the ad= ministration in how it handles what it regards as false alerts, which diffe= rs substantially from administration to administration. 4) s. 3, 5th para: As part of this work, the European Telecommunications Standards Institute (ETSI) [SDO-ETSI] has published a Technical Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] that presents findings and recommendations regarding support for eCall in an all-IP environment. This somehow implies that the contents of this document are valid for the i= nterpretation of the draft. Vewry little of the work has migrated into the = stage 1 in 3GPP, and the other groups in 3GPP are working directly from the= stage 1 description, not from the ETSI work. 5) s. 3 last para: A transition period will exist during which time the various entities involved in initiating and handling an eCall might support next- generation eCall, legacy eCall, or both. This transition period might last several years or longer. The issue of migration/co- existence during the transition period is very important but is outside the scope of this document. The ETSI TR "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in Clause 7. I have not found any statements that support the concept of a transition in= any of the documents I have read. The 3GPP stage 1 requires both UEs and P= SAPs to support both data transfer mechanisms. 6) s. 3 general Some statement should be made in this section about the need for the UE and= the PSAP to support both mechanisms within SIP, as required by the stage 1= , as the 3GPP emergency network does not provide any data interworking, onl= y signalling interworking. Interworking SIP to CS domain, any attached body= to a SIP message will be discarded. 7) s. 4 reference to 22.101, and s. 18.1. This document carries no provi= sions needed to implement this document, and therefore it should not be a n= ormative reference. Further the reference should be to release 14 and later= . The latest version of all releases of 3GPP documents are still valid docu= ments for that release. 8) s. 4. Is considerably out of data in regard to the current version of= 22.101. This appears to be a summary of the CS requirements before the IMS= changes were made. 9) s. 6 last para. This document registers new service URN children within the "sos" subservice. These URNs provide the mechanism by which an eCall is identified, and differentiate between manually and automatically triggered eCalls (which can be subject to different treatment, depending on policy). The two service URNs are: urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual The URN does not identify an ecall. It identifies the resource to which the= ecall needs to be directed. To explain further, the sos URN does not ident= ify an emergency call, it identifies the resource needed to answer the emer= gency call, which is why we have a separate Resource-Priority namespace "es= net". 10) s.7 Europe does not use the term ESInet. That term is North America, and possib= ly USA, specific. It might be more appropriate to use terminology from the = ETSI M483 group if this text is needed at all. 11) s.8 In regard to test calls, I think some statement should be made about what t= hey actually test. Using this URN would certainly not test the emergency ca= ll handling capabilities of either the network or the UE. Does it test all = data transfer capabilities (including the CS). Why do we need a URN rather = than just the same number as is used in the CS domain? 12) s.9 Future enhancements are desired to enable the PSAP to send other requests to the vehicle, such as locking or unlocking doors, sounding the horn, flashing the lights, starting a video stream from on-board cameras (such as rear focus or blind-spot), etc. Do you have a reference for this, or is it speculative thinking? I do not think the mechanisms proposed in this draft are suitable for trans= ferring a video stream, so even if provided, are they part of ecall, or jus= t part of the standard emergency call. Maybe the only ecall responsibility = is to indicate the existence of these? I'd note that extending beyond the existing CS domain capability is not req= uired at the moment by the 3GPP stage 1. I think we all acknowledge that al= l and any data available in the car might be candidates for transfer to the= PSAP, but it is not clear whether this is part of ecall, or whether it is = part of the additional media beyond voice already available as part of 3GPP= emergency call. Certainly there is a limit on the amount of data that can = be transferred using the mechanisms currently in this draft, beyond which t= he QoS of the signalling channel will become inappropriate. 13) s.9 & s.13 It is not clear to me which elements correspond to the existing MSD defined= by CEN, and which have been defined over the top. Firstly I think all data= that is defined by CEN should carry an appropriate CEN reference, because = the UE needs to support both, and it should be the same data that is transf= erred in this. That should occur either in one of these sections, or in a n= ew separate section. Further, if information does go over the top of the existing CEN definition= , this needs additional review and possibly postponement to a later version= , as this is not required by the current 3GPP stage 1. 14) s.14.3 A call-back from a PSAP incurs additional risk, since the current mechanisms are not ideal for verifying that such a call is indeed a call-back from a PSAP in response to an emergency call placed by the IVS. See the discussion in Section 11 and the PSAP Callback document [RFC7090]. I do not understand why call-back is being referred to here. Can you explai= n? Set 2 I did a reread of the INFO RFC last night in respect of the above draft, an= d came to the following conclusions. 1) Any usage of the INFO method requires a full Info package definition.= While there are various mentions of legacy usage, the draft is not trying = to follow that direction, and in any case I am not convinced new registrati= ons of relevant usage would be allowed down that route. So if the draft is = to attempt to use the INFO method, it should formally define that method. 2) The INFO RFC lays down clear instructions for the reviewer of the INF= O package definition before it can be registered. In my view the current ec= rit-ecall document would not pass that review. 3) The INFO RFC makes no reference to transfer of data outside of the IN= FO method itself. My understanding is that the negotiation of the Info pack= age within the Info-Package header field set to 'emergencyCallData.eCall' r= elates only to the data transferred in the INFO method using a conformant I= nfo package definition. There therefore needs to be a discussion about what= forms the negotiation mechanism for other information transferred, for exa= mple in the INVITE request, or other methods of the dialog, if such transfe= r is needed, and for it to be clearly documented. 4) As indicated in 3), the INFO RFC does not expect data outside the Inf= o package itself, and therefore nothing is stated there about the correlati= on of data between an application tagging things onto the methods of the di= alog, and the application using the Info package. 5) The INFO RFC allows for multiple Info packages to be used on the same= dialog. There needs to be careful review to ensure that this capability is= not compromised either in regard to the existing Info packages, or to new = ones, particularly in regard to the assumed correlation between data in the= Info package, and data transferred elsewhere in the dialog. I'd note that = the draft would appear to sanction the inclusion of data in INFO methods be= longing to entirely unrelated Info packages. I would note that I am beginning to question whether there needs to be any = transfer of data in the INVITE request. Transfer only within the INFO packa= ge after the response to the INVITE request is exchanged would still meet t= he 3GPP stage 1 requirements (see 22.101 release 14), and the whole documen= t would be significantly simpler. None of the contents of the MSD is used f= or routeing the emergency call. This is without going into discussion about= whether transfer using the signalling bearer, or some bearer negotiated us= ing the SDP, is more appropriate. From: Roger Marshall [mailto:Roger.Marshall@comtechtel.com] Sent: 03 June 2016 17:52 To: Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: RE: ECRIT Interim meeting - June Keith: I think you mean that you want to see all of your comments addressed ahead = of an updated draft, right? I see comments being made and some responses. If you have comments that you believe haven't been addressed as part of the= list discussions, resend them. Be sure to offer proposed text to what you= believe may be deficiencies in the current draft. -roger. From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com] Sent: Friday, June 03, 2016 9:45 AM To: Roger Marshall; ecrit@ietf.org Subject: RE: ECRIT Interim meeting - June Can we see some response to the comments being made first. This is a WG document, and is meant to reflect the consensus of the working= group, and not the authors thoughts and considerations. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 03 June 2016 17:41 To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Given a variety of factors, including individuals' availability, the chairs= have decided to Not schedule an interim meeting at this time. We look for= ward to seeing continued list discussion in order to work through the curre= nt issues, and it seems like progress is being made. We also look forward = to getting an updated draft soon, so that folks can see the proposed text c= hanges being discussed. Roger Marshall & Marc Linsner ECRIT Chairs From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, June 01, 2016 4:04 PM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_949EF20990823C4C85C18D59AA11AD8BADF0F0A6FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are you even bothering= to read the mailing list – give me an assessment of the draft editor= ’s response to all comments over the last month!

 

I have seen zero respo= nse from the draft editor on any of the comments I have made.

 

Some of these have bee= n part of existing threads (comments on INFO usage and service URN semantic= s – so please do not forget my comments there), but there is two majo= r sets of comments made on 19th May, which follow this message to ensure they are not lost.

 

Regards

 

Keith

 

Set 1

 

I did another read through of this document last = night, and had the following comments. I have not reviewed the entire docum= ent.

 

Note that this does not supercede any of the comm= ents made in the last few days:

 

1)    s. 2, 1st para: ecall in 3GP= P is a 3GPP emergency call, and while there are some similarities, 3GPP eme= rgency call does not fully comply with either RFC 6443 or RFC 6881. I am al= so not sure the references are relevant to the purpose of the draft in any case.

 

2)    s. 2, 3rd and 4th para: Thes= e paragraphs seem to be going beyond document scope, and into a wish list. = I suggest both these paragraphs are deleted.

 

3)    s. 3, 4th paragraph:

 

   An eCall can be either user-initiate= d or automatically triggered.

   Automatically triggered eCalls indic= ate a car crash or some other

   serious incident and carry a greater= presumption of risk of injury.

   Manually triggered eCalls might be r= eports of serious hazards and are

   likely to require a different respon= se than an automatically

   triggered eCall.  Manually trig= gered eCalls are also more likely to

   be false (e.g., accidental) calls an= d so might be subject to

   different operational handling by th= e PSAP.

 

The distinction between seriousness and impact of= manual versus automatic is highly subjective, and will depend on the under= lying philosophy of the administration in how it handles what it regards as= false alerts, which differs substantially from administration to administration.

 

4)    s. 3, 5th para:

 

   As part of this work, the European T= elecommunications

   Standards Institute (ETSI) [SDO-ETSI= ] has published a Technical

   Report titled "Mobile Standards= Group (MSG); eCall for VoIP" [MSG_TR]

   that presents findings and recommend= ations regarding support for

   eCall in an all-IP environment.=

 

This somehow implies that the contents of this do= cument are valid for the interpretation of the draft. Vewry little of the w= ork has migrated into the stage 1 in 3GPP, and the other groups in 3GPP are= working directly from the stage 1 description, not from the ETSI work.

 

5)    s. 3 last para:

 

   A transition period will exist durin= g which time the various entities

   involved in initiating and handling = an eCall might support next-

   generation eCall, legacy eCall, or b= oth.  This transition period

   might last several years or longer.&= nbsp; The issue of migration/co-

   existence during the transition peri= od is very important but is

   outside the scope of this document.&= nbsp; The ETSI TR "Mobile Standards

   Group (MSG); eCall for VoIP" [M= SG_TR] discusses these issues in

   Clause 7.

 

I have not found any statements that support the = concept of a transition in any of the documents I have read. The 3GPP stage= 1 requires both UEs and PSAPs to support both data transfer mechanisms.

 

6)    s. 3 general

 

Some statement should be made in this section abo= ut the need for the UE and the PSAP to support both mechanisms within SIP, = as required by the stage 1, as the 3GPP emergency network does not provide = any data interworking, only signalling interworking. Interworking SIP to CS domain, any attached body to a SIP me= ssage will be discarded.

 

7)    s. 4 reference to 22.101, an= d s. 18.1. This document carries no provisions needed to implement this doc= ument, and therefore it should not be a normative reference. Further the re= ference should be to release 14 and later. The latest version of all releases of 3GPP documents are still valid documents for th= at release.

 

8)    s. 4. Is considerably out of= data in regard to the current version of 22.101. This appears to be a summ= ary of the CS requirements before the IMS changes were made.

 

9)    s. 6 last para.

 

   This document registers new service = URN children within the "sos"

   subservice.  These URNs provide= the mechanism by which an eCall is

   identified, and differentiate betwee= n manually and automatically

   triggered eCalls (which can be subje= ct to different treatment,

   depending on policy).  The two = service URNs are:

   urn:service:sos.ecall.automatic and = urn:service:sos.ecall.manual

 

The URN does not identify an ecall. It identifies= the resource to which the ecall needs to be directed. To explain further, = the sos URN does not identify an emergency call, it identifies the resource= needed to answer the emergency call, which is why we have a separate Resource-Priority namespace "esnet&qu= ot;.

 

10)   s.7  

 

Europe does not use the term ESInet. That term is= North America, and possibly USA, specific. It might be more appropriate to= use terminology from the ETSI M483 group if this text is needed at all.

 

11)   s.8

 

In regard to test calls, I think some statement s= hould be made about what they actually test. Using this URN would certainly= not test the emergency call handling capabilities of either the network or= the UE. Does it test all data transfer capabilities (including the CS). Why do we need a URN rather than just the= same number as is used in the CS domain?

 

12)   s.9

 

   Future enhancements are desired to e= nable the PSAP to send other

   requests to the vehicle, such as loc= king or unlocking doors, sounding

   the horn, flashing the lights, start= ing a video stream from on-board

   cameras (such as rear focus or blind= -spot), etc.

 

Do you have a reference for this, or is it specul= ative thinking?

 

I do not think the mechanisms proposed in this dr= aft are suitable for transferring a video stream, so even if provided, are = they part of ecall, or just part of the standard emergency call. Maybe the = only ecall responsibility is to indicate the existence of these?

 

I'd note that extending beyond the existing CS do= main capability is not required at the moment by the 3GPP stage 1. I think = we all acknowledge that all and any data available in the car might be cand= idates for transfer to the PSAP, but it is not clear whether this is part of ecall, or whether it is part of th= e additional media beyond voice already available as part of 3GPP emergency= call. Certainly there is a limit on the amount of data that can be transfe= rred using the mechanisms currently in this draft, beyond which the QoS of the signalling channel will become = inappropriate.

 

13)   s.9 & s.13

 

It is not clear to me which elements correspond t= o the existing MSD defined by CEN, and which have been defined over the top= . Firstly I think all data that is defined by CEN should carry an appropria= te CEN reference, because the UE needs to support both, and it should be the same data that is transferred in thi= s. That should occur either in one of these sections, or in a new separate = section.

 

Further, if information does go over the top of t= he existing CEN definition, this needs additional review and possibly postp= onement to a later version, as this is not required by the current 3GPP sta= ge 1.

 

14)   s.14.3

 

         = A call-back from a PSAP incurs additional risk,

         = since the current mechanisms are not ideal for verifying that

         = such a call is indeed a call-back from a PSAP in response to an<= /p>

         = emergency call placed by the IVS.  See the discussion in

         = Section 11 and the PSAP Callback document [RFC7090].

 

I do not understand why call-back is being referr= ed to here. Can you explain?

 

Set 2

 

I did a reread of the INFO RFC last night in resp= ect of the above draft, and came to the following conclusions.

 

1)    Any usage of the INFO method= requires a full Info package definition. While there are various mentions = of legacy usage, the draft is not trying to follow that direction, and in a= ny case I am not convinced new registrations of relevant usage would be allowed down that route. So if the draft is to attempt to u= se the INFO method, it should formally define that method.

 

2)    The INFO RFC lays down clear= instructions for the reviewer of the INFO package definition before it can= be registered. In my view the current ecrit-ecall document would not pass = that review.

 

3)    The INFO RFC makes no refere= nce to transfer of data outside of the INFO method itself. My understanding= is that the negotiation of the Info package within the Info-Package header= field set to 'emergencyCallData.eCall' relates only to the data transferred in the INFO method using a conformant Info package= definition. There therefore needs to be a discussion about what forms the = negotiation mechanism for other information transferred, for example in the= INVITE request, or other methods of the dialog, if such transfer is needed, and for it to be clearly docume= nted.

 

4)    As indicated in 3), the INFO= RFC does not expect data outside the Info package itself, and therefore no= thing is stated there about the correlation of data between an application = tagging things onto the methods of the dialog, and the application using the Info package.

 

5)    The INFO RFC allows for mult= iple Info packages to be used on the same dialog. There needs to be careful= review to ensure that this capability is not compromised either in regard = to the existing Info packages, or to new ones, particularly in regard to the assumed correlation between data in the Info package, and= data transferred elsewhere in the dialog. I'd note that the draft would ap= pear to sanction the inclusion of data in INFO methods belonging to entirel= y unrelated Info packages.

 

I would note that I am beginning to question whether= there needs to be any transfer of data in the INVITE request. Transfer onl= y within the INFO package after the response to the INVITE request is excha= nged would still meet the 3GPP stage 1 requirements (see 22.101 release 14), and the whole document would be si= gnificantly simpler. None of the contents of the MSD is used for routeing t= he emergency call. This is without going into discussion about whether tran= sfer using the signalling bearer, or some bearer negotiated using the SDP, is more appropriate.

 

 

From: Roger Ma= rshall [mailto:Roger.Marshall@comtechtel.com]
Sent: 03 June 2016 17:52
To: Drage, Keith (Nokia - GB); ecrit@ietf.org
Subject: RE: ECRIT Interim meeting - June

 

Keith:

I think you mean that = you want to see all of your comments addressed ahead of an updated draft, r= ight?  I see comments being made and some responses. 

 

If you have comments t= hat you believe haven’t been addressed as part of the list discussion= s, resend them.  Be sure to offer proposed text to what you believe ma= y be deficiencies in the current draft.

 

-roger.

 

From: Drage, K= eith (Nokia - GB) [mailto:keith.dr= age@nokia.com]
Sent: Friday, June 03, 2016 9:45 AM
To: Roger Marshall; ecrit@ietf.org=
Subject: RE: ECRIT Interim meeting - June

 

Can we see some respon= se to the comments being made first.

 

This is a WG document,= and is meant to reflect the consensus of the working group, and not the au= thors thoughts and considerations.

 

Keith

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; ecrit@ietf.org=
Subject: Re: [Ecrit] ECRIT Interim meeting - June
<= /p>

 

Given a variety of fac= tors, including individuals’ availability, the chairs have decided to= Not schedule an interim meeting at this time.  We look forward to see= ing continued list discussion in order to work through the current issues, and it seems like progress is being made. = ; We also look forward to getting an updated draft soon, so that folks can = see the proposed text changes being discussed. 

 

Roger Marshall & M= arc Linsner

ECRIT Chairs

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: ecrit@ietf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure out how it can addres= s some of the raised issues in order to make progress on draft-ietf-ecrit-e= call-07.

 

We’ve set up a doodle poll at the following li= nk for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available times to discuss.&nb= sp; Bridge information will follow, once we have a timeslot identified.

 

 

Roger Marshall & Marc Linsner

ECRIT Chairs

 

 

NOTICE TO RECIPIENT: This em= ail, including attachments, may contain information which is confidential, = proprietary, attorney-client privileged and/or controlled under U.S. export= laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email= shall create any legal binding agreement between the parties unless expres= sly stated herein and provided by an authorized representative of Comtech T= elecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any= dissemination, distribution, or use of the contents of this message is str= ictly prohibited. If you received this message in error, please notify us i= mmediately by return email and permanently delete all copies of the original email and any attached documentation fro= m any computer or other media.

--_000_949EF20990823C4C85C18D59AA11AD8BADF0F0A6FR712WXCHMBA11z_-- From nobody Fri Jun 3 10:12:31 2016 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 DDE8412D752 for ; Fri, 3 Jun 2016 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo-Fha5RDYxG for ; Fri, 3 Jun 2016 10:12:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE0812D747 for ; Fri, 3 Jun 2016 10:12:21 -0700 (PDT) Received: from BL2PR17MB0852.namprd17.prod.outlook.com (10.167.119.14) by BL2PR17MB0849.namprd17.prod.outlook.com (10.167.119.11) with Microsoft SMTP Server (TLS) id 15.1.506.9; Fri, 3 Jun 2016 17:11:59 +0000 Received: from BL2PR17MB0852.namprd17.prod.outlook.com ([10.167.119.14]) by BL2PR17MB0852.namprd17.prod.outlook.com ([10.167.119.14]) with mapi id 15.01.0506.013; Fri, 3 Jun 2016 17:11:59 +0000 From: Dan Banks To: Philip Reichl , "ecrit@ietf.org" Thread-Topic: [Ecrit] Additional Data XSD Issues Thread-Index: AQHRtsXt/binYY7o90mwYb9YI7HyO5/X6KvQ Date: Fri, 3 Jun 2016 17:11:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: moducom.com; dkim=none (message not signed) header.d=none;moducom.com; dmarc=none action=none header.from=ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: ae1d73b4-e02c-42c0-e3ed-08d38bd22cbd x-microsoft-exchange-diagnostics: 1; BL2PR17MB0849; 5:7PP+alF2uhL/Xj0nqmZO3GgT72TTzuqCWD8j2Ln+NVfgmLc5YdH7nevhldREQ23SxLGhh5szsRFRvCCf94FkQzTOV+MA02z4QtdYYej6CnE0sNlCna+i6DR/zsQVO0XVw4IN/Xhz8Q8bkv7E26iuNw==; 24:AEk/bFrQB/Evv7Hfcio9Z4abrtOjcSq2skMYpEyxKjVxzrhuTpZUmyhIUVVgOEzwQ3fXJ9beCzqYW/5Fu5RzuEeK7X7zzloUKX2+jzn9Hi4=; 7:Z/ItsP9JfTMaVbqzMyNFjC9XM8ZpAaURmS3EMWFBaNPdUmOxXR3RzFI3XIMbffdJF+MhqQ2Tw9dT6vb7O54zBKMx+HuTXF2JIcsEfRhBcf9BWgYkgmk+3SHYPXnkz76GqsHmwD83EDNBNNF8ynjebPphkzlMdv4qtqDcSHUUqqi3jJc6ZO8H3KgR3ebxvtebWdTfFvp7KT+vsST3Psl39SJd2DyChi+ocaTrRHDFkDU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR17MB0849; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BL2PR17MB0849; BCL:0; PCL:0; RULEID:; SRVR:BL2PR17MB0849; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51444003)(38414003)(377454003)(11100500001)(86362001)(16236675004)(189998001)(5002640100001)(5008740100001)(33656002)(5001770100001)(87936001)(80792005)(19625215002)(122556002)(107886002)(5004730100002)(99286002)(8676002)(81166006)(74316001)(8936002)(19580405001)(5003600100002)(2906002)(10400500002)(54356999)(76176999)(2900100001)(3846002)(76576001)(3280700002)(50986999)(92566002)(5890100001)(586003)(9686002)(77096005)(19300405004)(19617315012)(2950100001)(15975445007)(2501003)(102836003)(3660700001)(66066001)(6116002)(19580395003)(790700001)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR17MB0849; H:BL2PR17MB0852.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR17MB08522DA9DA3F58B2515EA5B5A7590BL2PR17MB0852namp_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 17:11:59.6125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR17MB0849 Archived-At: Subject: Re: [Ecrit] Additional Data XSD Issues X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:12:30 -0000 --_000_BL2PR17MB08522DA9DA3F58B2515EA5B5A7590BL2PR17MB0852namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmV2aWV3aW5nIHlvdXIgY29uY2VybnMgYW5kIHJlY29tbWVuZGF0aW9ucywgaGVyZSBhcmUgbXkg dGhvdWdodHM6DQoNCjIg4oCTIHJlZ2FyZGluZyB0aGUgdXNlIG9mIGNvbXBsZXhDb250ZW50IGRl Y2xhcmF0aW9ucywgYWZ0ZXIgcmV2aWV3aW5nIHNlY3Rpb24gMi41LjMgb2YgaHR0cHM6Ly93d3cu dzMub3JnL1RSL3htbHNjaGVtYS0wLyBhbmQgYSBmZXcgb3RoZXIgZXhhbXBsZXMgb25saW5lLCBJ IHRoaW5rIGRlY2xhcmluZyBjb21wbGV4Q29udGVudCB3aXRoIGFuIGFueVR5cGUgcmVzdHJpY3Rp b24gaXMgYWN0dWFsbHkgY29ycmVjdCwgYW5kIHRoYXQgeW91ciByZWNvbW1lbmRlZCBjaGFuZ2Vz IGFyZSBhbiBlcXVpdmFsZW50IOKAnHNob3J0aGFuZOKAnSByZXByZXNlbnRhdGlvbiB0aGF0IGlz IGFsc28gYWNjZXB0YWJsZSAoYW5kIGVhc2llciB0byByZWFkKS4gIEnigJltIGluIGZhdm9yIG9m IG1ha2luZyB0aGluZ3MgZWFzaWVyIHRvIHJlYWQuDQoNClJlZ2FyZGluZyBleHRlbnNpYmlsaXR5 IG9mIHhDYXJkLCBpdCBkb2VzbuKAmXQgbG9vayB0byBtZSBsaWtlIHRoZSBzY2hlbWEgaW4gUkZD IDYzNTEgYWNjb21tb2RhdGVzIGl0LCBhbHRob3VnaCBzZWN0aW9uIDUuMSBpcyB2ZXJ5IGNsZWFy IHRoYXQgZXh0ZW5zaWJpbGl0eSB3YXMgaW50ZW5kZWQuICBQZXJoYXBzIHRoaXMgc2hvdWxkIGJl IHJlcG9ydGVkIGFzIGFuIGVycmF0YSBvbiA2MzUxLiAgV2UgaGFkIGEgc2ltaWxhciBkaXNjdXNz aW9uIHJlZ2FyZGluZyB0aGUgZXh0ZW5zaWJpbGl0eSBvZiBhIHR5cGUgcGFyYW1ldGVyLCB3aGVy ZSBhbiBlcnJhdGEgd2FzIGFscmVhZHkgcmVwb3J0ZWQuICBUaGlzIHNwYXduZWQgYSBiaWcgZGlz Y3Vzc2lvbiBhYm91dCB3aGF0IHdlIHNob3VsZCBvciBzaG91bGQgbm90IGNoYW5nZS4gIEl0IGFw cGVhcnMgdG8gbWUgdGhhdCB0aGUgaW50ZW5kZWQgZXh0ZW5zaWJpbGl0eSBvZiB2Q2FyZHMgaXMg YnJva2VuIGluIHRoZSA2MzUxIHNjaGVtYSwgYW5kIGlzIHN0aWxsIGJyb2tlbiAoYXQgbXVsdGlw bGUgbGV2ZWxzKSBpbiB0aGUgc2NoZW1hIGluIHRoZSBhZGRpdGlvbmFsIGRhdGEgZHJhZnQuICBJ IGRvbuKAmXQga25vdyB3aGF0IHRvIGRvIGFib3V0IHRoYXQsIGJ1dCBJIGFncmVlIHRoYXQgYW4g eHM6YW55IGVsZW1lbnQgcHJvYmFibHkgYmVsb25ncyBhcyBvbmUgb2YgdGhlIHJlcGVhdGFibGUg Y2hvaWNlcyBpbiB0aGUgdmNhcmRUeXBlIGRlZmluaXRpb24uDQoNCjMuMSDigJMgSSBiZWxpZXZl IHRoZSB1c2Ugb2YgY2hvaWNlIGlzIGNvcnJlY3QuICBBbHRob3VnaCB0aGUgY2hvaWNlIGl0c2Vs ZiBpcyBvbmx5IGxldHMgeW91IHBpY2sgb25lIHByb3BlcnR5LCB5b3UgY2FuIG1ha2UgYXMgbWFu eSBjaG9pY2VzIChhbmQgaW4gd2hhdGV2ZXIgb3JkZXIpIHlvdSBsaWtlIGJlY2F1c2UgdGhlIGNo b2ljZSBpcyBkZWNsYXJlZCB3aXRoIG1heE9jY3Vycz0idW5ib3VuZGVkIi4gIEEgc2VxdWVuY2Ug cmVxdWlyZXMgYSBzcGVjaWZpYyBvcmRlciwgd2hpY2ggSSBiZWxpZXZlIGlzIGluY29tcGF0aWJs ZSB3aXRoIHRoZSBpbnRlbnQgYW5kIHNjaGVtYXMgb2YgeENhcmQvdkNhcmQuDQoNCjMuMiDigJMg QXMgZmFyIGFzIGNhcmRpbmFsaXR5LCBJIHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIChpbiB0aGVv cnkpIHBvc3NpYmxlIHRvIHJlcHJlc2VudCBpbiB0aGUgc2NoZW1hLCBidXQgaXQgbWlnaHQgZ2V0 IHVnbHkuICBJIHNlZSB0aGF0IGFzIGFuIHVubmVjZXNzYXJ5IGNvbXBsaWNhdGlvbiB0aGF0IGdv ZXMgYmV5b25kIHRoZSBzY2hlbWEgaW4gUkZDIDYzNTEsIGFuZCBJIHRoaW5rIHdlIHNob3VsZCBh dm9pZCBhdHRlbXB0aW5nIHRvIHJlcHJlc2VudCBpdCBpbiB0aGUgYWRkaXRpb25hbCBkYXRhIHZl cnNpb24uDQoNCjMuMyDigJMgSSBiZWxpZXZlIHlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSA2MzUx IHNjaGVtYSBkb2VzIG5vdCBtYXRjaCA2MzUwIGRlZmluaXRpb24sIGFuZCB0aGUg4oCYKuKAmSBz aG91bGQgbm90IGJlIHRoZXJlLiAgSSB0aGluayB0aGUgZXhpc3RpbmcgZGVmaW5pdGlvbiBpbiB0 aGUgYWRkaXRpb25hbCBkYXRhIGRyYWZ0IGhhcyB0aGUgZXF1aXZhbGVudCBwcm9ibGVtIGJ5IGFs bG93aW5nICgwIHRvIHVuYm91bmRlZCkuICBUaGUgd2F5IHRoYXQgaXQgaW5jbHVkZXMgbXVsdGlw bGUgaW5kaXZpZHVhbCBzaW1wbGVUeXBlIGRlZmluaXRpb25zIGluIHRoZSB1bmlvbiBpbnN0ZWFk IG9mIGp1c3QgZW51bWVyYXRpbmcgYWxsIG9mIHRoZSBrbm93biB0b2tlbnMgc2VlbXMgc3RyYW5n ZSB0byBtZSwgYnV0IG5vdCBuZWNlc3NhcmlseSBpbmNvcnJlY3QuICBJIHRoaW5rIHlvdXIgc3Vn Z2VzdGlvbiBtaWdodCBiZSB0ZWNobmljYWxseSBvayAoSeKAmW0gbm90IHN1cmUgdGhlIHNlcXVl bmNlIGlzIG5lZWRlZCksIGJ1dCBJIHRoaW5rIGl0IGFjdHVhbGx5IG9ic2N1cmVzIHRoZSBpbnRl bnQgcmF0aGVyIHRoYW4gY2xhcmlmeWluZy4gIEkgd291bGQgcHJlZmVyIHRvIHN0aWNrIHRvIGEg ZGVmaW5pdGlvbiB0aGF0IG1pcnJvcnMgNjM1MSBhcyBmYWl0aGZ1bGx5IGFzIHBvc3NpYmxlLg0K DQpBbGwgb2YgdGhpcyBjb21lcyB3aXRoIHRoZSB1c3VhbCBjYXZlYXQgdGhhdCBJ4oCZbSBub3Qg YW4gZXhwZXJ0IGluIFhNTCBzY2hlbWFzLCBzbyBJIGNvdWxkIGJlIG1pc3Rha2VuIGFib3V0IGFu eSBvZiB0aGUgYWJvdmUuDQoNCkRhbiBCYW5rcw0KDQoNCkZyb206IEVjcml0IFttYWlsdG86ZWNy aXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxpcCBSZWljaGwNClNlbnQ6IFdl ZG5lc2RheSwgTWF5IDI1LCAyMDE2IDQ6NDIgUE0NClRvOiBlY3JpdEBpZXRmLm9yZw0KU3ViamVj dDogW0Vjcml0XSBBZGRpdGlvbmFsIERhdGEgWFNEIElzc3Vlcw0KDQpMYXRlIGxhc3QgeWVhciBJ IHN0YXJ0ZWQgdXNpbmcgdGhlIHNjaGVtYXMgZnJvbSBkcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9u YWwtZGF0YS0zNyBhbmQgZm91bmQgd2hhdCBJIGJlbGlldmUgdG8gYmUgc29tZSBlcnJvcnMgaW4g dGhlIFhTRCBpbmNsdWRlZCBpbiB0aGF0IGRvY3VtZW50Lg0KDQpJIGNvbW11bmljYXRlZCB0aGlz IGluZm9ybWF0aW9uIGRpcmVjdGx5IHdpdGggdGhlIGF1dGhvcnMgYW5kIGJhc2VkIHVwb24gdGhl IGNvcnJlc3BvbmRlbmNlIEkgcmVjZWl2ZWQgZnJvbSBvbiB0aGUgYXV0aG9ycyBsZWQgbWUgdG8g YmVsaWV2ZSB0aGF0IG15IHJlY29tbWVuZGVkIGNoYW5nZXMgd291bGQgYmUgaW5jbHVkZWQgaW4g dGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQoNCkhvd2V2ZXIsIHdoZW4gdmVyc2lv biAzOCB3YXMgcHVibGlzaGVkIEkgZGlzY292ZXJlZCB0aGF0IGl0IGRpZCBub3QgaW5jbHVkZSBt eSByZWNvbW1lbmRlZCBjaGFuZ2VzLg0KDQpUaGUgYXR0YWNoZWQgUERGIGZpbGUgaW5jbHVkZXMg YSBzdW1tYXJ5IG9mIHRoZSByZWNvbW1lbmRlZCBjaGFuZ2VzIGFsb25nIHdpdGggdGhlIHJlYXNv bmluZyBiZWhpbmQgdGhvc2UgcmVjb21tZW5kYXRpb25zLiBUaGUgYXR0YWNoZWQgWFNEIGZpbGVz IGluY2x1ZGUgdGhlIHJlY29tbWVuZGVkIGNoYW5nZXMsIGluY2x1ZGluZyB0aGUgb25lIGNoYW5n ZSB0aGF0IHdhcyBtYWRlIHRvIHRoZSB2Y2FyZCBzY2hlbWEgaW4gdmVyc2lvbiAzOCBmb3IgdGhl ICJ0ZWwiIGVsZW1lbnQuDQoNCkNhbiBhbnlvbmUgdGVsbCBtZSB3aGF0IGhhcHBlbmVkPw0KDQot LQ0KUGhpbGlwIEguIFJlaWNobA0KTW9kdWxhciBDb21tdW5pY2F0aW9uIFN5c3RlbXMNClRlbDog ODE4LTc2NC0xMzMzIGV4dC4gMzA4DQo= --_000_BL2PR17MB08522DA9DA3F58B2515EA5B5A7590BL2PR17MB0852namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiM0NDU0NkE7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPlJldmlld2luZyB5b3VyIGNvbmNlcm5zIGFu ZCByZWNvbW1lbmRhdGlvbnMsIGhlcmUgYXJlIG15IHRob3VnaHRzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+MiDigJMg cmVnYXJkaW5nIHRoZSB1c2Ugb2YgY29tcGxleENvbnRlbnQgZGVjbGFyYXRpb25zLCBhZnRlciBy ZXZpZXdpbmcgc2VjdGlvbiAyLjUuMyBvZg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cudzMub3JnL1RS L3htbHNjaGVtYS0wLyI+aHR0cHM6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0wLzwvYT4gYW5k IGEgZmV3IG90aGVyIGV4YW1wbGVzIG9ubGluZSwgSSB0aGluayBkZWNsYXJpbmcgY29tcGxleENv bnRlbnQgd2l0aCBhbiBhbnlUeXBlIHJlc3RyaWN0aW9uIGlzIGFjdHVhbGx5IGNvcnJlY3QsIGFu ZCB0aGF0IHlvdXIgcmVjb21tZW5kZWQgY2hhbmdlcyBhcmUgYW4gZXF1aXZhbGVudCDigJxzaG9y dGhhbmTigJ0NCiByZXByZXNlbnRhdGlvbiB0aGF0IGlzIGFsc28gYWNjZXB0YWJsZSAoYW5kIGVh c2llciB0byByZWFkKS4mbmJzcDsgSeKAmW0gaW4gZmF2b3Igb2YgbWFraW5nIHRoaW5ncyBlYXNp ZXIgdG8gcmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM0NDU0NkEiPlJlZ2FyZGluZyBleHRlbnNpYmlsaXR5IG9mIHhDYXJkLCBp dCBkb2VzbuKAmXQgbG9vayB0byBtZSBsaWtlIHRoZSBzY2hlbWEgaW4gUkZDIDYzNTEgYWNjb21t b2RhdGVzIGl0LCBhbHRob3VnaCBzZWN0aW9uIDUuMSBpcyB2ZXJ5IGNsZWFyIHRoYXQgZXh0ZW5z aWJpbGl0eSB3YXMNCiBpbnRlbmRlZC4mbmJzcDsgUGVyaGFwcyB0aGlzIHNob3VsZCBiZSByZXBv cnRlZCBhcyBhbiBlcnJhdGEgb24gNjM1MS4mbmJzcDsgV2UgaGFkIGEgc2ltaWxhciBkaXNjdXNz aW9uIHJlZ2FyZGluZyB0aGUgZXh0ZW5zaWJpbGl0eSBvZiBhIHR5cGUgcGFyYW1ldGVyLCB3aGVy ZSBhbiBlcnJhdGEgd2FzIGFscmVhZHkgcmVwb3J0ZWQuJm5ic3A7IFRoaXMgc3Bhd25lZCBhIGJp ZyBkaXNjdXNzaW9uIGFib3V0IHdoYXQgd2Ugc2hvdWxkIG9yIHNob3VsZCBub3QgY2hhbmdlLiZu YnNwOw0KIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCB0aGUgaW50ZW5kZWQgZXh0ZW5zaWJpbGl0eSBv ZiB2Q2FyZHMgaXMgYnJva2VuIGluIHRoZSA2MzUxIHNjaGVtYSwgYW5kIGlzIHN0aWxsIGJyb2tl biAoYXQgbXVsdGlwbGUgbGV2ZWxzKSBpbiB0aGUgc2NoZW1hIGluIHRoZSBhZGRpdGlvbmFsIGRh dGEgZHJhZnQuJm5ic3A7IEkgZG9u4oCZdCBrbm93IHdoYXQgdG8gZG8gYWJvdXQgdGhhdCwgYnV0 IEkgYWdyZWUgdGhhdCBhbiB4czphbnkgZWxlbWVudCBwcm9iYWJseSBiZWxvbmdzDQogYXMgb25l IG9mIHRoZSByZXBlYXRhYmxlIGNob2ljZXMgaW4gdGhlIHZjYXJkVHlwZSBkZWZpbml0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzQ0NTQ2QSI+My4xIOKAkyBJIGJlbGlldmUgdGhlIHVzZSBvZiBjaG9pY2UgaXMgY29ycmVjdC4m bmJzcDsgQWx0aG91Z2ggdGhlIGNob2ljZSBpdHNlbGYgaXMgb25seSBsZXRzIHlvdSBwaWNrIG9u ZSBwcm9wZXJ0eSwgeW91IGNhbiBtYWtlIGFzIG1hbnkgY2hvaWNlcyAoYW5kIGluIHdoYXRldmVy DQogb3JkZXIpIHlvdSBsaWtlIGJlY2F1c2UgdGhlIGNob2ljZSBpcyBkZWNsYXJlZCB3aXRoIG1h eE9jY3Vycz0mcXVvdDt1bmJvdW5kZWQmcXVvdDsuJm5ic3A7IEEgc2VxdWVuY2UgcmVxdWlyZXMg YSBzcGVjaWZpYyBvcmRlciwgd2hpY2ggSSBiZWxpZXZlIGlzIGluY29tcGF0aWJsZSB3aXRoIHRo ZSBpbnRlbnQgYW5kIHNjaGVtYXMgb2YgeENhcmQvdkNhcmQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjMu MiDigJMgQXMgZmFyIGFzIGNhcmRpbmFsaXR5LCBJIHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlIChp biB0aGVvcnkpIHBvc3NpYmxlIHRvIHJlcHJlc2VudCBpbiB0aGUgc2NoZW1hLCBidXQgaXQgbWln aHQgZ2V0IHVnbHkuJm5ic3A7IEkgc2VlIHRoYXQgYXMgYW4gdW5uZWNlc3NhcnkNCiBjb21wbGlj YXRpb24gdGhhdCBnb2VzIGJleW9uZCB0aGUgc2NoZW1hIGluIFJGQyA2MzUxLCBhbmQgSSB0aGlu ayB3ZSBzaG91bGQgYXZvaWQgYXR0ZW1wdGluZyB0byByZXByZXNlbnQgaXQgaW4gdGhlIGFkZGl0 aW9uYWwgZGF0YSB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+My4zIOKAkyBJIGJlbGlldmUgeW91IGFyZSBj b3JyZWN0IHRoYXQgdGhlIDYzNTEgc2NoZW1hIGRvZXMgbm90IG1hdGNoIDYzNTAgZGVmaW5pdGlv biwgYW5kIHRoZSDigJgq4oCZIHNob3VsZCBub3QgYmUgdGhlcmUuJm5ic3A7IEkgdGhpbmsgdGhl IGV4aXN0aW5nIGRlZmluaXRpb24gaW4gdGhlDQogYWRkaXRpb25hbCBkYXRhIGRyYWZ0IGhhcyB0 aGUgZXF1aXZhbGVudCBwcm9ibGVtIGJ5IGFsbG93aW5nICgwIHRvIHVuYm91bmRlZCkuJm5ic3A7 IFRoZSB3YXkgdGhhdCBpdCBpbmNsdWRlcyBtdWx0aXBsZSBpbmRpdmlkdWFsIHNpbXBsZVR5cGUg ZGVmaW5pdGlvbnMgaW4gdGhlIHVuaW9uIGluc3RlYWQgb2YganVzdCBlbnVtZXJhdGluZyBhbGwg b2YgdGhlIGtub3duIHRva2VucyBzZWVtcyBzdHJhbmdlIHRvIG1lLCBidXQgbm90IG5lY2Vzc2Fy aWx5IGluY29ycmVjdC4mbmJzcDsNCiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiBtaWdodCBiZSB0 ZWNobmljYWxseSBvayAoSeKAmW0gbm90IHN1cmUgdGhlIHNlcXVlbmNlIGlzIG5lZWRlZCksIGJ1 dCBJIHRoaW5rIGl0IGFjdHVhbGx5IG9ic2N1cmVzIHRoZSBpbnRlbnQgcmF0aGVyIHRoYW4gY2xh cmlmeWluZy4mbmJzcDsgSSB3b3VsZCBwcmVmZXIgdG8gc3RpY2sgdG8gYSBkZWZpbml0aW9uIHRo YXQgbWlycm9ycyA2MzUxIGFzIGZhaXRoZnVsbHkgYXMgcG9zc2libGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5BbGwg b2YgdGhpcyBjb21lcyB3aXRoIHRoZSB1c3VhbCBjYXZlYXQgdGhhdCBJ4oCZbSBub3QgYW4gZXhw ZXJ0IGluIFhNTCBzY2hlbWFzLCBzbyBJIGNvdWxkIGJlIG1pc3Rha2VuIGFib3V0IGFueSBvZiB0 aGUgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNDQ1NDZBIj5EYW4gQmFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2 QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFY3Jp dCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBo aWxpcCBSZWljaGw8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgNDo0 MiBQTTxicj4NCjxiPlRvOjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W0Vjcml0XSBBZGRpdGlvbmFsIERhdGEgWFNEIElzc3VlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXRlIGxhc3QgeWVhciBJIHN0YXJ0ZWQgdXNpbmcgdGhl IHNjaGVtYXMgZnJvbSBkcmFmdC1pZXRmLWVjcml0LWFkZGl0aW9uYWwtZGF0YS0zNyBhbmQgZm91 bmQgd2hhdCBJIGJlbGlldmUgdG8gYmUgc29tZSBlcnJvcnMgaW4gdGhlIFhTRCBpbmNsdWRlZCBp biB0aGF0IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGNvbW11bmljYXRlZCB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IHdp dGggdGhlIGF1dGhvcnMgYW5kIGJhc2VkIHVwb24gdGhlIGNvcnJlc3BvbmRlbmNlIEkgcmVjZWl2 ZWQgZnJvbSBvbiB0aGUgYXV0aG9ycyBsZWQgbWUgdG8gYmVsaWV2ZSB0aGF0IG15IHJlY29tbWVu ZGVkIGNoYW5nZXMgd291bGQgYmUgaW5jbHVkZWQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhvd2V2ZXIsIHdoZW4gdmVyc2lvbiAzOCB3YXMgcHVibGlzaGVkIEkgZGlzY292ZXJl ZCB0aGF0IGl0IGRpZCBub3QgaW5jbHVkZSBteSByZWNvbW1lbmRlZCBjaGFuZ2VzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXR0YWNo ZWQgUERGIGZpbGUgaW5jbHVkZXMgYSBzdW1tYXJ5IG9mIHRoZSByZWNvbW1lbmRlZCBjaGFuZ2Vz IGFsb25nIHdpdGggdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhvc2UgcmVjb21tZW5kYXRpb25zLiBU aGUgYXR0YWNoZWQgWFNEIGZpbGVzIGluY2x1ZGUgdGhlIHJlY29tbWVuZGVkIGNoYW5nZXMsIGlu Y2x1ZGluZyB0aGUgb25lIGNoYW5nZSB0aGF0IHdhcyBtYWRlIHRvIHRoZSB2Y2FyZCBzY2hlbWEN CiBpbiB2ZXJzaW9uIDM4IGZvciB0aGUgJnF1b3Q7dGVsJnF1b3Q7IGVsZW1lbnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiBhbnlvbmUg dGVsbCBtZSB3aGF0IGhhcHBlbmVkPzxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QaGlsaXAgSC4gUmVpY2hsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Nb2R1bGFyIENvbW11bmljYXRpb24gU3lzdGVtczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVsOiA4MTgtNzY0LTEzMzMg ZXh0LiAzMDg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL2PR17MB08522DA9DA3F58B2515EA5B5A7590BL2PR17MB0852namp_-- From nobody Fri Jun 3 10:16:49 2016 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 2589612D0C8 for ; Fri, 3 Jun 2016 10:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEBte6t1arTf for ; Fri, 3 Jun 2016 10:16:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBFB12D099 for ; Fri, 3 Jun 2016 10:16:45 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 62371F833EEBC; Fri, 3 Jun 2016 17:16:41 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53HGiS8023375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 17:16:44 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u53HGh1E016164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 19:16:43 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 3 Jun 2016 19:16:43 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAMDD4AAAu0xoAABVRikP//75KA///XPeA= Date: Fri, 3 Jun 2016 17:16:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF0F0C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF0EF84@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.40] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:16:48 -0000 I'm glad you agree we should keep usage of the INFO transaction within what= is defined for INFO packages. In regard to the rest of your mail, I'd note that UPDATE has semantics, whi= ch are to renegotiate session parameters (all of them except Contact, not j= ust the SDP). So sending UPDATE means the endpoints go through all the proc= edures of completing such a renegotiation. Now I agree that the renegotiati= on could be to renegotiate exactly the same parameters, but, a) it is expec= ting the remote side to cooperate and agree the same parameters that it did= before, and b) it involves an extra processing load for all the other para= meters which is unnecessary. Regards Keith -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 03 June 2016 17:45 To: Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June On 6/3/16 11:45 AM, Drage, Keith (Nokia - GB) wrote: > I don't think there is anything such as a benign message in SIP. Point taken. But some can be used in ways that are close to benign. For ins= tance, an UPDATE without an offer is mostly benign. (It can have an effect = on session timers, so that needs to be dealt with.) And of course it is possible to define an INFO package that is benign. > All the methods are there for a defined purpose and carry semantics. > > So I don't think attaching this to another message is appropriate, except= for the proper use of that message, i.e. INFO to carry an INFO package, SU= BSCRIBE/NOTIFY to carry an event package and so on. Note that I agree with you in that I don't think this is the best answer. I= prefer using an INFO package in a straightforward way. Thanks, Paul > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 03 June 2016 16:11 > To: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > My preferred approach to this was, after the completion of the initial IN= VITE, to carry the data in real INFO package bodies, using INFO as designed= . I was ok with using additional-data call-info with a referenced body part= to convey initial info in the INVITE. That *might* mean that some informat= ion might need to have two different representations - one via call-info an= d one via INFO. But some careful redesign could probably avoid the duplicat= ion. > > In passing I mentioned that body parts *can* be attached to pretty much a= ny message. So another way to do what was proposed would be to use addition= al-data call-info for all, and find some message to piggyback on when there= is a need to send something. This could be another message that was going = anyway. Or one could find a benign message to send, simply as a vehicle to = attach the call-info. This could be a reINVITE or UPDATE, or it could even = be an INFO. > > To use INFO that way there would need to be some validly constructed=20 > INFO to send, and then the call-info and its additional-data body part=20 > attached to it. Somebody suggested defining an INFO package that has=20 > no body. (I was a bit dubious of that. Alternatively one could define=20 > a very tiny package body part of no significance.) > > I think such an approach is *technically* valid. But I find it quite a ha= ck. I think using INFO with a new package that conveys the required data to= be a much cleaner, more elegant, approach. > > Thanks, > Paul > > On 6/3/16 2:32 AM, Christer Holmberg wrote: >> Hi, >> >>>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and=20 >>>>> Robert Sparks, and came to the conclusion that the draft should be=20 >>>>> modified slightly so that the reply to a mid-call request for an >>>>>> updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>>>> message, and that for consistency, the INFO package registration=20 >>>>> will say that no body type is associated with it, and it is=20 >>>>> restricted to be used >only when emergency call data is being sent=20 >>>>> using the Call-Info header field mechanism per additional-data. >>>> >>>> I am not sure I understand. The main purpose of the INFO package=20 >>>> is for carrying ecall information, and that ecall information is=20 >>>> carried as a message body, so how can one claim that the message=20 >>>> body is not associated with the INFO package??? >>> >>> As I understand it after the discussions with Paul and Robert, the=20 >>> INFO package registration provides a way to authorize sending body=20 >>> parts that are associated with the INFO package, >> >> Correct. >> >> >>> but that means that >>> the draft has two ways of authorizing sending the same body parts: >>> the base way from additional-data / Call-Info, and the INFO package=20 >>> registration. >> >> That is wrong. RFC 6086 says that any new INFO usage MUST use the=20 >> INFO package mechanism. >> >> >>> So, this is a very minor change that means that the authorization to=20 >>> send body parts is always per additional-data (using Call-Info), and=20 >>> the INFO package registration says that INFO can be used to send=20 >>> data per additional-data. >> >> Again, that is wrong. Information in INFO must be carried using the=20 >> INFO package mechanism. >> >> Note, though, that I am only talking about INFO. How you carry=20 >> information in e.g. INVITE is a separate issue. >> >> >>>> If the INFO package is supposed to be able to carry additional data=20 >>>> you need to fix draft-additional-data instead, and allow the=20 >>>> information to be associated with an INFO package. >>> >>> Only the ecall draft (and by extension car-crash) needs to use INFO. >> >> That makes me even more confused why you would want to use something=20 >> else than an INFO package=A9 >> >> >>>>> The result is that the draft will change so that all body parts=20 >>>>> are sent per the additional-data Call-Info header field mechanism,=20 >>>>> and if the PSAP sends a mid-call request for updated crash data,=20 >>>>> the vehicle >sends a response message to that INFO and a new INFO=20 >>>>> request message containing the data (simultaneously). >>>>> >>>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted=20 >>>>> a preference by several representatives that when there is a=20 >>>>> mid-call request for an updated MSD, the updated MSD is sent in=20 >>>>> its own >>>>>> INFO rather than the response to the requesting INFO, so this is >>>>> in alignment with the change the authors agreed with neutral SIP=20 >>>>> experts. >>>> >>>> Note that this is related to the issue raised in ECRIT earlier,=20 >>>> that you cannot not send *ANY* INFO package related information in=20 >>>> an INFO response, as per RFC 6086. >>> >>> Yes, and the draft currently says that the info that is sent is not=20 >>> INFO package related, but additional-data related, however, the=20 >>> change will be that the data will be sent in a new INFO message,=20 >>> which is exactly what you have been asking for. >> >> And I appreciate that :) >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Jun 3 10:18:53 2016 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 DD63B12D0BF for ; Fri, 3 Jun 2016 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH_VGMFARWjP for ; Fri, 3 Jun 2016 10:18:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098F612D5B4 for ; Fri, 3 Jun 2016 10:18:48 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-7d-5751bbf79bf5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.34.12926.7FBB1575; Fri, 3 Jun 2016 19:18:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 19:18:47 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYAAkvHEAAAimBBAACsEjAAAMDD4AAAu0xoAACGoPQA== Date: Fri, 3 Jun 2016 17:18:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38034E37@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> In-Reply-To: <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7iO733YHhBi+nyVg0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj56J7jAWPdSoOzm5mb2D8qtzFyMkhIWAi 8ffADBYIW0ziwr31bF2MXBxCAkcYJfZ+aWGBcBYzSrz7eJipi5GDg03AQqL7nzZIg4iAt8Sf 39/YQMLCAoYS3yeXQ4SNJPY27GaCsMMkrp28ywhiswioSBx50AoW5xXwldi18ilYXEjgPJPE pQUpIDangIPEou2b2UFsRqB7vp9aA1bPLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWklix /RIjRL2exLNTs1ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn 5aYbGeulFmUmFxfn5+nlpZZsYgRGycEtv1V3MF5+43iIUYCDUYmHN2FNQLgQa2JZcWXuIUYJ DmYlEd552wPDhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBK NTDyK/yx+fDm5Iufgd1PquRLjOtrT/95U92Qv1yXK7/i9Wa9hqMbu7v1AjoWrn5+iPffuuM+ dabhWae4de5M2JGrcHjaJZ/ZFcyqHSs5Tz+Z7p++6jW7VduvvrobSdOdl8n/4q9fd1dbQUY/ 8K3Rc0l5lrUHGJfVsexuvmdxeaPK+sv8gZL7tvkpsRRnJBpqMRcVJwIAfQ3dL44CAAA= Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:18:52 -0000 Hi, >My preferred approach to this was, after the completion of the initial INV= ITE, to carry the data in real INFO package bodies, using INFO as designed.= I was ok with using additional-data call-info with a >referenced body part= to convey initial info in the INVITE. That *might* mean that some informat= ion might need to have two different representations - one via call-info an= d one via INFO. But some >careful redesign could probably avoid the duplica= tion. Yes. >In passing I mentioned that body parts *can* be attached to pretty much an= y message. So another way to do what was proposed would be to use additiona= l-data call-info for all, and find some message >to piggyback on when there= is a need to send something. This could be another message that was going = anyway. Or one could find a benign message to send, simply as a vehicle to = attach the call-info. >This could be a reINVITE or UPDATE, or it could even= be an INFO. > >To use INFO that way there would need to be some validly constructed INFO = to send, and then the call-info and its additional-data body part attached = to it. Somebody suggested defining an INFO >package that has no body. (I wa= s a bit dubious of that. Alternatively one could define a very tiny package= body part of no significance.) So, we would define a "dummy" info package, and whenever we want to send eC= all data we just "happen" to also be sending an INFO associated with the du= mmy package - so we can then piggyback the eCall data into that INFO???=20 *mouth and eyes wide open* I don't find words :) >I think such an approach is *technically* valid. But I find it quite a hac= k. I think using INFO with a new package that conveys the required data to = be a much cleaner, more elegant, approach. Yes. Regards, Christer On 6/3/16 2:32 AM, Christer Holmberg wrote: > Hi, > >>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and=20 >>>> Robert Sparks, and came to the conclusion that the draft should be=20 >>>> modified slightly so that the reply to a mid-call request for an=20 >>>> >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO=20 >>>> message, and that for consistency, the INFO package registration=20 >>>> will say that no body type is associated with it, and it is=20 >>>> restricted to be used >only when emergency call data is being sent=20 >>>> using the Call-Info header field mechanism per additional-data. >>> >>> I am not sure I understand. The main purpose of the INFO package is=20 >>> for carrying ecall information, and that ecall information is=20 >>> carried as a message body, so how can one claim that the message=20 >>> body is not associated with the INFO package??? >> >> As I understand it after the discussions with Paul and Robert, the=20 >> INFO package registration provides a way to authorize sending body=20 >> parts that are associated with the INFO package, > > Correct. > > >> but that means that >> the draft has two ways of authorizing sending the same body parts: >> the base way from additional-data / Call-Info, and the INFO package=20 >> registration. > > That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO=20 > package mechanism. > > >> So, this is a very minor change that means that the authorization to=20 >> send body parts is always per additional-data (using Call-Info), and=20 >> the INFO package registration says that INFO can be used to send data=20 >> per additional-data. > > Again, that is wrong. Information in INFO must be carried using the=20 > INFO package mechanism. > > Note, though, that I am only talking about INFO. How you carry=20 > information in e.g. INVITE is a separate issue. > > >>> If the INFO package is supposed to be able to carry additional data=20 >>> you need to fix draft-additional-data instead, and allow the=20 >>> information to be associated with an INFO package. >> >> Only the ecall draft (and by extension car-crash) needs to use INFO. > > That makes me even more confused why you would want to use something=20 > else than an INFO package=A9 > > >>>> The result is that the draft will change so that all body parts are=20 >>>> sent per the additional-data Call-Info header field mechanism, and=20 >>>> if the PSAP sends a mid-call request for updated crash data, the=20 >>>> vehicle >sends a response message to that INFO and a new INFO=20 >>>> request message containing the data (simultaneously). >>>> >>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a=20 >>>> preference by several representatives that when there is a mid-call=20 >>>> request for an updated MSD, the updated MSD is sent in its own=20 >>>> >INFO rather than the response to the requesting INFO, so this is=20 >>>> in alignment with the change the authors agreed with neutral SIP=20 >>>> experts. >>> >>> Note that this is related to the issue raised in ECRIT earlier,=20 >>> that you cannot not send *ANY* INFO package related information in=20 >>> an INFO response, as per RFC 6086. >> >> Yes, and the draft currently says that the info that is sent is not=20 >> INFO package related, but additional-data related, however, the=20 >> change will be that the data will be sent in a new INFO message,=20 >> which is exactly what you have been asking for. > > And I appreciate that :) > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Jun 3 10:25:51 2016 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 5A7BF12D54C for ; Fri, 3 Jun 2016 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8khcHsjJg0z for ; Fri, 3 Jun 2016 10:25:48 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4477012D5E7 for ; Fri, 3 Jun 2016 10:25:48 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id 8spHbZCOppUrh8sqxbQVsF; Fri, 03 Jun 2016 17:25:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464974747; bh=NxE+olXaoFSjPf9XFaIoF42zgg7qq0GSHoy3s9wuHbM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=tNZcE+tk//ayWGYi55D3nf9/QW1FwZzf9pIJnxGzlV0eBfB91Y4sTtIFuEYdYodl3 Li1OomNgdvVeDuAFuNnA4a/VT/gIpXbD/s/XTADdVtiAKkDjSX4sfQoDDxh6p+bqYq OhvQzrrbvujL/Csy5ZQL4KMX08rLtBVygSHSh/MpFq0QV2OVM6/pdAjgrsiDXC9nRa GgjppB74pFZ6zd8Fny2aLFi/cjdryK8O+TNi6qsZe+II4o6PBJiUrF4NuG9E2B2DxP yB4B2jz01bLu2N67tncvHaOCJclRcvZPqmFzI1WHzkSdBVemWBvN0+iwIXwjbBuFHS cThB18EU0sevA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id 2HRm1t00n3KdFy101HRn7E; Fri, 03 Jun 2016 17:25:47 +0000 To: "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <7753474f-3b67-854c-c383-f072ddeb46fa@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF0EF84@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADF0F0C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <70990718-b40d-bd2b-4cd8-003ce564a7b0@alum.mit.edu> Date: Fri, 3 Jun 2016 13:25:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0F0C2@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:25:50 -0000 On 6/3/16 1:16 PM, Drage, Keith (Nokia - GB) wrote: > I'm glad you agree we should keep usage of the INFO transaction within what is defined for INFO packages. > > In regard to the rest of your mail, I'd note that UPDATE has semantics, which are to renegotiate session parameters (all of them except Contact, not just the SDP). So sending UPDATE means the endpoints go through all the procedures of completing such a renegotiation. Now I agree that the renegotiation could be to renegotiate exactly the same parameters, but, a) it is expecting the remote side to cooperate and agree the same parameters that it did before, and b) it involves an extra processing load for all the other parameters which is unnecessary. I think we largely agree. Perhaps my use of the term "benign" was overreaching. My point is that there are a variety of messages that one could "piggyback" additional data on. Each of them has *some* other consequence, so choosing one to send when you otherwise didn't need to means accepting those consequences. That is also true of using a "dummy" INFO package, though in that case the consequences are well bounded. But it is still a hack. Thanks, Paul > Regards > > Keith > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 03 June 2016 17:45 > To: Drage, Keith (Nokia - GB); ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > On 6/3/16 11:45 AM, Drage, Keith (Nokia - GB) wrote: >> I don't think there is anything such as a benign message in SIP. > > Point taken. But some can be used in ways that are close to benign. For instance, an UPDATE without an offer is mostly benign. (It can have an effect on session timers, so that needs to be dealt with.) > > And of course it is possible to define an INFO package that is benign. > >> All the methods are there for a defined purpose and carry semantics. >> >> So I don't think attaching this to another message is appropriate, except for the proper use of that message, i.e. INFO to carry an INFO package, SUBSCRIBE/NOTIFY to carry an event package and so on. > > Note that I agree with you in that I don't think this is the best answer. I prefer using an INFO package in a straightforward way. > > Thanks, > Paul > >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 03 June 2016 16:11 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT Interim meeting - June >> >> My preferred approach to this was, after the completion of the initial INVITE, to carry the data in real INFO package bodies, using INFO as designed. I was ok with using additional-data call-info with a referenced body part to convey initial info in the INVITE. That *might* mean that some information might need to have two different representations - one via call-info and one via INFO. But some careful redesign could probably avoid the duplication. >> >> In passing I mentioned that body parts *can* be attached to pretty much any message. So another way to do what was proposed would be to use additional-data call-info for all, and find some message to piggyback on when there is a need to send something. This could be another message that was going anyway. Or one could find a benign message to send, simply as a vehicle to attach the call-info. This could be a reINVITE or UPDATE, or it could even be an INFO. >> >> To use INFO that way there would need to be some validly constructed >> INFO to send, and then the call-info and its additional-data body part >> attached to it. Somebody suggested defining an INFO package that has >> no body. (I was a bit dubious of that. Alternatively one could define >> a very tiny package body part of no significance.) >> >> I think such an approach is *technically* valid. But I find it quite a hack. I think using INFO with a new package that conveys the required data to be a much cleaner, more elegant, approach. >> >> Thanks, >> Paul >> >> On 6/3/16 2:32 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>>> A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>>>>> Robert Sparks, and came to the conclusion that the draft should be >>>>>> modified slightly so that the reply to a mid-call request for an >>>>>>> updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>>>>> message, and that for consistency, the INFO package registration >>>>>> will say that no body type is associated with it, and it is >>>>>> restricted to be used >only when emergency call data is being sent >>>>>> using the Call-Info header field mechanism per additional-data. >>>>> >>>>> I am not sure I understand. The main purpose of the INFO package >>>>> is for carrying ecall information, and that ecall information is >>>>> carried as a message body, so how can one claim that the message >>>>> body is not associated with the INFO package??? >>>> >>>> As I understand it after the discussions with Paul and Robert, the >>>> INFO package registration provides a way to authorize sending body >>>> parts that are associated with the INFO package, >>> >>> Correct. >>> >>> >>>> but that means that >>>> the draft has two ways of authorizing sending the same body parts: >>>> the base way from additional-data / Call-Info, and the INFO package >>>> registration. >>> >>> That is wrong. RFC 6086 says that any new INFO usage MUST use the >>> INFO package mechanism. >>> >>> >>>> So, this is a very minor change that means that the authorization to >>>> send body parts is always per additional-data (using Call-Info), and >>>> the INFO package registration says that INFO can be used to send >>>> data per additional-data. >>> >>> Again, that is wrong. Information in INFO must be carried using the >>> INFO package mechanism. >>> >>> Note, though, that I am only talking about INFO. How you carry >>> information in e.g. INVITE is a separate issue. >>> >>> >>>>> If the INFO package is supposed to be able to carry additional data >>>>> you need to fix draft-additional-data instead, and allow the >>>>> information to be associated with an INFO package. >>>> >>>> Only the ecall draft (and by extension car-crash) needs to use INFO. >>> >>> That makes me even more confused why you would want to use something >>> else than an INFO package© >>> >>> >>>>>> The result is that the draft will change so that all body parts >>>>>> are sent per the additional-data Call-Info header field mechanism, >>>>>> and if the PSAP sends a mid-call request for updated crash data, >>>>>> the vehicle >sends a response message to that INFO and a new INFO >>>>>> request message containing the data (simultaneously). >>>>>> >>>>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted >>>>>> a preference by several representatives that when there is a >>>>>> mid-call request for an updated MSD, the updated MSD is sent in >>>>>> its own >>>>>>> INFO rather than the response to the requesting INFO, so this is >>>>>> in alignment with the change the authors agreed with neutral SIP >>>>>> experts. >>>>> >>>>> Note that this is related to the issue raised in ECRIT earlier, >>>>> that you cannot not send *ANY* INFO package related information in >>>>> an INFO response, as per RFC 6086. >>>> >>>> Yes, and the draft currently says that the info that is sent is not >>>> INFO package related, but additional-data related, however, the >>>> change will be that the data will be sent in a new INFO message, >>>> which is exactly what you have been asking for. >>> >>> And I appreciate that :) >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > From nobody Fri Jun 3 10:32:54 2016 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 127A412D747 for ; Fri, 3 Jun 2016 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrKI28PhWU8J for ; Fri, 3 Jun 2016 10:32:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C162A12D72A for ; Fri, 3 Jun 2016 10:32:48 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-d6-5751bf3e63ed Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.65.12926.E3FB1575; Fri, 3 Jun 2016 19:32:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Fri, 3 Jun 2016 19:32:46 +0200 From: Christer Holmberg To: Roger Marshall , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: ECRIT Interim meeting - June Thread-Index: AdG8WcQa/4sbSbn0SBC9ofdj6JXfYABW0UVwAACHd1AAABvUwAABSMsg Date: Fri, 3 Jun 2016 17:32:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38034EB6@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38034EB6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7pa79/sBwg0u7OC0aFz1ltdiw5TiL xcJfv1gcmD0ubWll91iy5CeTx91bl5gCmKO4bFJSczLLUov07RK4Mp4e+MxUMHcKY8XeS8tY GxhfNDF2MXJySAiYSCx/+4YNwhaTuHBvPZDNxSEkcIRRov/nVyYIZzGjxM4fR4EyHBxsAhYS 3f+0QeIiAj2MEn8XXWMG6RYW0JRYuamDCcQWEdCS2DHzMiuE7SYxc9JWsBoWARWJ6Tc2gG3j FfCVuLTsJ9SCjUwScyfMZgJZwCkQKNF21g2khhHoou+n1oDNZBYQl7j1ZD4TxKUCEkv2nGeG sEUlXj7+xwphK0ms2H6JEaI+X2L7km1QuwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuE rS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtzBLb9VdzBe fuN4iFGAg1GJhzdhTUC4EGtiWXFl7iFGCQ5mJRHeedsDw4V4UxIrq1KL8uOLSnNSiw8xSnOw KInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwGn984dL//Z1N0MO2S/e2518uqXJ9wGNlrWa8 WSFazWdvDue+Yydre87s11o6+UAQg4arV8W8L0ofZvfZ6S2rtbq9It3BTn1D4OGfkjYh/g/C Zd//m/7f8csbm7Md0U7HDj48P/kJg803xya1QIH8ywz/wirDd50sSpK/c+eL3MN8i3cr5ye8 V2Ipzkg01GIuKk4EAF7xbGW0AgAA Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 17:32:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38034EB6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to get some input e.g. on what changes will be done regarding the = ASN.1 encoding. Q1: Will ASN.1 be added in addition to XML? Or, will we remove XML? Q2: For ASN.1, which encoding will we use? CEN allows both UPER and EXER. A= s 3GPP wants binary encoding, at least UPER needs to be supported. What abo= ut EXER? Q3: What will we do regarding the MSD max size of 140 bytes? I'd also like to get some input regarding the usage-of-modem-on-the-media-p= lane issue I raised earlier today. Do we need to say something? What do we = need to say? Etc etc. Regards, Christer From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 03 June 2016 19:52 To: Drage, Keith (Nokia - GB) ; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Keith: I think you mean that you want to see all of your comments addressed ahead = of an updated draft, right? I see comments being made and some responses. If you have comments that you believe haven't been addressed as part of the= list discussions, resend them. Be sure to offer proposed text to what you= believe may be deficiencies in the current draft. -roger. From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com] Sent: Friday, June 03, 2016 9:45 AM To: Roger Marshall; ecrit@ietf.org Subject: RE: ECRIT Interim meeting - June Can we see some response to the comments being made first. This is a WG document, and is meant to reflect the consensus of the working= group, and not the authors thoughts and considerations. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 03 June 2016 17:41 To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT Interim meeting - June Given a variety of factors, including individuals' availability, the chairs= have decided to Not schedule an interim meeting at this time. We look for= ward to seeing continued list discussion in order to work through the curre= nt issues, and it seems like progress is being made. We also look forward = to getting an updated draft soon, so that folks can see the proposed text c= hanges being discussed. Roger Marshall & Marc Linsner ECRIT Chairs From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Wednesday, June 01, 2016 4:04 PM To: ecrit@ietf.org Subject: [Ecrit] ECRIT Interim meeting - June ECRIT: The work group needs to figure out how it can address some of the raised is= sues in order to make progress on draft-ietf-ecrit-ecall-07. We've set up a doodle poll at the following link for next week: http://doodle.com/poll/hnfhkvfgc7x6hesx Please mark your best available times to discuss. Bridge information will = follow, once we have a timeslot identified. Roger Marshall & Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_7594FB04B1934943A5C02806D1A2204B38034EB6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’d like to get some input e.g. on what changes will be done reg= arding the ASN.1 encoding.

 

Q1: Will ASN.1 be added in addition to XML? Or, will we remove XML?

 

Q2: For ASN.1, which encoding will we use? CEN allows both UPER and EX= ER. As 3GPP wants binary encoding, at least UPER needs to be supported. Wha= t about EXER?

 

Q3: What will we do regarding the MSD max size of 140 bytes?

 

I’d also like to get some input regarding the usage-of-modem-on-= the-media-plane issue I raised earlier today. Do we need to say something? = What do we need to say?

 

Etc etc.

 

Regards,

 

Christer

 

 

From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 03 June 2016 19:52
To: Drage, Keith (Nokia - GB) <keith.drage@nokia.com>; ecrit@i= etf.org
Subject: Re: [Ecrit] ECRIT Interim meeting - June
<= /p>

 

Keith:<= o:p>

I think= you mean that you want to see all of your comments addressed ahead of an u= pdated draft, right?  I see comments being made and some responses.&nb= sp;

&n= bsp;

If you = have comments that you believe haven’t been addressed as part of the = list discussions, resend them.  Be sure to offer proposed text to what= you believe may be deficiencies in the current draft.

&n= bsp;

-roger.=

&n= bsp;

From: Dr= age, Keith (Nokia - GB) [mailto:keith.drage@nokia.com]
Sent: Friday, June 03, 2016 9:45 AM
To: Roger Marshall;
ecrit@ietf.org
Subject: RE: ECRIT Interim meeting - June

 

Can we = see some response to the comments being made first.

&n= bsp;

This is= a WG document, and is meant to reflect the consensus of the working group,= and not the authors thoughts and considerations.

&n= bsp;

Keith

&n= bsp;

From: Ec= rit [mailto= :ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall;
ecrit@ietf.org
Subject: Re: [Ecrit] ECRIT Interim meeting - June
<= /p>

 

Given a= variety of factors, including individuals’ availability, the chairs = have decided to Not schedule an interim meeting at this time.  We look= forward to seeing continued list discussion in order to work through the current issues, and it seems like progress is being ma= de.  We also look forward to getting an updated draft soon, so that fo= lks can see the proposed text changes being discussed. 

&n= bsp;

Roger M= arshall & Marc Linsner

ECRIT C= hairs

&n= bsp;

From: Ec= rit [mailto= :ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To:
ecrit@ie= tf.org
Subject: [Ecrit] ECRIT Interim meeting - June

 

ECRIT:

The work group needs to figure = out how it can address some of the raised issues in order to make progress = on draft-ietf-ecrit-ecall-07.

 

We’ve set up a doodle pol= l at the following link for next week:

 

= http://doodle.com/poll/hnfhkvfgc7x6hesx

 

Please mark your best available= times to discuss.  Bridge information will follow, once we have a tim= eslot identified.

 

 

Roger Marshall & Marc Linsn= er

ECRIT Chairs<= /p>

 

 

NOTICE TO REC= IPIENT: This email, including attachments, may contain information which is= confidential, proprietary, attorney-client privileged and/or controlled un= der U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law.= Nothing in this email shall create any legal binding agreement between the= parties unless expressly stated herein and provided by an authorized repre= sentative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this m= essage, be advised that any dissemination, distribution, or use of the cont= ents of this message is strictly prohibited. If you received this message i= n error, please notify us immediately by return email and permanently delete all copies of the original email an= d any attached documentation from any computer or other media.

--_000_7594FB04B1934943A5C02806D1A2204B38034EB6ESESSMB209erics_-- From nobody Sat Jun 4 09:53:05 2016 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 D288C12D53B for ; Sat, 4 Jun 2016 09:53:04 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8fI62oMpoZm for ; Sat, 4 Jun 2016 09:53:02 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADF912D53A for ; Sat, 4 Jun 2016 09:53:02 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 09:53:02 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0EDC8@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF0EDC8@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 09:52:59 -0700 To: "Drage, Keith (Nokia - GB)" , Randall Gellens , Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 16:53:05 -0000 Hi Keith, I agree -- the additional-data mechanism shouldn't be used to regulate the transfer of INFO packages. INFO package registration does that. --Randy At 2:16 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote: > I would note that as one of the major commenters on this document, > I have not been involved in this discussion, not has it appeared > prior to this on the WG list. > > I think you absolutely need to separate what goes in the INFO > mechanism as an attached body, and what goes in other messages. The > additional-data mechanism should not be used to regulate the > transfer of INFO packages. > > That comment also probably applies to other messages designed for > transferring packages, e.g. SUBSCRIBE/NOTIFY as well. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: 03 June 2016 04:51 > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > Hi Christer, > > At 8:54 PM +0000 6/2/16, Christer Holmberg wrote: > >> Hi, >> >>>A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>>Robert Sparks, and came to the conclusion that the draft should be >>>modified slightly so that the reply to a mid-call request for an >>>>updated MSD (ecall) or VEDS (car-crash) goes in a new INFO message, >>>and that for consistency, the INFO package registration will say that >>>no body type is associated with it, and it is restricted to be used >>>>only when emergency call data is being sent using the Call-Info >>>header field mechanism per additional-data. >> >> I am not sure I understand. The main purpose of the INFO package is >> for carrying ecall information, and that ecall information is carried >> as a message body, so how can one claim that the message body is not >> associated with the INFO package??? > > As I understand it after the discussions with Paul and Robert, the > INFO package registration provides a way to authorize sending body > parts that are associated with the INFO package, but that means > that the draft has two ways of authorizing sending the same body > parts: > the base way from additional-data / Call-Info, and the INFO package > registration. So, this is a very minor change that means that the > authorization to send body parts is always per additional-data > (using Call-Info), and the INFO package registration says that INFO > can be used to send data per additional-data. > >> >> If the INFO package is supposed to be able to carry additional data >> you need to fix draft-additional-data instead, and allow the >> information to be associated with an INFO package. > > Only the ecall draft (and by extension car-crash) needs to use INFO. > >> >>>The result is that the draft will change so that all body parts are >>>sent per the additional-data Call-Info header field mechanism, and if >>>the PSAP sends a mid-call request for updated crash data, the vehicle >>>>sends a response message to that INFO and a new INFO request message >>>containing the data (simultaneously). >>> >>>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >>>preference by several representatives that when there is a mid-call >>>request for an updated MSD, the updated MSD is sent in its own >INFO >>>rather than the response to the requesting INFO, so this is in >>>alignment with the change the authors agreed with neutral SIP >>>experts. >> >> Note that this is related to the issue raised in ECRIT earlier, that >> you cannot not send *ANY* INFO package related information in an INFO >> response, as per RFC 6086. > > Yes, and the draft currently says that the info that is sent is not > INFO package related, but additional-data related, however, the > change will be that the data will be sent in a new INFO message, > which is exactly what you have been asking for. > >> >>>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 >>>rather than XML (both encodings are specified by CEN in EN 15722). >>>When this was previously discussed within the IETF, participants >>>expressed concern over using ASN.1, but in light of 3GPP's >>>preference, and because SIP can use binary content-transfer-encoding >>>for >>> body parts, I will make this change unless the group objects. >>> >>> Because of this, I don't see a need to have an interim call. >> >> I'll let others decide on that, but I don't agree with the Call-Info >> thing - unless I've misunderstood something. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- The well-bred > contradict other people. The wise contradict themselves. > --Oscar Wilde > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Teacher Strikes Idle Kids --Newspaper headline From nobody Sat Jun 4 09:58:11 2016 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 BC07312D53B for ; Sat, 4 Jun 2016 09:58:09 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGDWc5EUWllb for ; Sat, 4 Jun 2016 09:58:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6512D108 for ; Sat, 4 Jun 2016 09:58:08 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 09:58:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 09:58:06 -0700 To: Christer Holmberg , Randall Gellens , "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 Archived-At: Subject: Re: [Ecrit] MSD ASN.1 encoding (was: ECRIT Interim meeting - June) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 16:58:10 -0000 At 12:07 PM +0000 6/3/16, Christer Holmberg wrote: > >Further, 3GPP indicated they want the MSD to be encoded in ASN.1 > >rather than XML (both encodings are specified by CEN in EN 15722). >>When this was previously discussed within the IETF, participants >>expressed concern over using ASN.1, but in light of 3GPP's >>preference, and because SIP can use binary content-transfer-encoding >>for body parts, I will make this change unless the group objects. > > Could you describe example what you intend to change? Hi Christer, I intend to change the reference to the MSD from the XML encoding to the ASN.1 encoding (from Annex C to Annex A in EN 15722) and the MIME registration will delete the "+xml" suffix (so, 'application/emergencyCallData.eCall.MSD' instead of 'application/emergencyCallData.eCall.MSD+xml'), with corresponding edits to the registration template. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There's always one more bug. From nobody Sat Jun 4 10:00:00 2016 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 0FE9112D537 for ; Sat, 4 Jun 2016 09:59:59 -0700 (PDT) X-Quarantine-ID: <5yckMXLCQXPP> 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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yckMXLCQXPP for ; Sat, 4 Jun 2016 09:59:57 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6625C12B031 for ; Sat, 4 Jun 2016 09:59:57 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 09:59:57 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B380307C1@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 09:59:54 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 16:59:59 -0000 At 6:32 AM +0000 6/3/16, Christer Holmberg wrote: > Hi, > >>>>A few weeks ago, Brian and I had discussions with Paul Kyzivat and >>>> Robert Sparks, and came to the conclusion that the draft should be >>>> modified slightly so that the reply to a mid-call request for >>>> an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO >>>> message, and that for consistency, the INFO package registration >>>> will say that no body type is associated with it, and it is >>>> restricted to be used >only when emergency call data is being sent >>>> using the Call-Info header field mechanism per additional-data. >>> >>> I am not sure I understand. The main purpose of the INFO package is >>> for carrying ecall information, and that ecall information is >>> carried as a message body, so how can one claim that the message >>> body is not associated with the INFO package??? >> >>As I understand it after the discussions with Paul and Robert, the >>INFO package registration provides a way to authorize sending body >>parts that are associated with the INFO package, > > Correct. > > >> but that means that >>the draft has two ways of authorizing sending the same body parts: >>the base way from additional-data / Call-Info, and the INFO package >>registration. > > That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO > package mechanism. Yes; there will still be an INFO package, to conform with this. > >So, this is a very minor change that means that the >>authorization to send body parts is always per additional-data (using >>Call-Info), and the INFO package registration says that INFO can be >>used to send data per additional-data. > > Again, that is wrong. Information in INFO must be carried using the INFO > package mechanism. > > Note, though, that I am only talking about INFO. How you carry information > in e.g. INVITE is a separate issue. > > >>>If the INFO package is supposed to be able to carry additional data >>> you need to fix draft-additional-data instead, and allow the >>> information to be associated with an INFO package. >> >>Only the ecall draft (and by extension car-crash) needs to use INFO. > > That makes me even more confused why you would want to use something else > than an INFO packageS > > >>>>The result is that the draft will change so that all body parts are >>>> sent per the additional-data Call-Info header field mechanism, and >>>> if the PSAP sends a mid-call request for updated crash data, the >>>> vehicle >sends a response message to that INFO and a new INFO >>>> request message containing the data (simultaneously). >>>> >>>>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a >>>> preference by several representatives that when there is a >>>> mid-call request for an updated MSD, the updated MSD is sent in >>>> its own >INFO rather than the response to the requesting INFO, so >>>> this is in alignment with the change the authors agreed with >>>> neutral SIP experts. >>> >>> Note that this is related to the issue raised in ECRIT earlier, >>> that you cannot not send *ANY* INFO package related information in >>> an INFO response, as per RFC 6086. >> >>Yes, and the draft currently says that the info that is sent is not >>INFO package related, but additional-data related, however, the >>change will be that the data will be sent in a new INFO message, >>which is exactly what you have been asking for. > > And I appreciate that :) > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Miners Refuse to Work after Death --Newspaper headline From nobody Sat Jun 4 14:41:43 2016 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 1BD5C12D536 for ; Sat, 4 Jun 2016 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrVkcPvLrmIi for ; Sat, 4 Jun 2016 14:41:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FFD12D1ED for ; Sat, 4 Jun 2016 14:41:40 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-06-57534b1273ba Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.F7.12926.21B43575; Sat, 4 Jun 2016 23:41:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0294.000; Sat, 4 Jun 2016 23:41:37 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: MSD ASN.1 encoding (was: [Ecrit] ECRIT Interim meeting - June) Thread-Index: AQHRvZCKLTz3YMrTTUWDi4YaYdz44Z/ZZ98AgABpJAA= Date: Sat, 4 Jun 2016 21:41:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38035EB4@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7ma6Qd3C4wdk1EhaNi56yWnx/3sXo wOSxZMlPJo+tdx6zBDBFcdmkpOZklqUW6dslcGXcX7CaueAUV8WHXT9ZGxiPcnQxcnJICJhI tE+8wQxhi0lcuLeeDcQWEjjCKNG3H6iGC8hezCjxee1vpi5GDg42AQuJ7n/aIKaIQIhEy3su kHJhAW+JI18fsIPYIgI+EnOu/ICyrSQeHfzPDlLOIqAicag5DiTMK+ArsW/RDqhNKRL9p3sZ QWxOoGvmbb/KCmIzAl3z/dQaJhCbWUBc4taT+UwQVwpILNlzHupiUYmXj/+xQthKEo1LnrBC 1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqR sV5qUWZycXF+nl5easkmRmCEHNzyW3UH4+U3jocYBTgYlXh4H/wNDBdiTSwrrsw9xCjBwawk wuvmHhwuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgVHT TmaDFlf4odbl+3sqHjp++1RkdJtjfrPot3N7pixUOGZSMntZ47K5fy90cjukPTr2uzi4zrKI a+I9tj/ZQYoze9rPb/mnmerzuDn45AEnm70h+x1O/o2YEmb37oR4b+dd9lkzt+wuyrokdm5i xbnQ5DY+RQ+lqX98Zk0+nrzwlJIb67qZ4i1KLMUZiYZazEXFiQBxBe57jAIAAA== Archived-At: Subject: Re: [Ecrit] MSD ASN.1 encoding (was: ECRIT Interim meeting - June) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 21:41:42 -0000 Hi Randall, >>>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 >>>rather than XML (both encodings are specified by CEN in EN 15722). >>>When this was previously discussed within the IETF, participants=20 >>>expressed concern over using ASN.1, but in light of 3GPP's preference,=20 >>>and because SIP can use binary content-transfer-encoding for body=20 >>>parts, I will make this change unless the group objects. >> >> Could you describe example what you intend to change? > > Hi Christer, > > I intend to change the reference to the MSD from the XML encoding to the = ASN.1 encoding (from Annex C to Annex A in EN 15722) and=20 > the MIME registration will delete the "+xml" suffix (so, 'application/eme= rgencyCallData.eCall.MSD' instead of 'application/emergencyCallData.eCall.M= SD+xml'),=20 > with corresponding edits to the registration template. As I said in another e-mail, ASN.1 as such is not an encoding - ASN.1 defin= es multiple codings, and the CEN spec defines usage of two of those for MSD= . I assume we'll only use one of them, the UPER, which needs to be specifie= d. Also, I assume we have to specify whether the encoded output is going to be= transported in binary format, or e.g. in base64 format. These things need to be defined in the MIME definition. Regards, Christer From nobody Sat Jun 4 15:18:21 2016 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 87BC312D675 for ; Sat, 4 Jun 2016 15:18:19 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqoDGn_AGsF1 for ; Sat, 4 Jun 2016 15:18:18 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2782312D673 for ; Sat, 4 Jun 2016 15:18:18 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 15:18:17 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38035EB4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B38035EB4@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 15:18:14 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] MSD ASN.1 encoding (was: ECRIT Interim meeting - June) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 22:18:20 -0000 Hi Christer, At 9:41 PM +0000 6/4/16, Christer Holmberg wrote: > Hi Randall, > >>>>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 >>>>rather than XML (both encodings are specified by CEN in EN 15722). >>>>When this was previously discussed within the IETF, participants >>>>expressed concern over using ASN.1, but in light of 3GPP's preference, >>>>and because SIP can use binary content-transfer-encoding for body >>>>parts, I will make this change unless the group objects. >>> >>> Could you describe example what you intend to change? >> >> Hi Christer, >> >> I intend to change the reference to the MSD from the XML encoding >> to the ASN.1 encoding (from Annex C to Annex A in EN 15722) and >> the MIME registration will delete the "+xml" suffix (so, >> 'application/emergencyCallData.eCall.MSD' instead of >> 'application/emergencyCallData.eCall.MSD+xml'), >> with corresponding edits to the registration template. > > As I said in another e-mail, ASN.1 as such is not an encoding - > ASN.1 defines multiple codings, and the CEN spec defines usage of > two of those for MSD. I assume we'll only use one of them, the > UPER, which needs to be specified. Thanks for pointing that out, I appreciate it. > Also, I assume we have to specify whether the encoded output is > going to be transported in binary format, or e.g. in base64 format. I mentioned before that it would be carried in binary, since SIP supports binary content-transfer-encoding, and there is no benefit to using base64. > These things need to be defined in the MIME definition. Yes, of course. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. --G. B. Shaw From nobody Sat Jun 4 16:49:09 2016 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 868E512D539 for ; Sat, 4 Jun 2016 16:49: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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkd7PUqzz3tF for ; Sat, 4 Jun 2016 16:49:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A207712D133 for ; Sat, 4 Jun 2016 16:49:05 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 16:49:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 16:49:03 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 23:49:08 -0000 Hi Christer, I think in-band modem is out of scope of the draft. The draft is limited to SIP signaling aspects. --Randy At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: > Hi, > > 3GPP agreed that, when communicating with a PSTN PSAP, it shall be > possible to transport MSD using a legacy modem on the media plane. The > reason is for not mandating the network to perform "interworking between > MSD transported in INVITE/INFO and MSD transported using a legacy modem on > the media plane". > > I don't think the ecall draft needs to consider WHEN the MSD will be > transported using a legacy modem on the media plane, but I think the draft > should describe the possibility, so that PSAPs are aware of it. > > Also, as the same eCall URNs will be used for calls where the MSD is > transported using a legacy modem on the media plane, the draft must enable > usage of the eCall URNs in setup of an IMS emergency call where MSD is > transported using the legacy modem on the media plane. > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- >From new transmitters came the old stupidities. --Bertolt Brecht From nobody Sat Jun 4 16:51:12 2016 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 4BD5212D1BB for ; Sat, 4 Jun 2016 16:51:10 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xdm7rY_E4hEB for ; Sat, 4 Jun 2016 16:51:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B108D12B074 for ; Sat, 4 Jun 2016 16:51:08 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 16:51:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 16:51:05 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 23:51:10 -0000 Hi Christer, The draft will be changed to specify sending the MSD in the CEN ASN.1 encoding, using binary content-transfer-encoding. So, the result will be in conformance with 3GPP's wishes. The draft does not need to impose a specific limit of its own. At 11:38 AM +0000 6/3/16, Christer Holmberg wrote: > Content-Language: en-US > Content-Type: multipart/alternative; > boundary="_000_D37747B09B2Dchristerholmbergericssoncom_" > > Hi, > > 3GPP has specified a maximum size of 140 bytes for the MSD. We > either need to make that a general limit for the info package, or > we need to have a mechanism to indicate the max size. Indicating > the max size can be done e.g. by defining an Recv-Info header field > info package parameter. > > Example: > > Recv-Info: emergencyCallData.eCall; max-msd-size=140 > > Note that the size represents the size of the MSD in raw binary > format - depending on the encoding the size may be bigger "on the > wire". > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This fortune intentionally not included. From nobody Sat Jun 4 16:52:28 2016 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 4DEE212D1BB for ; Sat, 4 Jun 2016 16:52:27 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOTqPCDyu951 for ; Sat, 4 Jun 2016 16:52:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A421D12B074 for ; Sat, 4 Jun 2016 16:52:25 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 4 Jun 2016 16:52:26 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0DD72@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF0DD72@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Jun 2016 16:52:21 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 23:52:27 -0000 The draft describes the current MSD, which as Keith says, has its own size limit. At 1:57 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote: > Maybe this is playing with words, but the MSD always has a maximum > size of 140 octets, and has a standard content defined by the > existing CEN document. > > If there is data beyond this existing data content definition, it > is no longer the MSD, but some other data set, that needs to be > called something else. > > I wonder if we actually have two different info packages, rather > than some package parameter, i.e. package v1 with MSD only, package > v2 etc with additional data beyond MSD. 3GPP release 14 only > requires v1 at the moment. > > > Keith > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 03 June 2016 12:39 > To: ecrit@ietf.org > Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size > > Hi, > > 3GPP has specified a maximum size of 140 bytes for the MSD. We > either need to make that a general limit for the info package, or > we need to have a mechanism to indicate the max size. Indicating > the max size can be done e.g. by defining an Recv-Info header field > info package parameter. > > Example: > > Recv-Info: emergencyCallData.eCall; max-msd-size=140 > > Note that the size represents the size of the MSD in raw binary > format - depending on the encoding the size may be bigger "on the > wire". > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- They're only trying to make me LOOK paranoid! From nobody Sat Jun 4 22:21:43 2016 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 64C2E128874 for ; Sat, 4 Jun 2016 22:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9pf1c_J7AkM for ; Sat, 4 Jun 2016 22:21:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E67A12B02D for ; Sat, 4 Jun 2016 22:21:38 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-be-5753b6e08036 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.15.12516.0E6B3575; Sun, 5 Jun 2016 07:21:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Sun, 5 Jun 2016 07:21:36 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRvruw7p53FxT91E+Ats5sH2il3p/aVsoT Date: Sun, 5 Jun 2016 05:21:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380360BE@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380360BEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdUffBtuBwgwXrdS0aFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4MrYO3UCY8FZvYplP+awNzAeVe9i5OSQEDCR mPb/ACOELSZx4d56NhBbSOAIo8SL/oQuRi4gezGjxJfp89m7GDk42AQsJLr/aYOYIgIhEi3v uUDKhQWiJBo3bmEGsUUEoiUeTtvCBmEbSbxYchvMZhFQkVi//DcLiM0r4CvxdttZJohVSRJf O7ezgYzkBDpn5Ut7kDAj0DXfT60BK2EWEJdo+rKSFeJKAYkle84zQ9iiEi8f/2OFqMmXeLPs FRPEeEGJkzOfsExgFJ6FpH0WkrJZSMog4gYSX97fhrK1JZYtfM0MYetLdL8/zYQsvoCRfRWj aHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYOQc3PJbdwfj6teOhxgFOBiVeHgT/IPDhVgTy4or cw8xSnAwK4nwVm4GCvGmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl 4uCUamA0X7K1S8oxdPo28x3Ln9xZv/UA40QHxdBVj3qXXeeZbDRDkl3/4KuE1QmfYvgKQq6E iog4f5jyxqNio3fypPA6gZOGAnd8gvd+Y3n0Ji0mzen0Ep55NV+Ofg76P937XXBp2U8PP23n UGUO4+VXFumdt533NOPucyulnVm5H/tDb2r83xV9Ij5GiaU4I9FQi7moOBEAGmK+SJgCAAA= Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:21:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380360BEESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, The draft also defines eCall URNs, and those cannot be limited to SIP. Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD05/=FD06/=FD2016 02:49 To: Christer Holmberg; ecrit@ietf.or= g Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi Christer, I think in-band modem is out of scope of the draft. The draft is limited to SIP signaling aspects. --Randy At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: > Hi, > > 3GPP agreed that, when communicating with a PSTN PSAP, it shall be > possible to transport MSD using a legacy modem on the media plane. The > reason is for not mandating the network to perform "interworking between > MSD transported in INVITE/INFO and MSD transported using a legacy modem = on > the media plane". > > I don't think the ecall draft needs to consider WHEN the MSD will be > transported using a legacy modem on the media plane, but I think the dra= ft > should describe the possibility, so that PSAPs are aware of it. > > Also, as the same eCall URNs will be used for calls where the MSD is > transported using a legacy modem on the media plane, the draft must enab= le > usage of the eCall URNs in setup of an IMS emergency call where MSD is > transported using the legacy modem on the media plane. > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- >From new transmitters came the old stupidities. --Bertolt Brecht --_000_7594FB04B1934943A5C02806D1A2204B380360BEESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

The draft also defines eCall URNs, and those cannot be limited to SIP.

Regards,

Christer

Sent from my Windows Phone

From: Randall Gellens
Sent: =FD05= /=FD06/=FD2016 02:49
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD

Hi Christer,

I think in-band modem is out of scope of the draft.  The draft is
limited to SIP signaling aspects.

--Randy

At 11:35 AM +0000 6/3/16, Christer Holmberg wrote:

>  Hi,
>
>  3GPP agreed that, when communicating with a PSTN PSAP, it shall = be
>  possible to transport MSD using a legacy modem on the media plan= e. The
>  reason is for not mandating the network to perform "interwo= rking between
>  MSD transported in INVITE/INFO and MSD transported using a legac= y modem on
>  the media plane".
>
>  I don't think the ecall draft needs to consider WHEN the MSD wil= l be
>  transported using a legacy modem on the media plane, but I think= the draft
>  should describe the possibility, so that PSAPs are aware of it.<= br> >
>  Also, as the same eCall URNs will be used for calls where the MS= D is
>  transported using a legacy modem on the media plane, the draft m= ust enable
>  usage of the eCall URNs in setup of an IMS emergency call where = MSD is
>  transported using the legacy modem on the media plane.
>
>  Regards,
>
>  Christer
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
https://= www.ietf.org/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only
-------------- Randomly selected tag: ---------------
>From new transmitters came the old stupidities.   --Bertolt Brech= t
--_000_7594FB04B1934943A5C02806D1A2204B380360BEESESSMB209erics_-- From nobody Sat Jun 4 22:27:24 2016 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 88B8412B02D for ; Sat, 4 Jun 2016 22:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFwUUl9BtoH0 for ; Sat, 4 Jun 2016 22:27:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3299212B033 for ; Sat, 4 Jun 2016 22:27:21 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-1e-5753b83722d4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.F2.12926.738B3575; Sun, 5 Jun 2016 07:27:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Sun, 5 Jun 2016 07:27:19 +0200 From: Christer Holmberg To: Christer Holmberg , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRvuon3ke1IKFraEKNbHBLjHf78J/aWAaC Date: Sun, 5 Jun 2016 05:27:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> References: , , <7594FB04B1934943A5C02806D1A2204B380360BE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B380360BE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3803614CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdWtd8R3C4wfIjchaNi56yWnx/3sXo wOSxZMlPJo+tdx6zBDBFcdmkpOZklqUW6dslcGV86DrEWPDeumLe7QWsDYwrjbsYOTkkBEwk lq/rY4KwxSQu3FvP1sXIxSEkcIRR4ua/HmYIZzGjxMPPExm7GDk42AQsJLr/aYPERQQ6GCVO HZrLAtItLBApsXJdOwtIjYhAlMT1zliQsIiAkcTTd/8ZQWwWARWJG0vfsoLYvAK+En2NbewQ 85czSqyZNZcZJMEp4CfRd2EDWBEj0EXfT60Bu45ZQFyi6ctKVohLBSSW7DnPDGGLSrx8/I8V oiZfYtemTWwQCwQlTs58wjKBUXgWkvZZSMpmISmDiBtIfHl/G8rWlli28DUzhK0v0f3+NBOy +AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgRF0cMtv1R2Ml984HmIU4GBU4uFN8A8O F2JNLCuuzD3EKMHBrCTCW7kZKMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZq akFqEUyWiYNTqoGRI8PssHVjmXmHvcGhXxFcMz6dqJd9wcq77Hb6h7Qpqw4Xmq3r6rry+vwK 03+lTMmeqx/ty5RVass5uD469Jxd5YIa2a4FdeI8sZuPWqYZvN/51HebzKTT878tKJ/4/b9S 1eS9bAujPs1+yv5de8r6DaJNfaaHI2e/CbFh+atxluv7lsZA1hR3JZbijERDLeai4kQAYcb7 sJwCAAA= Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:27:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3803614CESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Clarification: the URNs cannot be limited to the INFO mechanism for transpo= rting MSD. Regards, Christer Sent from my Windows Phone ________________________________ From: Christer Holmberg Sent: =FD05/=FD06/=FD2016 08:21 To: Randall Gellens; ecrit@ietf.org Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi, The draft also defines eCall URNs, and those cannot be limited to SIP. Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD05/=FD06/=FD2016 02:49 To: Christer Holmberg; ecrit@ietf.or= g Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi Christer, I think in-band modem is out of scope of the draft. The draft is limited to SIP signaling aspects. --Randy At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: > Hi, > > 3GPP agreed that, when communicating with a PSTN PSAP, it shall be > possible to transport MSD using a legacy modem on the media plane. The > reason is for not mandating the network to perform "interworking between > MSD transported in INVITE/INFO and MSD transported using a legacy modem = on > the media plane". > > I don't think the ecall draft needs to consider WHEN the MSD will be > transported using a legacy modem on the media plane, but I think the dra= ft > should describe the possibility, so that PSAPs are aware of it. > > Also, as the same eCall URNs will be used for calls where the MSD is > transported using a legacy modem on the media plane, the draft must enab= le > usage of the eCall URNs in setup of an IMS emergency call where MSD is > transported using the legacy modem on the media plane. > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- >From new transmitters came the old stupidities. --Bertolt Brecht --_000_7594FB04B1934943A5C02806D1A2204B3803614CESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Clarification= : the URNs cannot be limited to the INFO mechanism for transporting MSD.
Regards,

Christer

Sent from my Windows Phone

From: Christer Holmberg Sent: =FD05= /=FD06/=FD2016 08:21
To: Randall Gellens; ecrit@ietf.org
Subject: Re: [= Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD

Hi,

The draft also defines eCall URNs, and those cannot be limited to SIP.

Regards,

Christer

Sent from my Windows Phone

From: Randall Gellens
Sent: =FD05= /=FD06/=FD2016 02:49
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD

Hi Christer,

I think in-band modem is out of scope of the draft.  The draft is
limited to SIP signaling aspects.

--Randy

At 11:35 AM +0000 6/3/16, Christer Holmberg wrote:

>  Hi,
>
>  3GPP agreed that, when communicating with a PSTN PSAP, it shall = be
>  possible to transport MSD using a legacy modem on the media plan= e. The
>  reason is for not mandating the network to perform "interwo= rking between
>  MSD transported in INVITE/INFO and MSD transported using a legac= y modem on
>  the media plane".
>
>  I don't think the ecall draft needs to consider WHEN the MSD wil= l be
>  transported using a legacy modem on the media plane, but I think= the draft
>  should describe the possibility, so that PSAPs are aware of it.<= br> >
>  Also, as the same eCall URNs will be used for calls where the MS= D is
>  transported using a legacy modem on the media plane, the draft m= ust enable
>  usage of the eCall URNs in setup of an IMS emergency call where = MSD is
>  transported using the legacy modem on the media plane.
>
>  Regards,
>
>  Christer
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
https://= www.ietf.org/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only
-------------- Randomly selected tag: ---------------
>From new transmitters came the old stupidities.   --Bertolt B= recht
--_000_7594FB04B1934943A5C02806D1A2204B3803614CESESSMB209erics_-- From nobody Sat Jun 4 22:31:43 2016 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 E5BDF12D541 for ; Sat, 4 Jun 2016 22:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z861Z5FulASV for ; Sat, 4 Jun 2016 22:31:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0905128874 for ; Sat, 4 Jun 2016 22:31:39 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-e2-5753b93938cb Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B3.D5.12516.939B3575; Sun, 5 Jun 2016 07:31:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Sun, 5 Jun 2016 07:31:37 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: max MSD size Thread-Index: AQHRvrwlO1Y4sum6X0KVKa425ZP/6p/aWZda Date: Sun, 5 Jun 2016 05:31:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38036195@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADF0DD72@FR712WXCHMBA11.zeu.alcatel-l ucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38036195ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7iK7VzuBwg+uLmSwaFz1ltdiw5TiL xffnXYwOzB5Llvxk8rh76xKTx9Y7j1kCmKO4bFJSczLLUov07RK4MvYcms5YsMqiYvlJzQbG vfpdjJwcEgImEn9udzND2GISF+6tZwOxhQSOMEq0fyyBsBczSrz+Id3FyMHBJmAh0f1Pu4uR i0NEoJNRYve1k4wgNcICthL/V/8As0UE7CT+PLjKDmEbSZx8NB0sziKgIvF+3SSwOK+Ar8Tc CQfZQQYJCexglPj/aTULSIIT6KDt+yAOYgQ66PupNUwgNrOAuETTl5WsEIcKSCzZcx7qaFGJ l4//sULU5Ev8utHBBLFAUOLkzCcsExiFZyFpn4WkbBaSMoi4gcSX97ehbG2JZQtfM0PY+hLd 708zIYsvYGRfxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYUQe3/Nbdwbj6teMhRgEORiUe 3gT/4HAh1sSy4srcQ4wSHMxKIryVm4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQn lqRmp6YWpBbBZJk4OKUaGL3F7+tMSjlfM7t+4bGDvSt/LBTmWb/mxSX5Q5VS3zWCE7/tKX/h /WveGrveHWZ+AbuLv8bK7+1LS5I139ocqLVGYtefVmvbPtPpv+OEY7uvhEa6R92Oztx505gj tCbjh7vT2qnVgsKiL654/LHM6GhpEF/G8+ztzrlqM3crKUbFVz8qzjq5V4mlOCPRUIu5qDgR AKiDDHWkAgAA Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 05:31:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38036195ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I guess the "current MSD" also nerds to be described in the MIME descriptio= n. E.g. "This MIME is used for carrying MSDs as defined in XXX". Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD05/=FD06/=FD2016 02:52 To: Drage, Keith (Nokia - GB); Christer Holmb= erg; ecrit@ietf.org Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size The draft describes the current MSD, which as Keith says, has its own size limit. At 1:57 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote: > Maybe this is playing with words, but the MSD always has a maximum > size of 140 octets, and has a standard content defined by the > existing CEN document. > > If there is data beyond this existing data content definition, it > is no longer the MSD, but some other data set, that needs to be > called something else. > > I wonder if we actually have two different info packages, rather > than some package parameter, i.e. package v1 with MSD only, package > v2 etc with additional data beyond MSD. 3GPP release 14 only > requires v1 at the moment. > > > Keith > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmbe= rg > Sent: 03 June 2016 12:39 > To: ecrit@ietf.org > Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size > > Hi, > > 3GPP has specified a maximum size of 140 bytes for the MSD. We > either need to make that a general limit for the info package, or > we need to have a mechanism to indicate the max size. Indicating > the max size can be done e.g. by defining an Recv-Info header field > info package parameter. > > Example: > > Recv-Info: emergencyCallData.eCall; max-msd-size=3D140 > > Note that the size represents the size of the MSD in raw binary > format - depending on the encoding the size may be bigger "on the > wire". > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- They're only trying to make me LOOK paranoid! --_000_7594FB04B1934943A5C02806D1A2204B38036195ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I guess the "current MSD" also nerds to be described in the MIME = description.

E.g. "This MIME is used for carrying MSDs as defined in XXX".

Regards,

Christer

Sent from my Windows Phone

From: Randall Gellens
Sent: =FD05= /=FD06/=FD2016 02:52
To: Drage, Keith (Nokia - GB); Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] 3GPP impact on draft-ecall: max MSD size

The draft describes the current MSD, which as Keit= h says, has its own
size limit.

At 1:57 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote:

>  Maybe this is playing with words, but the MSD always has a maxim= um
> size of 140 octets, and has a standard content defined by the
> existing CEN document.
>
>  If there is data beyond this existing data content definition, i= t
> is no longer the MSD, but some other data set, that needs to be
> called something else.
>
>  I wonder if we actually have two different info packages, rather=
> than some package parameter, i.e. package v1 with MSD only, package > v2 etc with additional data beyond MSD. 3GPP release 14 only
> requires v1 at the moment.
>
>
>  Keith
>
>  From: Ecrit [mailto:ec= rit-bounces@ietf.org] On Behalf Of Christer Holmberg
>  Sent: 03 June 2016 12:39
>  To: ecrit@ietf.org
>  Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size
>
>  Hi,
>
>  3GPP has specified a maximum size of 140 bytes for the MSD. We <= br> > either need to make that a general limit for the info package, or
> we need to have a mechanism to indicate the max size. Indicating
> the max size can be done e.g. by defining an Recv-Info header field > info package parameter.
>
>  Example:
>
>  Recv-Info: emergencyCallData.eCall; max-msd-size=3D140
>
>  Note that the size represents the size of the MSD in raw binary =
> format - depending on the encoding the size may be bigger "on the=
> wire".
>
>  Regards,
>
>  Christer
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
https://= www.ietf.org/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only
-------------- Randomly selected tag: ---------------
They're only trying to make me LOOK paranoid!
--_000_7594FB04B1934943A5C02806D1A2204B38036195ESESSMB209erics_-- From nobody Sat Jun 4 23:05:17 2016 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 C217B12D112 for ; Sat, 4 Jun 2016 23:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XVxu7b1oSJd for ; Sat, 4 Jun 2016 23:05:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD87B12D10E for ; Sat, 4 Jun 2016 23:05:13 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-aa-5753c11724eb Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.5D.27088.711C3575; Sun, 5 Jun 2016 08:05:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Sun, 5 Jun 2016 08:05:11 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: max MSD size Thread-Index: AQHRvrv3/z4S5KmBLkOSqUfhHB7f8Z/aYr8g Date: Sun, 5 Jun 2016 06:05:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3803626C@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7n674weBwg0dLTSwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4MrYvbqTpeAMb8XUpwdZGxj/c3UxcnJICJhI TDw1kwXCFpO4cG89WxcjF4eQwBFGiZYbS6GcxYwSl5q+AlVxcLAJWEh0/9MGMUUEQiRa3oPN ERawlfi/+gcjiC0iYCfx58FVdgjbSKJpUhdYJ4uAisSpGxYgYV4BX4kNjUvBwkICKRLXX2eA hDlBrlm1DmwKI9A130+tYQKxmQXEJW49mc8EcaWAxJI955khbFGJl4//sULYShIrtl9ihKjX kViw+xMbhK0tsWzha2aItYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTipNx0IyO9 1KLM5OLi/Dy9vNSSTYzACDm45bfBDsaXzx0PMQpwMCrx8Cb4B4cLsSaWFVfmHmKU4GBWEuF9 vgcoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgdE0j81H 6I0T0+G+yOqfTqdYW7aKLP12SeD8pR6GosdvD32J1jHclplZ8VHwZe2kJVMOT/KMKLsZsO2Q 6LE1dVs+P3TQ2O6yu7IzibntaUosZ9Xjc6fZQ04vN3tQ9CDC52n3h+o3c2Vdz/qXhC2yrvur pbbwj/KXJ69nJErU1q7mzbxeK9+S0K7EUpyRaKjFXFScCAD3kxMJjAIAAA== Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 06:05:16 -0000 Hi, I guess 'Content-Type: multipart/alternative' is a mistake? Regards, Christer -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 05 June 2016 02:51 To: Christer Holmberg ; ecrit@ietf.org Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size Hi Christer, The draft will be changed to specify sending the MSD in the CEN ASN.1 encod= ing, using binary content-transfer-encoding. So, the result will be in con= formance with 3GPP's wishes. The draft does not need to impose a specific = limit of its own. At 11:38 AM +0000 6/3/16, Christer Holmberg wrote: > Content-Language: en-US > Content-Type: multipart/alternative; > boundary=3D"_000_D37747B09B2Dchristerholmbergericssoncom_" > > Hi, > > 3GPP has specified a maximum size of 140 bytes for the MSD. We either=20 > need to make that a general limit for the info package, or we need to=20 > have a mechanism to indicate the max size. Indicating the max size can=20 > be done e.g. by defining an Recv-Info header field info package=20 > parameter. > > Example: > > Recv-Info: emergencyCallData.eCall; max-msd-size=3D140 > > Note that the size represents the size of the MSD in raw binary=20 > format - depending on the encoding the size may be bigger "on the=20 > wire". > > Regards, > > Christer > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This fortune intentio= nally not included. From nobody Mon Jun 6 05:15:46 2016 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 8D50212D0DA for ; Mon, 6 Jun 2016 05:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3RxjSSMfiUX for ; Mon, 6 Jun 2016 05:15:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF88112B03A for ; Mon, 6 Jun 2016 05:15:43 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-dd-5755696e4476 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.53.12926.E6965575; Mon, 6 Jun 2016 14:15:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Mon, 6 Jun 2016 14:15:41 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-ecall: A few editorial change suggestions Thread-Index: AQHRv+0kjJcJLRVjy0K5Da/1iuK7xQ== Date: Mon, 6 Jun 2016 12:15:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D37B44D69E9Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdUTcvMzTcoGOOkEXjoqesDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+Dn1MVvBJtGKAy1PGBsYXwp2MXJySAiYSLw9e48FwhaTuHBv PVsXIxeHkMARRonrz9eyQDiLGSUuHzjH1MXIwcEmYCHR/U8bpEFEQFViw5mVjCC2MFC4Z+If Roi4rcS31+9ZIWw9iT2zV4PFWQRUJGY86QYbwytgJbFrggxImBFo7/dTa5hAbGYBcYlbT+Yz QdwjILFkz3lmCFtU4uXjf2AjRYFGfrk3jxEiriix82w7M0RvvETPh0NgNq+AoMTJmU9YJjAK z0IydhaSsllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lrj3pZcFWc0CRo5VjKLFqcVJ uelGxnqpRZnJxcX5eXp5qSWbGIERdHDLb9UdjJffOB5iFOBgVOLhfbAgJFyINbGsuDL3EKME B7OSCK9kSmi4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6p BsYerp2BG/fVmfadFGc4fnXafb5MUd7DB/WPGdkU5bxKbN5hJ7L5rGK/AU98X3TGmeOsy6ou bzlm+3uCuteeY4/+v/i+dsHU1ZOyT2v0bORa8+y4VXfz5w+X7D5+cN/2KUNf6uyzoO1sh1Wu JlRvefYyQPTUbz7xDx/WHVn2b6LUIr2PUhmmMdo/lViKMxINtZiLihMB5xcLT5wCAAA= Archived-At: Subject: [Ecrit] draft-ecall: A few editorial change suggestions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 12:15:45 -0000 --_000_D37B44D69E9Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A few (I will do a more detailed review once we get the changes based on th= e 3GPP requirements implemented) editorial comments on the ecall draft: Q1: The Abstract needs to be shorter. There are too many ecall details that= I think can be removed. Q2: In section 3, I suggested to remove =93Currently,=94. If you really wa= nt to refer to the current time, you could say something like =93At the tim= e of writing this document,=94 but personally I don=92t think it=92s needed= in this case. Q3: Similar to Q2, I suggest to remove/replace "is now in process.=94. Q4: Would it be possible to make sections 7 and 8 to subsections of sectio= n 6? Q5: I suggest that we put the INFO package definition in a separate main s= ection instead of subsection (9.2). Thanks! Regards, Christer --_000_D37B44D69E9Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4FFE96118E6C5F41B01354FD51D01591@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

A few (I will do a more detailed review once we get the changes based = on the 3GPP requirements implemented) editorial comments on the ecall draft= :

Q1: Th= e Abstract needs to be shorter. There are too many ecall details that I thi= nk can be removed.

Q2:  In section 3, I suggested to remove =93Currently,=94. If you= really want to refer to the current time, you could say something like =93= At the time of writing this document,=94 but personally I don=92t think it= =92s needed in this case.

Q3:  Similar to Q2, I suggest to remove/replace "is now in p= rocess.=94.

Q4:  Would it be possible to make sections 7 and 8 to subsections= of section 6?

Q5:  I suggest that we put the INFO package definition in a separ= ate main section instead of subsection (9.2).

Thanks!

Regards,

Christer
--_000_D37B44D69E9Bchristerholmbergericssoncom_-- From nobody Tue Jun 7 00:11:41 2016 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 BF00A12D10E for ; Tue, 7 Jun 2016 00:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-H1Ot5OL88G for ; Tue, 7 Jun 2016 00:11:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6004112D1C8 for ; Tue, 7 Jun 2016 00:11:31 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-64-575673a11ee8 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.34.12926.1A376575; Tue, 7 Jun 2016 09:11:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 09:11:26 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: draft-ecall: References to draft-additional-data Thread-Index: AQHRwIvN3NrajcJyG0SOK/L21RpYWQ== Date: Tue, 7 Jun 2016 07:11:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D37C4F0A9F4Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdUXdhcVi4we12dYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0X3sKVPBbp6KF1vXsTcw3uHqYuTkkBAwkZh17QArhC0mceHe erYuRi4OIYEjjBJ7Ns9gBEkICSxmlDhw0qWLkYODTcBCovufNkhYREBVYsOZlWAlwgJWEm2v 1jBBxO0lNu8CmQNi60nMXX0YbD6LgIrEwtlnmUHG8ALVnznNDRJmBFr7/RREK7OAuMStJ/OZ IM4RkFiy5zwzhC0q8fLxP7AxokAjv9ybxwgRV5TYebadGaI3XuJI/1qwGl4BQYmTM5+wTGAU noVk7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DFUr7XEg0XT2ZHVLGDkWMUoWpxanJSb bmSsl1qUmVxcnJ+nl5dasokRGD8Ht/xW3cF4+Y3jIUYBDkYlHt4FWmHhQqyJZcWVuYcYJTiY lUR4pxUBhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTB6 nP/x8tq81vqTaUybQ5rf2YToVd6tyjr2zpR/71zNuZz/qnqSSvZsbtb/3avzO2V25pbGFs2e 9H9TXLb9dl/yTWv93oPMIkyMlVu9wrbE868OKE2atC8lLb9Kddr9kD9rtP/sVtD2O3v0Yn6h 7uImthfaf+PLtWdLlwpLdS7sXOqz+4LYr2wlluKMREMt5qLiRACoXfJKmwIAAA== Archived-At: Subject: [Ecrit] draft-ecall: References to draft-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 07:11:40 -0000 --_000_D37C4F0A9F4Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There are quite many references to draft-additional-data in draft-ecall. I think we should have a section where we describe how to carry the ecall i= nformation in INVITE messages (non-INFO), and refer to the mechanism in dra= ft-additional-data. But, otherwise I think we should try to avoid referenci= ng draft-additional-data if possible. Regards, Christer --_000_D37C4F0A9F4Bchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

There are quite many references to draft-additional-data in draft-ecal= l.

I think we should have a section where we describe how to carry the ec= all information in INVITE messages (non-INFO), and refer to the mechanism i= n draft-additional-data. But, otherwise I think we should try to avoid refe= rencing draft-additional-data if possible.

Regards,

Christer
--_000_D37C4F0A9F4Bchristerholmbergericssoncom_-- From nobody Tue Jun 7 17:03:16 2016 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 ACDD312D65E for ; Tue, 7 Jun 2016 17:03:14 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVDU-vzrf927 for ; Tue, 7 Jun 2016 17:03:13 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1182C12D0DB for ; Tue, 7 Jun 2016 17:03:13 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Jun 2016 17:03:13 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jun 2016 17:03:08 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 00:03:15 -0000 Hi Christer, The URNs are registered as child elements of the SOS service URN, so they are in no way limited to INFO. At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: > Clarification: the URNs cannot be limited to the INFO mechanism for > transporting MSD. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Christer Holmberg > Sent: 05/06/2016 08:21 > To: Randall Gellens; > ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy > modem to transport MSD > > Hi, > > The draft also defines eCall URNs, and those cannot be limited to SIP. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 05/06/2016 02:49 > To: Christer Holmberg; > ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy > modem to transport MSD > > Hi Christer, > > I think in-band modem is out of scope of the draft. The draft is > limited to SIP signaling aspects. > > --Randy > > At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: > >> Hi, >> >> 3GPP agreed that, when communicating with a PSTN PSAP, it shall be >> possible to transport MSD using a legacy modem on the media plane. The >> reason is for not mandating the network to perform "interworking between >> MSD transported in INVITE/INFO and MSD transported using a legacy modem on >> the media plane". >> >> I don't think the ecall draft needs to consider WHEN the MSD will be >> transported using a legacy modem on the media plane, but I think the draft >> should describe the possibility, so that PSAPs are aware of it. >> >> Also, as the same eCall URNs will be used for calls where the MSD is >> transported using a legacy modem on the media plane, the draft must enable >> usage of the eCall URNs in setup of an IMS emergency call where MSD is >> transported using the legacy modem on the media plane. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- >>From new transmitters came the old stupidities. --Bertolt Brecht -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- True patriotism hates injustice in its own land more than anywhere else. --Clarence Darrow From nobody Tue Jun 7 17:06:27 2016 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 6587212D8FF for ; Tue, 7 Jun 2016 17:06:26 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvF2KMQjI_JX for ; Tue, 7 Jun 2016 17:06:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 071D212D8EB for ; Tue, 7 Jun 2016 17:06:25 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Jun 2016 17:06:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38036195@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADF0DD72@FR712WXCHMBA11.zeu.alcatel-l ucent.com>, <7594FB04B1934943A5C02806D1A2204B38036195@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jun 2016 17:06:21 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 00:06:26 -0000 Hi Christer, Yes, the MIME registration will be updated from "Published specification: Annex C of EN 15722" to "Published specification: Annex A of EN 15722". At 5:31 AM +0000 6/5/16, Christer Holmberg wrote: > Hi, > > I guess the "current MSD" also nerds to be described in the MIME description. > > E.g. "This MIME is used for carrying MSDs as defined in XXX". > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 05/06/2016 02:52 > To: Drage, Keith (Nokia - GB); > Christer Holmberg; > ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: max MSD size > > The draft describes the current MSD, which as Keith says, has its own > size limit. > > At 1:57 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote: > >> Maybe this is playing with words, but the MSD always has a maximum >> size of 140 octets, and has a standard content defined by the >> existing CEN document. >> >> If there is data beyond this existing data content definition, it >> is no longer the MSD, but some other data set, that needs to be >> called something else. >> >> I wonder if we actually have two different info packages, rather >> than some package parameter, i.e. package v1 with MSD only, package >> v2 etc with additional data beyond MSD. 3GPP release 14 only >> requires v1 at the moment. >> >> >> Keith >> >> From: Ecrit >> [mailto:ecrit-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: 03 June 2016 12:39 >> To: ecrit@ietf.org >> Subject: [Ecrit] 3GPP impact on draft-ecall: max MSD size >> >> Hi, >> >> 3GPP has specified a maximum size of 140 bytes for the MSD. We >> either need to make that a general limit for the info package, or >> we need to have a mechanism to indicate the max size. Indicating >> the max size can be done e.g. by defining an Recv-Info header field >> info package parameter. >> >> Example: >> >> Recv-Info: emergencyCallData.eCall; max-msd-size=140 >> >> Note that the size represents the size of the MSD in raw binary >> format - depending on the encoding the size may be bigger "on the >> wire". >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > They're only trying to make me LOOK paranoid! -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Consistency is the last refuge of the unimaginative. --Oscar Wilde From nobody Tue Jun 7 17:58:03 2016 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 4280B12D615 for ; Tue, 7 Jun 2016 17:58:01 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRPkwaLWRPlb for ; Tue, 7 Jun 2016 17:57:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 552BE12D675 for ; Tue, 7 Jun 2016 17:57:59 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Jun 2016 17:57:59 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jun 2016 17:57:54 -0700 To: "Drage, Keith (Nokia - GB)" , 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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 00:58:01 -0000 Hi Keith, The authors have been replying, and will be updating the draft taking the comments into account. If you think we made a mistake and the draft doesn't reflect consensus, just let us know. --Randy At 4:45 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote: > Can we see some response to the comments being made first. > > This is a WG document, and is meant to reflect the consensus of the > working group, and not the authors thoughts and considerations. > > Keith > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: 03 June 2016 17:41 > To: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > Given a variety of factors, including individuals' availability, > the chairs have decided to Not schedule an interim meeting at this > time. We look forward to seeing continued list discussion in order > to work through the current issues, and it seems like progress is > being made. We also look forward to getting an updated draft soon, > so that folks can see the proposed text changes being discussed. > > Roger Marshall & Marc Linsner > ECRIT Chairs > > From: Ecrit > [mailto:ecrit-bounces@ietf.org] On > Behalf Of Roger Marshall > Sent: Wednesday, June 01, 2016 4:04 PM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT Interim meeting - June > > ECRIT: > The work group needs to figure out how it can address some of the > raised issues in order to make progress on > draft-ietf-ecrit-ecall-07. > > We've set up a doodle poll at the following link for next week: > > > http://doodle.com/poll/hnfhkvfgc7x6hesx > > Please mark your best available times to discuss. Bridge > information will follow, once we have a timeslot identified. > > > Roger Marshall & Marc Linsner > ECRIT Chairs > > > NOTICE TO RECIPIENT: This email, including attachments, may contain > information which is confidential, proprietary, attorney-client > privileged and/or controlled under U.S. export laws and regulations > and may be restricted from disclosure by applicable State and > Federal law. Nothing in this email shall create any legal binding > agreement between the parties unless expressly stated herein and > provided by an authorized representative of Comtech > Telecommunications Corp. or its subsidiaries. If you are not the > intended recipient of this message, be advised that any > dissemination, distribution, or use of the contents of this message > is strictly prohibited. If you received this message in error, > please notify us immediately by return email and permanently delete > all copies of the original email and any attached documentation > from any computer or other media. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Invention is the mother of necessity. --Thorstein Veblen From nobody Tue Jun 7 18:06:51 2016 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 8C0FC12D67F for ; Tue, 7 Jun 2016 18:06:50 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdsO3alCyELj for ; Tue, 7 Jun 2016 18:06:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59812D67B for ; Tue, 7 Jun 2016 18:06:48 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Jun 2016 18:06:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jun 2016 18:06:46 -0700 To: "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:06:50 -0000 Hi Keith, At 12:17 PM +0000 5/19/16, Keith (Nokia - GB) Drage wrote: > I did a reread of the INFO RFC last night in respect of the above > draft, and came to the following conclusions. > > 1) Any usage of the INFO method requires a full Info package > definition. While there are various mentions of legacy usage, the > draft is not trying to follow that direction, and in any case I am > not convinced new registrations of relevant usage would be allowed > down that route. So if the draft is to attempt to use the INFO > method, it should formally define that method. I am not sure what you are saying is the problem with the draft. The draft does not try to use INFO in a legacy (non-package) manner. It does register an INFO package. Could you clarify the problem that you see? > > 2) The INFO RFC lays down clear instructions for the reviewer of > the INFO package definition before it can be registered. In my view > the current ecrit-ecall document would not pass that review. What is the problem? > > 3) The INFO RFC makes no reference to transfer of data outside > of the INFO method itself. My understanding is that the negotiation > of the Info package within the Info-Package header field set to > 'emergencyCallData.eCall' relates only to the data transferred in > the INFO method using a conformant Info package definition. There > therefore needs to be a discussion about what forms the negotiation > mechanism for other information transferred, for example in the > INVITE request, or other methods of the dialog, if such transfer is > needed, and for it to be clearly documented. The INFO RFC is limited to the INFO method, so wouldn't be expected to discuss transfer of data outside of INFO. The draft references additional-data for data transfer in INVITE. > > 4) As indicated in 3), the INFO RFC does not expect data outside > the Info package itself, and therefore nothing is stated there > about the correlation of data between an application tagging things > onto the methods of the dialog, and the application using the Info > package. The draft has limited scope: it is for emergency calls where the endpoints support the draft (and additional-data, which is a normative reference). So, confirming endpoints would understand data transferred in accordance with the draft and additional-data. > > 5) The INFO RFC allows for multiple Info packages to be used on > the same dialog. There needs to be careful review to ensure that > this capability is not compromised either in regard to the existing > Info packages, or to new ones, particularly in regard to the > assumed correlation between data in the Info package, and data > transferred elsewhere in the dialog. I'd note that the draft would > appear to sanction the inclusion of data in INFO methods belonging > to entirely unrelated Info packages. The draft is not trying to authorize or discuss any other INFO packages or their data. I'll see if I can improve the wording to make this more clear. > I would note that I am beginning to question whether there needs to > be any transfer of data in the INVITE request. Transfer only within > the INFO package after the response to the INVITE request is > exchanged would still meet the 3GPP stage 1 requirements (see > 22.101 release 14), and the whole document would be significantly > simpler. None of the contents of the MSD is used for routeing the > emergency call. This is without going into discussion about whether > transfer using the signalling bearer, or some bearer negotiated > using the SDP, is more appropriate. The draft makes use of additional-data, which carries various data types in the initial INVITE. 3GPP has now agreed to use this for the MSD, in accordance with the draft. However, 3GPP wants the ASN.1 encoding rather than the XML encoding of the MSD used, so this change is being made. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein From nobody Tue Jun 7 18:34:27 2016 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 ED3CB12D8EA for ; Tue, 7 Jun 2016 18:34:23 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfWWeXuJ6iBf for ; Tue, 7 Jun 2016 18:34:22 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC212D94A for ; Tue, 7 Jun 2016 18:34:21 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 7 Jun 2016 18:34:21 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEF7E85@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADEF7E85@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jun 2016 18:34:19 -0700 To: "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecall-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:34:24 -0000 Hi Keith, At 12:48 PM +0000 5/19/16, Keith (Nokia - GB) Drage wrote: > I did another read through of this document last night, and had the > following comments. I have not reviewed the entire document. > > Note that this does not supercede any of the comments made in the > last few days: > > 1) s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and > while there are some similarities, 3GPP emergency call does not > fully comply with either RFC 6443 or RFC 6881. I am also not sure > the references are relevant to the purpose of the draft in any case. In my understanding, 3GPP IMS emergency calls are conformant with these RFCs because the RFCs permit the 3GPP model of a proxy (in the 3GPP case, the E-CSCF) inserting location. 3GPP does not require that the proxy insert location, but does permit it, so in my view there isn't a conflict. > > 2) s. 2, 3rd and 4th para: These paragraphs seem to be going > beyond document scope, and into a wish list. I suggest both these > paragraphs are deleted. The 4th paragraph was added last year at your request. The 3d paragraph permits the document to be used in non-ecall situations (such as the car-crash document for North America), and is identified a permitted but out of scope use. > > 3) s. 3, 4th paragraph: > > An eCall can be either user-initiated or automatically triggered. > Automatically triggered eCalls indicate a car crash or some other > serious incident and carry a greater presumption of risk of injury. > Manually triggered eCalls might be reports of serious hazards and are > likely to require a different response than an automatically > triggered eCall. Manually triggered eCalls are also more likely to > be false (e.g., accidental) calls and so might be subject to > different operational handling by the PSAP. > > The distinction between seriousness and impact of manual versus > automatic is highly subjective, and will depend on the underlying > philosophy of the administration in how it handles what it regards > as false alerts, which differs substantially from administration to > administration. Good point, I will reword this text. > > 4) s. 3, 5th para: > > As part of this work, the European Telecommunications > Standards Institute (ETSI) [SDO-ETSI] has published a Technical > Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] > that presents findings and recommendations regarding support for > eCall in an all-IP environment. > > This somehow implies that the contents of this document are valid > for the interpretation of the draft. Vewry little of the work has > migrated into the stage 1 in 3GPP, and the other groups in 3GPP are > working directly from the stage 1 description, not from the ETSI > work. I'll adjust the wording to make it more clear that the ETSI work is background and informative, and not being used to direct the draft. > > 5) s. 3 last para: > > A transition period will exist during which time the various entities > involved in initiating and handling an eCall might support next- > generation eCall, legacy eCall, or both. This transition period > might last several years or longer. The issue of migration/co- > existence during the transition period is very important but is > outside the scope of this document. The ETSI TR "Mobile Standards > Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in > Clause 7. > > I have not found any statements that support the concept of a > transition in any of the documents I have read. The 3GPP stage 1 > requires both UEs and PSAPs to support both data transfer > mechanisms. By definition there is a transition period, and various 3GPP CRs and DPs and the like mention this concept (e.g., at some point 2G/3G networks will be turned off). The text says that transition issues are out of scope. > > 6) s. 3 general > > Some statement should be made in this section about the need for > the UE and the PSAP to support both mechanisms within SIP, as > required by the stage 1, as the 3GPP emergency network does not > provide any data interworking, only signalling interworking. > Interworking SIP to CS domain, any attached body to a SIP message > will be discarded. That's out of scope of the draft. 3GPP will cover it, as you say above. > > 7) s. 4 reference to 22.101, and s. 18.1. This document carries > no provisions needed to implement this document, and therefore it > should not be a normative reference. Further the reference should > be to release 14 and later. The latest version of all releases of > 3GPP documents are still valid documents for that release. I can make this an informative reference. > > 8) s. 4. Is considerably out of data in regard to the current > version of 22.101. This appears to be a summary of the CS > requirements before the IMS changes were made. In light of the recently approved changes for eCall over IMS, perhaps these can be deleted from this document or less formally summarized. > > 9) s. 6 last para. > > This document registers new service URN children within the "sos" > subservice. These URNs provide the mechanism by which an eCall is > identified, and differentiate between manually and automatically > triggered eCalls (which can be subject to different treatment, > depending on policy). The two service URNs are: > urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual > > The URN does not identify an ecall. It identifies the resource to > which the ecall needs to be directed. To explain further, the sos > URN does not identify an emergency call, it identifies the resource > needed to answer the emergency call, which is why we have a > separate Resource-Priority namespace "esnet". Thanks for the clarification regarding the wording, I'll revise it. > > 10) s.7 > > Europe does not use the term ESInet. That term is North America, > and possibly USA, specific. It might be more appropriate to use > terminology from the ETSI M483 group if this text is needed at all. EENA uses the term, which is why it's mentioned. However, perhaps this section can be replaced with a statement that call routing is out of scope of the draft. > > 11) s.8 > > In regard to test calls, I think some statement should be made > about what they actually test. Using this URN would certainly not > test the emergency call handling capabilities of either the network > or the UE. Does it test all data transfer capabilities (including > the CS). Why do we need a URN rather than just the same number as > is used in the CS domain? The document does not try to mandate the behavior of test calls. I'll make this more clear. > > 12) s.9 > > Future enhancements are desired to enable the PSAP to send other > requests to the vehicle, such as locking or unlocking doors, sounding > the horn, flashing the lights, starting a video stream from on-board > cameras (such as rear focus or blind-spot), etc. > > Do you have a reference for this, or is it speculative thinking? > > I do not think the mechanisms proposed in this draft are suitable > for transferring a video stream, so even if provided, are they part > of ecall, or just part of the standard emergency call. Maybe the > only ecall responsibility is to indicate the existence of these? > > I'd note that extending beyond the existing CS domain capability is > not required at the moment by the 3GPP stage 1. I think we all > acknowledge that all and any data available in the car might be > candidates for transfer to the PSAP, but it is not clear whether > this is part of ecall, or whether it is part of the additional > media beyond voice already available as part of 3GPP emergency > call. Certainly there is a limit on the amount of data that can be > transferred using the mechanisms currently in this draft, beyond > which the QoS of the signalling channel will become inappropriate. No additional data beyond the MSD is currently required nor supported, but there has been discussion in various European eCall-related forums regarding such capabilities. I will look into adding references. Video feeds and other such streaming data would be carried using SIP media streams, not the additional-data mechanisms. > > 13) s.9 & s.13 > > It is not clear to me which elements correspond to the existing MSD > defined by CEN, and which have been defined over the top. Firstly I > think all data that is defined by CEN should carry an appropriate > CEN reference, because the UE needs to support both, and it should > be the same data that is transferred in this. That should occur > either in one of these sections, or in a new separate section. > > Further, if information does go over the top of the existing CEN > definition, this needs additional review and possibly postponement > to a later version, as this is not required by the current 3GPP > stage 1. > > 14) s.14.3 > > A call-back from a PSAP incurs additional risk, > since the current mechanisms are not ideal for verifying that > such a call is indeed a call-back from a PSAP in response to an > emergency call placed by the IVS. See the discussion in > Section 11 and the PSAP Callback document [RFC7090]. > > I do not understand why call-back is being referred to here. Can you explain? A call back from a PSAP could request that the vehicle send an updated MSD. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Majority: That quality that distinguishes a crime from a law. From nobody Tue Jun 7 23:15:18 2016 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 A001E12D7FE for ; Tue, 7 Jun 2016 23:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-Pm2_LipbDD for ; Tue, 7 Jun 2016 23:15:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB1612D7FB for ; Tue, 7 Jun 2016 23:15:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-4b-5757b7f159ba Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.01.18043.1F7B7575; Wed, 8 Jun 2016 08:15:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 08:14:16 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwUz80wpXvugJDU61pgBXsmcAlg== Date: Wed, 8 Jun 2016 06:14:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3546DBFD119FA14C91861C1E7C558D89@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7iu7H7eHhBhufS1g0LnrKarFhy3EW i+/PuxgdmD2WLPnJ5HH31iUmj613HrMEMEdx2aSk5mSWpRbp2yVwZbTef8ZSsIS54uHSw+wN jBeYuhg5OSQETCSWbH7BDGGLSVy4t56ti5GLQ0jgCKPEy7vHmCGcxYwS66ZfB3I4ONgELCS6 /2mDxEUEOhkldl87yQgSFxbIkLjfqQYySEQgV2LfzpuMELaexOrpu1hBbBYBFYmGmadZQGxe ASuJsx/Xgh3BCLT4+6k1YDazgLjErSfzoY4TkFiy5zzUcaISLx//A5sjCjTzy715jBBxRYmd Z9uZIXoNJN6fmw9lW0t0/Z3NDmFrSyxb+JoZYq+gxMmZT1gmMIrOQrJuFpL2WUjaZyFpn4Wk fQEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwJg6uOW31Q7Gg88dDzEKcDAq8fA+cA4P F2JNLCuuzD3EKMHBrCTCu3cLUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU 1ILUIpgsEwenVAMjA3f4etlsw/3977kVw7mYsqo9HwTOWHD3qov0jJdFKq1Xu9ZxBql8yJ3I 7bhEq49tRk+9gP2/tSet0uaypTn+36bgnDN3+pVq3btruzqfGQn0ry6rLeG8Wri7xkbt6USO dSaGn65ISpUnLt49d5vozMTDJkHZ26O7iuqelD96uLvspekL+/lKLMUZiYZazEXFiQBbQPSM pQIAAA== Archived-At: Subject: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 06:15:17 -0000 Hi, =8A >The draft has limited scope: it is for emergency calls where the >endpoints support the draft (and additional-data, which is a >normative reference). So, confirming endpoints would understand data >transferred in accordance with the draft and additional-data. I think it needs to be clear that an endpoint is not mandated to support the additional-data XML schemas etc. Regards, Christer From nobody Wed Jun 8 05:27:59 2016 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 B3EA112D0A9 for ; Wed, 8 Jun 2016 05:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyUtk1jo1xjP for ; Wed, 8 Jun 2016 05:27:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD1F12B03B for ; Wed, 8 Jun 2016 05:27:55 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DAA6A6D15C82A; Wed, 8 Jun 2016 12:27:49 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u58CRrDB004757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 12:27:53 GMT 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 u58CRqGr007917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 14:27:52 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 8 Jun 2016 14:27:33 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRvru1CGX6/X+gHEe7TsYhX7N4gp/aNUKAgAABmQCABFxsAIAA3Oug Date: Wed, 8 Jun 2016 12:27:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> 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.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:27:58 -0000 I have made similar comments to Christer at least a couple of times. Firstly, the only usage of this draft is in 3GPP networks. Noone has identi= fied a use case or a deployment for this draft outside 3GPP. 3GPP has speci= al usages of SIP for emergency calls, which essentially require it to be us= ed via IMS entities. Try and use SIP outside this, and it will not be an em= ergency call in the 3GPP network, and the call will probably fail for roami= ng users. The IMS standards do specify what happens in regard to correlatio= n with the CS domain, and the URNs defined for emergency call usage must ta= ke account of it. The URNs identity the resource to which the call should be routed.=20 For the existing sos URNs, the interworking with the CS domain has no speci= al capabilities and is handled within IMS. The media bearers used for IMS b= ased emergency calls are a superset of those used for CS domain emergency c= all, and therefore there is no disparity in the URN usage. In 3GPP ecall, that resource must be a resource capable of handling both th= e data transfer mechanism specifically designed for IMS, but also the exist= ing data transfer mechanism using a modem based mechanism. There is no inte= rworking point defined for converting one mechnanism to the other, and the = PSAP is expected to handle both (as is the calling UA). Therefore the URNs = must identity a resource that handles both. If transmission fails using the= mechanism defined by this draft (presumably because of interworking) then = the UA and PSAP will drop back to trying to use the existing modem based ap= proach.=20 Therefore the draft that defined the URN must define these semantics for th= e resource addressed. No one is saying you need to write the rest of the story relating to CS dat= a transfer, but the URN definition must encompass it. Regards Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 08 June 2016 01:03 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi Christer, The URNs are registered as child elements of the SOS service URN, so they a= re in no way limited to INFO. At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: > Clarification: the URNs cannot be limited to the INFO mechanism for=20 > transporting MSD. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Christer Holmberg > Sent: 05/06/2016 08:21 > To: Randall Gellens;=20 > ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy=20 > modem to transport MSD > > Hi, > > The draft also defines eCall URNs, and those cannot be limited to SIP. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 05/06/2016 02:49 > To: Christer Holmberg;=20 > ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy=20 > modem to transport MSD > > Hi Christer, > > I think in-band modem is out of scope of the draft. The draft is =20 > limited to SIP signaling aspects. > > --Randy > > At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: > >> Hi, >> >> 3GPP agreed that, when communicating with a PSTN PSAP, it shall be >> possible to transport MSD using a legacy modem on the media plane. The >> reason is for not mandating the network to perform "interworking betwe= en >> MSD transported in INVITE/INFO and MSD transported using a legacy mode= m on >> the media plane". >> >> I don't think the ecall draft needs to consider WHEN the MSD will be >> transported using a legacy modem on the media plane, but I think the d= raft >> should describe the possibility, so that PSAPs are aware of it. >> >> Also, as the same eCall URNs will be used for calls where the MSD is >> transported using a legacy modem on the media plane, the draft must en= able >> usage of the eCall URNs in setup of an IMS emergency call where MSD is >> transported using the legacy modem on the media plane. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >>=20 >> https://www.ietf.org/mai >> lman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- >>From new transmitters came the old stupidities. --Bertolt Brecht -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- True patriotism hates= injustice in its own land more than anywhere else. --Clarence Darrow _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Jun 8 08:54:05 2016 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 9FB6012D772 for ; Wed, 8 Jun 2016 08:54:04 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0a2U1AD1dra for ; Wed, 8 Jun 2016 08:53:55 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 552C812D8BF for ; Wed, 8 Jun 2016 08:53:55 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 08:53:55 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 08:53:52 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:54:04 -0000 Hi Christer, The additional-data document doesn't force UEs to add the structures. It says devices SHOULD add a Device Info block. In NENA's view, it would be helpful if all UEs did so. At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > S > >>The draft has limited scope: it is for emergency calls where the >>endpoints support the draft (and additional-data, which is a >>normative reference). So, confirming endpoints would understand data >>transferred in accordance with the draft and additional-data. > > I think it needs to be clear that an endpoint is not mandated to support > the additional-data XML schemas etc. > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Inside every large problem is a small problem struggling to get out. From nobody Wed Jun 8 08:57:25 2016 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 B290B12D78E for ; Wed, 8 Jun 2016 08:57:23 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkDboe4G8G5x for ; Wed, 8 Jun 2016 08:57:17 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3BA12D0FD for ; Wed, 8 Jun 2016 08:57:17 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 08:57:18 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 08:57:14 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:57:24 -0000 Hi Keith, It seems to me that 3GPP is the entity that should define the semantics, since they define IMS and IMS emergency calls. If you feel that the draft needs to do so, could you send the text you suggest be added to the draft, so we can see it and see if it is in scope for the draft? --Randy At 12:27 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > I have made similar comments to Christer at least a couple of times. > > Firstly, the only usage of this draft is in 3GPP networks. Noone > has identified a use case or a deployment for this draft outside > 3GPP. 3GPP has special usages of SIP for emergency calls, which > essentially require it to be used via IMS entities. Try and use SIP > outside this, and it will not be an emergency call in the 3GPP > network, and the call will probably fail for roaming users. The IMS > standards do specify what happens in regard to correlation with the > CS domain, and the URNs defined for emergency call usage must take > account of it. > > The URNs identity the resource to which the call should be routed. > > For the existing sos URNs, the interworking with the CS domain has > no special capabilities and is handled within IMS. The media > bearers used for IMS based emergency calls are a superset of those > used for CS domain emergency call, and therefore there is no > disparity in the URN usage. > > In 3GPP ecall, that resource must be a resource capable of handling > both the data transfer mechanism specifically designed for IMS, but > also the existing data transfer mechanism using a modem based > mechanism. There is no interworking point defined for converting > one mechnanism to the other, and the PSAP is expected to handle > both (as is the calling UA). Therefore the URNs must identity a > resource that handles both. If transmission fails using the > mechanism defined by this draft (presumably because of > interworking) then the UA and PSAP will drop back to trying to use > the existing modem based approach. > > Therefore the draft that defined the URN must define these > semantics for the resource addressed. > > No one is saying you need to write the rest of the story relating > to CS data transfer, but the URN definition must encompass it. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: 08 June 2016 01:03 > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy > modem to transport MSD > > Hi Christer, > > The URNs are registered as child elements of the SOS service URN, > so they are in no way limited to INFO. > > At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: > >> Clarification: the URNs cannot be limited to the INFO mechanism for >> transporting MSD. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Christer Holmberg >> Sent: 05/06/2016 08:21 >> To: Randall Gellens; >> ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy >> modem to transport MSD >> >> Hi, >> >> The draft also defines eCall URNs, and those cannot be limited to SIP. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 05/06/2016 02:49 >> To: Christer Holmberg; >> ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy >> modem to transport MSD >> >> Hi Christer, >> >> I think in-band modem is out of scope of the draft. The draft is >> limited to SIP signaling aspects. >> >> --Randy >> >> At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> 3GPP agreed that, when communicating with a PSTN PSAP, it shall be > >> possible to transport MSD using a legacy modem on the media plane. The >>> reason is for not mandating the network to perform "interworking between >>> MSD transported in INVITE/INFO and MSD transported using a >>> legacy modem on >>> the media plane". >>> >>> I don't think the ecall draft needs to consider WHEN the MSD will be >>> transported using a legacy modem on the media plane, but I >>> think the draft >>> should describe the possibility, so that PSAPs are aware of it. >>> >>> Also, as the same eCall URNs will be used for calls where the MSD is >>> transported using a legacy modem on the media plane, the draft >>> must enable >>> usage of the eCall URNs in setup of an IMS emergency call where MSD is >>> transported using the legacy modem on the media plane. >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> >>> https://www.ietf.org/mai >>> lman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >>>From new transmitters came the old stupidities. --Bertolt Brecht > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- True > patriotism hates injustice in its own land more than anywhere else. > --Clarence Darrow > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- 37% of Americans agree that while they would hate being British, they wouldn't mind having a British accent. From nobody Wed Jun 8 09:18:55 2016 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 A89A912D5AB for ; Wed, 8 Jun 2016 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJbt547aiNqs for ; Wed, 8 Jun 2016 09:18:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58F212D0F4 for ; Wed, 8 Jun 2016 09:18:52 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-5a-5758456a7237 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 10.0B.12516.A6548575; Wed, 8 Jun 2016 18:18:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 18:18:50 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwZ32HOzFv4dCtU6NlzruujwOTJ/fv6aN Date: Wed, 8 Jun 2016 16:18:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38043C2FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7qG62a0S4wbr9zBaNi56yWmzYcpzF 4vvzLkYHZo8lS34yedy9dYnJY+udxywBzFFcNimpOZllqUX6dglcGY/OWResVa9o+/GcqYHx o2IXIyeHhICJRM+mS+wQtpjEhXvr2boYuTiEBI4wSjxp+sMI4SxmlLhyqpOpi5GDg03AQqL7 nzZIXESgk1Fi97WTjCDdwgK5Ehv3vAKbJCKQJ9F1azEThG0k0f9uLTNIL4uAisTlbRUgYV4B X4mfk08yg9hCAkkSxy9/AxvDCXTQtw8/weKMQAd9P7UGbAyzgLhE05eVrBCHCkgs2XOeGcIW lXj5+B8rRE2+xILNq9kg5gtKnJz5hGUCo/AsJO2zkJTNQlIGETeQ+PL+NpStLbFs4WtmCFtf ovv9aSZk8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAiPq4JbfujsYV792PMQowMGo xMP7wDk8XIg1say4MvcQowQHs5II7yXHiHAh3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOF BNITS1KzU1MLUotgskwcnFINjN4arn9PSJUZ5p4KPSp6z35B+eNZh5scb6zO/6G2V55JVWtN pvC9ndtYlvSzmRusfnF5xjn3Do3Z9xte6QobRG15pfL5smnNpSOS9hfcOL9wiU/81S20+nHL V524hdeUSrg6fx38mMQ3f2rcr1NZppO92+T2MIfzndzhXbXTYve0ebKfFi64wqbEUpyRaKjF XFScCACc3nlqpAIAAA== Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:18:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38043C2FESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, My point was that draft-ecall shall not mandate UEs to support the addition= al-data structures: not explicitly, and not via a normative reference. Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD08/=FD06/=FD2016 18:53 To: Christer Holmberg; Drage, Keith = (Nokia - GB); ecrit@ietf.org Subject: Re: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Hi Christer, The additional-data document doesn't force UEs to add the structures. It says devices SHOULD add a Device Info block. In NENA's view, it would be helpful if all UEs did so. At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > S > >>The draft has limited scope: it is for emergency calls where the >>endpoints support the draft (and additional-data, which is a >>normative reference). So, confirming endpoints would understand data >>transferred in accordance with the draft and additional-data. > > I think it needs to be clear that an endpoint is not mandated to support > the additional-data XML schemas etc. > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Inside every large problem is a small problem struggling to get out. --_000_7594FB04B1934943A5C02806D1A2204B38043C2FESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

My point was that draft-ecall shall not mandate UEs to support the addition= al-data structures: not explicitly, and not via a normative reference.

Regards,

Christer

Sent from my Windows Phone

From: Randall Gellens
Sent: =FD08= /=FD06/=FD2016 18:53
To: Christer Holmberg; Drage, Keith (Nokia - GB); ecrit@ietf.org
Subject: Re: d= raft-ecall: Support of drafft-additional-data [was: Usage of INFO  by = draft-ietf-ecrit-ecall]

Hi Christer,

The additional-data document doesn't force UEs to add the structures.
It says devices SHOULD add a Device Info block.  In NENA's view, it would be helpful if all UEs did so.

At 6:14 AM +0000 6/8/16, Christer Holmberg wrote:

>  Hi,
>
>  S
>
>>The draft has limited scope: it is for emergency calls where the >>endpoints support the draft (and additional-data, which is a
>>normative reference).  So, confirming endpoints would understa= nd data
>>transferred in accordance with the draft and additional-data.
>
>  I think it needs to be clear that an endpoint is not mandated to= support
>  the additional-data XML schemas etc.
>
>  Regards,
>
>  Christer


--
Randall Gellens
Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only
-------------- Randomly selected tag: ---------------
Inside every large problem is a small problem struggling to get out.
--_000_7594FB04B1934943A5C02806D1A2204B38043C2FESESSMB209erics_-- From nobody Wed Jun 8 09:24:21 2016 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 DB11F12D093 for ; Wed, 8 Jun 2016 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyC0adu0vcaI for ; Wed, 8 Jun 2016 09:24:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C98B12D792 for ; Wed, 8 Jun 2016 09:24:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 02F5AFE3D49C; Wed, 8 Jun 2016 16:24:08 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u58GOCe1028816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 16:24:12 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u58GOBLo017940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 18:24:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 8 Jun 2016 18:24:11 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwZ36RbauKouQfEGH2Uj/Hyi+fZ/fuTrA Date: Wed, 8 Jun 2016 16:24:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF11A38@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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:24:19 -0000 What has NENA to do with ecall? Further this draft is not supported directly by 3GPP UEs. (Nothing prevents= its implementation but it is not covered by any 3GPP specifications so wil= l possibly be dropped at SBCs). Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 08 June 2016 16:54 To: Christer Holmberg; Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: Re: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Hi Christer, The additional-data document doesn't force UEs to add the structures.=20 It says devices SHOULD add a Device Info block. In NENA's view, it would b= e helpful if all UEs did so. At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > S > >>The draft has limited scope: it is for emergency calls where the=20 >>endpoints support the draft (and additional-data, which is a normative=20 >>reference). So, confirming endpoints would understand data=20 >>transferred in accordance with the draft and additional-data. > > I think it needs to be clear that an endpoint is not mandated to=20 > support the additional-data XML schemas etc. > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Inside every large pr= oblem is a small problem struggling to get out. From nobody Wed Jun 8 09:24:29 2016 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 78C5512D093 for ; Wed, 8 Jun 2016 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7eEZdrt9TwL for ; Wed, 8 Jun 2016 09:24:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0F612D786 for ; Wed, 8 Jun 2016 09:24:15 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C45C71EAC01F5; Wed, 8 Jun 2016 16:24:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u58GOD95031410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 16:24:14 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u58GODpE021432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 18:24:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 8 Jun 2016 18:24:13 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRwZ56uo3tgfgLq0+6O+wYEYsuE5/fudJg Date: Wed, 8 Jun 2016 16:24:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF11A3F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-l ucent.com> 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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 16:24:21 -0000 Going the direction of 3GPP definition means the draft should remove the UR= Ns entirely and leave their definition and registration to 3GPP. The docume= nt definiting the semantics should be referenced by the IANA registration. In terms of text that we need, my suggestion as a starting point would be s= omething along the lines of: "ecall: This subtype of the sos URN represents a resource that is optimsed = for handling emergency calls carrying ecall data. This URN represents a res= ource that supports both the data transfer mechanisms identified in this dr= aft, and also those defined in 3GPP TS 26.267 [ref]." You will need to work this definition into both 14.1 and into either clause= 6 (area of last paragraph) or clause 7. Note that "ecall" is a subtype in its own right, and will need to defined s= eparately to "manual" and "automatic", which are also subtypes in their own= right. Theorectically, in terms of what you have defined sos.ecall is equa= lly valid as sos.ecall.manual and sos.ecall.automatic. I notice that you will probably also need to register "ecall" as a subtype = of "test.sos" in the IANA definitions. Regards Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 08 June 2016 16:57 To: Drage, Keith (Nokia - GB); Christer Holmberg; ecrit@ietf.org Subject: RE: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi Keith, It seems to me that 3GPP is the entity that should define the semantics, si= nce they define IMS and IMS emergency calls. If you feel that the draft needs to do so, could you send the text you sugg= est be added to the draft, so we can see it and see if it is in scope for t= he draft? --Randy At 12:27 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > I have made similar comments to Christer at least a couple of times. > > Firstly, the only usage of this draft is in 3GPP networks. Noone has=20 > identified a use case or a deployment for this draft outside 3GPP.=20 > 3GPP has special usages of SIP for emergency calls, which essentially=20 > require it to be used via IMS entities. Try and use SIP outside this,=20 > and it will not be an emergency call in the 3GPP network, and the call=20 > will probably fail for roaming users. The IMS standards do specify=20 > what happens in regard to correlation with the CS domain, and the URNs=20 > defined for emergency call usage must take account of it. > > The URNs identity the resource to which the call should be routed. > > For the existing sos URNs, the interworking with the CS domain has no=20 > special capabilities and is handled within IMS. The media bearers used=20 > for IMS based emergency calls are a superset of those used for CS=20 > domain emergency call, and therefore there is no disparity in the URN=20 > usage. > > In 3GPP ecall, that resource must be a resource capable of handling=20 > both the data transfer mechanism specifically designed for IMS, but=20 > also the existing data transfer mechanism using a modem based=20 > mechanism. There is no interworking point defined for converting one=20 > mechnanism to the other, and the PSAP is expected to handle both (as=20 > is the calling UA). Therefore the URNs must identity a resource that=20 > handles both. If transmission fails using the mechanism defined by=20 > this draft (presumably because of > interworking) then the UA and PSAP will drop back to trying to use the=20 > existing modem based approach. > > Therefore the draft that defined the URN must define these semantics=20 > for the resource addressed. > > No one is saying you need to write the rest of the story relating to=20 > CS data transfer, but the URN definition must encompass it. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall=20 > Gellens > Sent: 08 June 2016 01:03 > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy=20 > modem to transport MSD > > Hi Christer, > > The URNs are registered as child elements of the SOS service URN, so=20 > they are in no way limited to INFO. > > At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: > >> Clarification: the URNs cannot be limited to the INFO mechanism for =20 >> transporting MSD. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Christer Holmberg >> Sent: 05/06/2016 08:21 >> To: Randall Gellens; =20 >> ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy =20 >> modem to transport MSD >> >> Hi, >> >> The draft also defines eCall URNs, and those cannot be limited to SIP. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 05/06/2016 02:49 >> To: Christer Holmberg; =20 >> ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy =20 >> modem to transport MSD >> >> Hi Christer, >> >> I think in-band modem is out of scope of the draft. The draft is =20 >> limited to SIP signaling aspects. >> >> --Randy >> >> At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> 3GPP agreed that, when communicating with a PSTN PSAP, it shall=20 >>> be > >> possible to transport MSD using a legacy modem on the media plane.= The >>> reason is for not mandating the network to perform "interworking bet= ween >>> MSD transported in INVITE/INFO and MSD transported using a legacy=20 >>> modem on >>> the media plane". >>> >>> I don't think the ecall draft needs to consider WHEN the MSD will be >>> transported using a legacy modem on the media plane, but I think=20 >>> the draft >>> should describe the possibility, so that PSAPs are aware of it. >>> >>> Also, as the same eCall URNs will be used for calls where the MSD is >>> transported using a legacy modem on the media plane, the draft=20 >>> must enable >>> usage of the eCall URNs in setup of an IMS emergency call where MSD = is >>> transported using the legacy modem on the media plane. >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> >>> =20 >>> https://www.ietf.org/ma >>> i >>> lman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- >>>From new transmitters came the old stupidities. --Bertolt Brecht > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- True patriotism=20 > hates injustice in its own land more than anywhere else. > --Clarence Darrow > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- 37% of Americans agre= e that while they would hate being British, they wouldn't mind having a Bri= tish accent. From nobody Wed Jun 8 10:54:13 2016 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 AAB7112D595 for ; Wed, 8 Jun 2016 10:54:11 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBEUcZzKJ7N1 for ; Wed, 8 Jun 2016 10:54:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF1A12D1A4 for ; Wed, 8 Jun 2016 10:54:10 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 10:54:10 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 10:54:06 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 17:54:11 -0000 Hi Christer, We're not mandating that the UE support any of the additional-data blocks. The normative reference brings in two SHOULDs that apply to the UE, with no MUSTs: - 4.1: "Devices SHOULD use [the Data Provider Information] block to provide identifying information." - 4.3: "[The Device Information block] SHOULD be provided ... by the device itself." At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > My point was that draft-ecall shall not mandate UEs to support the > additional-data structures: not explicitly, and not via a normative > reference. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 08/06/2016 18:53 > To: Christer Holmberg; > Drage, Keith (Nokia - GB); > ecrit@ietf.org > Subject: Re: draft-ecall: Support of drafft-additional-data [was: > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi Christer, > > The additional-data document doesn't force UEs to add the structures. > It says devices SHOULD add a Device Info block. In NENA's view, it > would be helpful if all UEs did so. > > At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> S >> >>>The draft has limited scope: it is for emergency calls where the >>>endpoints support the draft (and additional-data, which is a >>>normative reference). So, confirming endpoints would understand data >>>transferred in accordance with the draft and additional-data. >> >> I think it needs to be clear that an endpoint is not mandated to support >> the additional-data XML schemas etc. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Inside every large problem is a small problem struggling to get out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- New Study of Obesity Looks for Larger Test Group --Newspaper headline From nobody Wed Jun 8 10:55:46 2016 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 DE45312D5C9 for ; Wed, 8 Jun 2016 10:55:44 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCfPX4K90x43 for ; Wed, 8 Jun 2016 10:55:44 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E707212D150 for ; Wed, 8 Jun 2016 10:55:43 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 10:55:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF11A38@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <949EF20990823C4C85C18D59AA11AD8BADF11A38@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 10:55:41 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 17:55:45 -0000 At 4:24 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > What has NENA to do with ecall? NENA has a lot to do with the additional-data draft. > > Further this draft is not supported directly by 3GPP UEs. (Nothing > prevents its implementation but it is not covered by any 3GPP > specifications so will possibly be dropped at SBCs). The mechanisms in the additional-data draft are used in the ecall draft. That does not mandate that UEs support any of the additional-data blocks. > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 08 June 2016 16:54 > To: Christer Holmberg; Drage, Keith (Nokia - GB); ecrit@ietf.org > Subject: Re: draft-ecall: Support of drafft-additional-data [was: > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi Christer, > > The additional-data document doesn't force UEs to add the structures. > It says devices SHOULD add a Device Info block. In NENA's view, it > would be helpful if all UEs did so. > > At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> S >> >>>The draft has limited scope: it is for emergency calls where the >>>endpoints support the draft (and additional-data, which is a normative >>>reference). So, confirming endpoints would understand data >>>transferred in accordance with the draft and additional-data. >> >> I think it needs to be clear that an endpoint is not mandated to >> support the additional-data XML schemas etc. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Inside every > large problem is a small problem struggling to get out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You are wise, witty, and wonderful, but you spend too much time reading this sort of trash. From nobody Wed Jun 8 11:46:48 2016 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 9CB4512B01D for ; Wed, 8 Jun 2016 11:46:47 -0700 (PDT) X-Quarantine-ID: <9Gw-LmpJOY7s> 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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gw-LmpJOY7s for ; Wed, 8 Jun 2016 11:46:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 948A212D0BC for ; Wed, 8 Jun 2016 11:46:45 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 11:46:45 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF11A3F@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF11A3F@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 11:46:42 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:46:47 -0000 Hi Keith, Especially since the car-crash draft references this draft and uses the same URNs (per your request), it might be best to leave the URN registration here, and add text such as "The semantics of these URNs when used with an IMS-based eCall are defined by 3GPP." The draft already registers "ecall" as a child of the "test" service. --Randy At 4:24 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > Going the direction of 3GPP definition means the draft should > remove the URNs entirely and leave their definition and > registration to 3GPP. The document definiting the semantics should > be referenced by the IANA registration. > > In terms of text that we need, my suggestion as a starting point > would be something along the lines of: > > "ecall: This subtype of the sos URN represents a resource that is > optimsed for handling emergency calls carrying ecall data. This URN > represents a resource that supports both the data transfer > mechanisms identified in this draft, and also those defined in 3GPP > TS 26.267 [ref]." > > You will need to work this definition into both 14.1 and into > either clause 6 (area of last paragraph) or clause 7. > > Note that "ecall" is a subtype in its own right, and will need to > defined separately to "manual" and "automatic", which are also > subtypes in their own right. Theorectically, in terms of what you > have defined sos.ecall is equally valid as sos.ecall.manual and > sos.ecall.automatic. > > I notice that you will probably also need to register "ecall" as a > subtype of "test.sos" in the IANA definitions. > > Regards > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 08 June 2016 16:57 > To: Drage, Keith (Nokia - GB); Christer Holmberg; ecrit@ietf.org > Subject: RE: [Ecrit] 3GPP impact on draft-ecall: usage of legacy > modem to transport MSD > > Hi Keith, > > It seems to me that 3GPP is the entity that should define the > semantics, since they define IMS and IMS emergency calls. > > If you feel that the draft needs to do so, could you send the text > you suggest be added to the draft, so we can see it and see if it > is in scope for the draft? > > --Randy > > At 12:27 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > >> I have made similar comments to Christer at least a couple of times. >> >> Firstly, the only usage of this draft is in 3GPP networks. Noone has >> identified a use case or a deployment for this draft outside 3GPP. >> 3GPP has special usages of SIP for emergency calls, which essentially >> require it to be used via IMS entities. Try and use SIP outside this, >> and it will not be an emergency call in the 3GPP network, and the call >> will probably fail for roaming users. The IMS standards do specify >> what happens in regard to correlation with the CS domain, and the URNs >> defined for emergency call usage must take account of it. >> >> The URNs identity the resource to which the call should be routed. >> >> For the existing sos URNs, the interworking with the CS domain has no >> special capabilities and is handled within IMS. The media bearers used >> for IMS based emergency calls are a superset of those used for CS >> domain emergency call, and therefore there is no disparity in the URN >> usage. >> >> In 3GPP ecall, that resource must be a resource capable of handling >> both the data transfer mechanism specifically designed for IMS, but >> also the existing data transfer mechanism using a modem based >> mechanism. There is no interworking point defined for converting one >> mechnanism to the other, and the PSAP is expected to handle both (as >> is the calling UA). Therefore the URNs must identity a resource that >> handles both. If transmission fails using the mechanism defined by >> this draft (presumably because of >> interworking) then the UA and PSAP will drop back to trying to use the > > existing modem based approach. >> >> Therefore the draft that defined the URN must define these semantics >> for the resource addressed. >> >> No one is saying you need to write the rest of the story relating to >> CS data transfer, but the URN definition must encompass it. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall >> Gellens >> Sent: 08 June 2016 01:03 >> To: Christer Holmberg; ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy >> modem to transport MSD >> >> Hi Christer, >> >> The URNs are registered as child elements of the SOS service URN, so >> they are in no way limited to INFO. >> >> At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: >> >>> Clarification: the URNs cannot be limited to the INFO mechanism for >>> transporting MSD. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> >>> From: Christer Holmberg >>> Sent: 05/06/2016 08:21 >>> To: Randall Gellens; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy >>> modem to transport MSD >>> >>> Hi, >>> >>> The draft also defines eCall URNs, and those cannot be limited to SIP. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> >>> From: Randall Gellens >>> Sent: 05/06/2016 02:49 >>> To: Christer Holmberg; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy >>> modem to transport MSD >>> >>> Hi Christer, >>> >>> I think in-band modem is out of scope of the draft. The draft is >>> limited to SIP signaling aspects. >>> >>> --Randy >>> >>> At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> 3GPP agreed that, when communicating with a PSTN PSAP, it shall >>>> be >> >> possible to transport MSD using a legacy modem on the media >> plane. The >>>> reason is for not mandating the network to perform >>>> "interworking between >>>> MSD transported in INVITE/INFO and MSD transported using a legacy >>>> modem on >>>> the media plane". >>>> >>>> I don't think the ecall draft needs to consider WHEN the MSD will be >>>> transported using a legacy modem on the media plane, but I think >>>> the draft >>>> should describe the possibility, so that PSAPs are aware of it. >>>> >>>> Also, as the same eCall URNs will be used for calls where the MSD is >>>> transported using a legacy modem on the media plane, the draft >>>> must enable >>>> usage of the eCall URNs in setup of an IMS emergency call where MSD is >>>> transported using the legacy modem on the media plane. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> >>>> >>>> https://www.ietf.org/ma >>>> i >>>> lman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>>>From new transmitters came the old stupidities. --Bertolt Brecht >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- True patriotism >> hates injustice in its own land more than anywhere else. >> --Clarence Darrow >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- 37% of > Americans agree that while they would hate being British, they > wouldn't mind having a British accent. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Justice is incidental to law and order. --J.Edgar Hoover From nobody Wed Jun 8 12:56:09 2016 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 5151F12D739 for ; Wed, 8 Jun 2016 12:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIXuP7cVNxwD for ; Wed, 8 Jun 2016 12:56:06 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668AD12D619 for ; Wed, 8 Jun 2016 12:56:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-3c-575878542c12 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.69.18043.45878575; Wed, 8 Jun 2016 21:56:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 21:56:03 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwa7D7Dr85MhUuUeVxEBaTcHVq5/f+qPw Date: Wed, 8 Jun 2016 19:56:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdRjekIiLc4OczUYvGRU9ZLTZsOc5i 8f15F6MDs8eSJT+ZPO7eusTksfXOY5YA5igum5TUnMyy1CJ9uwSujDWztzMXPBStmPVtO2MD 43zBLkZODgkBE4mFF7czQ9hiEhfurWfrYuTiEBI4wihxZEc7C4SzmFFi66R9rF2MHBxsAhYS 3f+0QeIiAp2MEruvnWQE6RYWyJM4dPgeE4gtIpAvsfP4QyaQehEBI4kzr/JAwiwCKhLPV11i B7F5BXwlWqatg5p/GWjZipdgCU6gi/7d+ckGYjMCXfT91BqwmcwC4hK3nsxngrhUQGLJnvNQ V4tKvHz8jxXCVpJYe3g7C0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nL LCQtCxhZVjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERs/BLb+tdjAefO54iFGAg1GJh/eB c3i4EGtiWXFl7iFGCQ5mJRHelwUR4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeW pGanphakFsFkmTg4pRoYk71qvjy5mPx+ZfSDSaEuBd+O/oz5cdlBS7RB6Kjp0eYvOo8iD09x mvXhnnFz+5p/Zm121+qTTsmaOf2cNlPsnMILVlH/tXUclY8e23z6oDqjd0VOzZHmi/z9T7bd 2hwmlr++Yvqhzhb1b9KOPutSji18sZ71nPPM0xNit+wPM2kPmNr08B13vhJLcUaioRZzUXEi AChRNuCaAgAA Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 19:56:08 -0000 Hi, >We're not mandating that the UE support any of the additional-data blocks.= The normative reference >brings in two SHOULDs that apply to the UE, with= no MUSTs: > >- 4.1: "Devices SHOULD use [the Data Provider Information] block to provid= e identifying information." >- 4.3: "[The Device Information block] SHOULD be provided ... by the devic= e itself." I don't think we should bring in that, because that would mean support of t= he Data Provider XML schema and the associated MIME type. IF we need to reference draft-additional-data to begin with, it should only= be for the "mechanism" that will be used to carry the ecall information in= the INVITE. We may also need to be a little more clear on what we mean by "mechanism", = but I'll comment more on that (if needed) once I've seen the next version o= f the ecall draft. Regards, Christer At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > My point was that draft-ecall shall not mandate UEs to support the=20 > additional-data structures: not explicitly, and not via a normative=20 > reference. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 08/06/2016 18:53 > To: Christer Holmberg;=20 > Drage, Keith (Nokia - GB);=20 > ecrit@ietf.org > Subject: Re: draft-ecall: Support of drafft-additional-data [was:=20 > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi Christer, > > The additional-data document doesn't force UEs to add the structures. > It says devices SHOULD add a Device Info block. In NENA's view, it =20 > would be helpful if all UEs did so. > > At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> S >> >>>The draft has limited scope: it is for emergency calls where the=20 >>>endpoints support the draft (and additional-data, which is a=20 >>>normative reference). So, confirming endpoints would understand data=20 >>>transferred in accordance with the draft and additional-data. >> >> I think it needs to be clear that an endpoint is not mandated to suppo= rt >> the additional-data XML schemas etc. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Inside every=20 > large problem is a small problem struggling to get out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- New Study of Obesity = Looks for Larger Test Group --Newspaper headline From nobody Wed Jun 8 13:15:35 2016 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 7F96912D790 for ; Wed, 8 Jun 2016 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0dRmQjMDYVm for ; Wed, 8 Jun 2016 13:15:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B150612D53A for ; Wed, 8 Jun 2016 13:15:32 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 989BC2E88A39A; Wed, 8 Jun 2016 20:15:25 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u58KFUCm029776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 20:15:30 GMT 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 u58KFTib016263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 22:15:29 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.147]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 8 Jun 2016 22:15:29 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , Randall Gellens , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwa7K26tAyQPENkGQXDDqGriA5J/f2q2AgAAmKjA= Date: Wed, 8 Jun 2016 20:15:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF11D07@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:15:34 -0000 Can we turn the question around? Can we identify what we still need from additional-data to support ecall? Surely if the coding is now ASN.1 based directly from the CEN document, muc= h disappears, and it would be nice to know what is now left. Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 08 June 2016 20:56 To: Randall Gellens; Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Hi, >We're not mandating that the UE support any of the additional-data blocks.= The normative reference >brings in two SHOULDs that apply to the UE, with= no MUSTs: > >- 4.1: "Devices SHOULD use [the Data Provider Information] block to provid= e identifying information." >- 4.3: "[The Device Information block] SHOULD be provided ... by the devic= e itself." I don't think we should bring in that, because that would mean support of t= he Data Provider XML schema and the associated MIME type. IF we need to reference draft-additional-data to begin with, it should only= be for the "mechanism" that will be used to carry the ecall information in= the INVITE. We may also need to be a little more clear on what we mean by "mechanism", = but I'll comment more on that (if needed) once I've seen the next version o= f the ecall draft. Regards, Christer At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > My point was that draft-ecall shall not mandate UEs to support the=20 > additional-data structures: not explicitly, and not via a normative=20 > reference. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 08/06/2016 18:53 > To: Christer Holmberg;=20 > Drage, Keith (Nokia - GB);=20 > ecrit@ietf.org > Subject: Re: draft-ecall: Support of drafft-additional-data [was:=20 > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi Christer, > > The additional-data document doesn't force UEs to add the structures. > It says devices SHOULD add a Device Info block. In NENA's view, it=20 > would be helpful if all UEs did so. > > At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> S >> >>>The draft has limited scope: it is for emergency calls where the=20 >>>endpoints support the draft (and additional-data, which is a=20 >>>normative reference). So, confirming endpoints would understand data=20 >>>transferred in accordance with the draft and additional-data. >> >> I think it needs to be clear that an endpoint is not mandated to suppo= rt >> the additional-data XML schemas etc. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Inside every=20 > large problem is a small problem struggling to get out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- New Study of Obesity = Looks for Larger Test Group --Newspaper headline From nobody Wed Jun 8 13:24:21 2016 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 A385312D0BD for ; Wed, 8 Jun 2016 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY5J4CPBXdNz for ; Wed, 8 Jun 2016 13:24:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEAE12B00C for ; Wed, 8 Jun 2016 13:24:18 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-22-57587ef03498 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.04.12926.0FE78575; Wed, 8 Jun 2016 22:24:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 22:24:16 +0200 From: Christer Holmberg To: "Drage, Keith (Nokia - GB)" , Randall Gellens , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRwa7D7Dr85MhUuUeVxEBaTcHVq5/f+qPw///leICAACOKAA== Date: Wed, 8 Jun 2016 20:24:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380443A6@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF11D07@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF11D07@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdW/dDXUS4wbYzihaNi56yWmzYcpzF 4vvzLkYHZo8lS34yedy9dYnJY+udxywBzFFcNimpOZllqUX6dglcGS/nvWMveCBbMbupibWB 8b14FyMnh4SAicSlMw2MELaYxIV769m6GLk4hASOMErMWDqPHcJZzCjx/EgLcxcjBwebgIVE 9z9tkAYRgU5GiZtv0kFsYYE8iUOH7zFBxPMldh5/CGU7Sfw9fBuslUVAReLF2QKQMK+Ar0TX yXYWiPGvmCQOd3xhBanhFIiVuDCDBaSGEeie76fWgI1hFhCXuPVkPhPEnQISS/acZ4awRSVe Pv7HCmErSaw9vJ0Fol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYF jCyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQIj5+CW36o7GC+/cTzEKMDBqMTD+8A5PFyI NbGsuDL3EKMEB7OSCG9QVUS4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2amp BalFMFkmDk6pBkbp/W0bMhYwfjtSy9aYcDvkRfblWvsPphv3Hz+tO0v8c0HX22NLZ3HtKbwe GPXQOixq/p2TAo1q4ZKz888/LPHZxK1pWX7Cqou1efFuo88fVzZYnv34+/1d449ZK7/NNfH5 JV3utL9EP3v9HfljvTxnnun+zXkls3lq77nCyMy6xbYqdz5Il/YpsRRnJBpqMRcVJwIAe6uM eJgCAAA= Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:24:20 -0000 Hi, As far as I understand, we need section 6, but I hope some can verify that. Regards, Christer -----Original Message----- From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com]=20 Sent: 08 June 2016 23:15 To: Christer Holmberg ; Randall Gellens ; ecrit@ietf.org Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Can we turn the question around? Can we identify what we still need from additional-data to support ecall? Surely if the coding is now ASN.1 based directly from the CEN document, muc= h disappears, and it would be nice to know what is now left. Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 08 June 2016 20:56 To: Randall Gellens; Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Hi, >We're not mandating that the UE support any of the additional-data blocks.= The normative reference >brings in two SHOULDs that apply to the UE, with= no MUSTs: > >- 4.1: "Devices SHOULD use [the Data Provider Information] block to provid= e identifying information." >- 4.3: "[The Device Information block] SHOULD be provided ... by the devic= e itself." I don't think we should bring in that, because that would mean support of t= he Data Provider XML schema and the associated MIME type. IF we need to reference draft-additional-data to begin with, it should only= be for the "mechanism" that will be used to carry the ecall information in= the INVITE. We may also need to be a little more clear on what we mean by "mechanism", = but I'll comment more on that (if needed) once I've seen the next version o= f the ecall draft. Regards, Christer At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > > My point was that draft-ecall shall not mandate UEs to support the=20 > additional-data structures: not explicitly, and not via a normative=20 > reference. > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 08/06/2016 18:53 > To: Christer Holmberg;=20 > Drage, Keith (Nokia - GB);=20 > ecrit@ietf.org > Subject: Re: draft-ecall: Support of drafft-additional-data [was:=20 > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi Christer, > > The additional-data document doesn't force UEs to add the structures. > It says devices SHOULD add a Device Info block. In NENA's view, it=20 > would be helpful if all UEs did so. > > At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> S >> >>>The draft has limited scope: it is for emergency calls where the=20 >>>endpoints support the draft (and additional-data, which is a=20 >>>normative reference). So, confirming endpoints would understand data=20 >>>transferred in accordance with the draft and additional-data. >> >> I think it needs to be clear that an endpoint is not mandated to suppo= rt >> the additional-data XML schemas etc. >> >> Regards, >> >> Christer > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Inside every=20 > large problem is a small problem struggling to get out. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- New Study of Obesity = Looks for Larger Test Group --Newspaper headline From nobody Wed Jun 8 17:12:48 2016 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 AAB0512D1DC for ; Wed, 8 Jun 2016 17:12:46 -0700 (PDT) X-Quarantine-ID: <2MKuqnUuODEy> 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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MKuqnUuODEy for ; Wed, 8 Jun 2016 17:12:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 700EC12D85B for ; Wed, 8 Jun 2016 17:12:45 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 17:12:46 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 17:12:43 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 00:12:47 -0000 Hi Christer, Since those are SHOULDs instead of MUSTs, it isn't a mandate. A UE implementation can choose to not support those two SHOULDs and still be in compliance. --Randy At 7:56 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > >>We're not mandating that the UE support any of the additional-data >> blocks. The normative reference >brings in two SHOULDs that apply >> to the UE, with no MUSTs: >> >>- 4.1: "Devices SHOULD use [the Data Provider Information] block to >> provide identifying information." >>- 4.3: "[The Device Information block] SHOULD be provided ... by >> the device itself." > > I don't think we should bring in that, because that would mean > support of the Data Provider XML schema and the associated MIME > type. > > IF we need to reference draft-additional-data to begin with, it > should only be for the "mechanism" that will be used to carry the > ecall information in the INVITE. > > We may also need to be a little more clear on what we mean by > "mechanism", but I'll comment more on that (if needed) once I've > seen the next version of the ecall draft. > > Regards, > > Christer > > > > At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> My point was that draft-ecall shall not mandate UEs to support the >> additional-data structures: not explicitly, and not via a normative >> reference. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 08/06/2016 18:53 >> To: Christer Holmberg; >> Drage, Keith (Nokia - GB); >> ecrit@ietf.org >> Subject: Re: draft-ecall: Support of drafft-additional-data [was: >> Usage of INFO by draft-ietf-ecrit-ecall] >> >> Hi Christer, >> >> The additional-data document doesn't force UEs to add the structures. >> It says devices SHOULD add a Device Info block. In NENA's view, it >> would be helpful if all UEs did so. >> >> At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> S >>> >>>>The draft has limited scope: it is for emergency calls where the >>>>endpoints support the draft (and additional-data, which is a >>>>normative reference). So, confirming endpoints would understand data >>>>transferred in accordance with the draft and additional-data. >>> >>> I think it needs to be clear that an endpoint is not mandated to support >>> the additional-data XML schemas etc. >>> >>> Regards, >>> >>> Christer >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- Inside every >> large problem is a small problem struggling to get out. > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- New Study of > Obesity Looks for Larger Test Group --Newspaper headline -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I'm prepared for all emergencies but totally unprepared for everyday life. From nobody Wed Jun 8 17:13:27 2016 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 235C312D863 for ; Wed, 8 Jun 2016 17:13:25 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1F-SFGKhWL8 for ; Wed, 8 Jun 2016 17:13:23 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8459F12D1DC for ; Wed, 8 Jun 2016 17:13:23 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 8 Jun 2016 17:13:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF11D07@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF11D07@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jun 2016 17:13:21 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , Randall Gellens , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 00:13:26 -0000 Hi Keith, I don't see what ASN.1 versus XML has to do with it. --Randy At 8:15 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > Can we turn the question around? > > Can we identify what we still need from additional-data to support ecall? > > Surely if the coding is now ASN.1 based directly from the CEN > document, much disappears, and it would be nice to know what is now > left. > > Keith > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 08 June 2016 20:56 > To: Randall Gellens; Drage, Keith (Nokia - GB); ecrit@ietf.org > Subject: RE: draft-ecall: Support of drafft-additional-data [was: > Usage of INFO by draft-ietf-ecrit-ecall] > > Hi, > >>We're not mandating that the UE support any of the additional-data >> blocks. The normative reference >brings in two SHOULDs that apply >> to the UE, with no MUSTs: >> >>- 4.1: "Devices SHOULD use [the Data Provider Information] block to >> provide identifying information." >>- 4.3: "[The Device Information block] SHOULD be provided ... by >> the device itself." > > I don't think we should bring in that, because that would mean > support of the Data Provider XML schema and the associated MIME > type. > > IF we need to reference draft-additional-data to begin with, it > should only be for the "mechanism" that will be used to carry the > ecall information in the INVITE. > > We may also need to be a little more clear on what we mean by > "mechanism", but I'll comment more on that (if needed) once I've > seen the next version of the ecall draft. > > Regards, > > Christer > > > > At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> My point was that draft-ecall shall not mandate UEs to support the >> additional-data structures: not explicitly, and not via a normative >> reference. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 08/06/2016 18:53 >> To: Christer Holmberg; >> Drage, Keith (Nokia - GB); >> ecrit@ietf.org >> Subject: Re: draft-ecall: Support of drafft-additional-data [was: >> Usage of INFO by draft-ietf-ecrit-ecall] >> >> Hi Christer, >> >> The additional-data document doesn't force UEs to add the structures. >> It says devices SHOULD add a Device Info block. In NENA's view, it >> would be helpful if all UEs did so. >> >> At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> S >>> >>>>The draft has limited scope: it is for emergency calls where the >>>>endpoints support the draft (and additional-data, which is a >>>>normative reference). So, confirming endpoints would understand data >>>>transferred in accordance with the draft and additional-data. >>> >>> I think it needs to be clear that an endpoint is not mandated to support >>> the additional-data XML schemas etc. >>> >>> Regards, >>> >>> Christer >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- Inside every >> large problem is a small problem struggling to get out. > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- New Study of > Obesity Looks for Larger Test Group --Newspaper headline -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One forgets words as one forgets names. One's vocabulary needs constant fertilization or it will die. --Evelyn Waugh From nobody Wed Jun 8 21:46:31 2016 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 160FD12D099 for ; Wed, 8 Jun 2016 21:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1OTN2LuEL9G for ; Wed, 8 Jun 2016 21:46:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8826E12B02A for ; Wed, 8 Jun 2016 21:46:27 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-72-5758f4a1d0a0 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.C9.12926.1A4F8575; Thu, 9 Jun 2016 06:46:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 06:45:29 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] Thread-Index: AQHRweOodlS53smo/UeHUDZ/fIcNG5/gj7bZ Date: Thu, 9 Jun 2016 04:45:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B380446AE@ESESSMB209.ericsson.se> References: , <7594FB04B1934943A5C02806D1A2204B38043C2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B38044293@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B380446AEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7nO7CLxHhBjf26Fo0LnrKarFhy3EW i+/PuxgdmD2WLPnJ5HH31iUmj613HrMEMEdx2aSk5mSWpRbp2yVwZWx9e5Wp4GJ0xbZnF9kb GJf6djFyckgImEjMfN7GBmGLSVy4tx7I5uIQEjjCKLF/wh92CGcxo8TnbXuAMhwcbAIWEt3/ tEHiIgKdjBK7r51kBOkWFsiXeNQ1jwnEFhEokJg2YyILhG0ksWf5WTCbRUBF4tySi2A2r4Cv xNVzs1kgFuxnkjjZO5EVJMEJdNKLaf/ABjECnfT91Bowm1lAXKLpy0pWiFMFJJbsOc8MYYtK vHz8jxXkOGagI9beEoKYLyhxcuYTlgmMwrOQdM9CqJqFpAqixEDiy/vbULa2xLKFr5khbH2J 7venmZDFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKmDW36r7mC8/MbxEKMAB6MS D2/C1IhwIdbEsuLK3EOMEhzMSiK8nneBQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmk J5akZqemFqQWwWSZODilGhi1TwR/Kf9iZvjy3xTbH68T5jyw+fN1+cMq29efuhyVmKJ9P3KZ uEkbvN/WNv/qPpHmjRJsW04IiDvIbeLP12H55Hzu19L+Dtso2yUfVyye/9GvhGOVyCGbTy/D YzltWfOClz4xPaK8cLZF1i3/79lTN+1fz7/K9VmdUYTBKZtdNy/zL7u12OKIEktxRqKhFnNR cSIALNCPt6UCAAA= Archived-At: Subject: Re: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 04:46:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B380446AEESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, The point is not whether it's MUST, SHOULD or MAY - those parts should not = be incorporated into draft-ecall to begin with. Just because you have a normative reference to a spec you can still scope w= hat parts of the spec you incorporate, and I think we need to make that cle= ar. Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD09/=FD06/=FD2016 03:12 To: Christer Holmberg; Drage, Keith = (Nokia - GB); ecrit@ietf.org Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of = INFO by draft-ietf-ecrit-ecall] Hi Christer, Since those are SHOULDs instead of MUSTs, it isn't a mandate. A UE implementation can choose to not support those two SHOULDs and still be in compliance. --Randy At 7:56 PM +0000 6/8/16, Christer Holmberg wrote: > Hi, > >>We're not mandating that the UE support any of the additional-data >> blocks. The normative reference >brings in two SHOULDs that apply >> to the UE, with no MUSTs: >> >>- 4.1: "Devices SHOULD use [the Data Provider Information] block to >> provide identifying information." >>- 4.3: "[The Device Information block] SHOULD be provided ... by >> the device itself." > > I don't think we should bring in that, because that would mean > support of the Data Provider XML schema and the associated MIME > type. > > IF we need to reference draft-additional-data to begin with, it > should only be for the "mechanism" that will be used to carry the > ecall information in the INVITE. > > We may also need to be a little more clear on what we mean by > "mechanism", but I'll comment more on that (if needed) once I've > seen the next version of the ecall draft. > > Regards, > > Christer > > > > At 4:18 PM +0000 6/8/16, Christer Holmberg wrote: > >> Hi, >> >> My point was that draft-ecall shall not mandate UEs to support the >> additional-data structures: not explicitly, and not via a normative >> reference. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 08/06/2016 18:53 >> To: Christer Holmberg; >> Drage, Keith (Nokia - GB); >> ecrit@ietf.org >> Subject: Re: draft-ecall: Support of drafft-additional-data [was: >> Usage of INFO by draft-ietf-ecrit-ecall] >> >> Hi Christer, >> >> The additional-data document doesn't force UEs to add the structures. >> It says devices SHOULD add a Device Info block. In NENA's view, it >> would be helpful if all UEs did so. >> >> At 6:14 AM +0000 6/8/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> S >>> >>>>The draft has limited scope: it is for emergency calls where the >>>>endpoints support the draft (and additional-data, which is a >>>>normative reference). So, confirming endpoints would understand data >>>>transferred in accordance with the draft and additional-data. >>> >>> I think it needs to be clear that an endpoint is not mandated to sup= port >>> the additional-data XML schemas etc. >>> >>> Regards, >>> >>> Christer >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- Inside every >> large problem is a small problem struggling to get out. > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- New Study of > Obesity Looks for Larger Test Group --Newspaper headline -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I'm prepared for all emergencies but totally unprepared for everyday life. --_000_7594FB04B1934943A5C02806D1A2204B380446AEESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

The point is not whether it's MUST, SHOULD or MAY - those parts should not = be incorporated into draft-ecall to begin with.

Just because you have a normative reference to a spec you can still scope w= hat parts of the spec you incorporate, and I think we need to make that cle= ar.

Regards,

Christer

Sent from my Windows Phone

From: Randall Gellens
Sent: =FD09= /=FD06/=FD2016 03:12
To: Christer Holmberg; Drage, Keith (Nokia - GB); ecrit@ietf.org
Subject: RE: d= raft-ecall: Support of drafft-additional-data [was: Usage of   IN= FO  by draft-ietf-ecrit-ecall]

Hi Christer,

Since those are SHOULDs instead of MUSTs, it isn't a mandate.  A UE implementation can choose to not support those two SHOULDs and still
be in compliance.

--Randy

At 7:56 PM +0000 6/8/16, Christer Holmberg wrote:

>  Hi,
>
>>We're not mandating that the UE support any of the additional-data =
>> blocks.  The normative reference >brings in two SHOULDs th= at apply
>> to the UE, with no MUSTs:
>>
>>- 4.1: "Devices SHOULD use [the Data Provider Information] blo= ck to
>> provide identifying information."
>>- 4.3: "[The Device Information block] SHOULD be provided ... = by
>> the device itself."
>
>  I don't think we should bring in that, because that would mean <= br> > support of the Data Provider XML schema and the associated MIME
> type.
>
>  IF we need to reference draft-additional-data to begin with, it =
> should only be for the "mechanism" that will be used to carr= y the
> ecall information in the INVITE.
>
>  We may also need to be a little more clear on what we mean by > "mechanism", but I'll comment more on that (if needed) once = I've
> seen the next version of the ecall draft.
>
>  Regards,
>
>  Christer
>
>
>
>  At 4:18 PM +0000 6/8/16, Christer Holmberg wrote:
>
>>   Hi,
>>
>>   My point was that draft-ecall shall not mandate UEs to= support the
>>  additional-data structures: not explicitly, and not via a no= rmative
>>  reference.
>>
>>   Regards,
>>
>>   Christer
>>
>>   Sent from my Windows Phone
>>
>>   From: <mailto:rg+ietf@randy.pensive.org>Randall Gellens
>>   Sent: 08/06/2016 18:53
>>   To: <mailto:christer.holmberg@ericsson.com>Christer Holmberg;
>>  <mailto:keith.dr= age@nokia.com>Drage, Keith (Nokia - GB);
>>  <mailto:ecrit@ietf.org<= /a>> ecrit@ietf.org
>>   Subject: Re: draft-ecall: Support of drafft-additional= -data [was:
>>  Usage of INFO  by draft-ietf-ecrit-ecall]
>>
>>   Hi Christer,
>>
>>   The additional-data document doesn't force UEs to add = the structures.
>>   It says devices SHOULD add a Device Info block.  = In NENA's view, it
>>  would be helpful if all UEs did so.
>>
>>   At 6:14 AM +0000 6/8/16, Christer Holmberg wrote:<= br> >>
>>>    Hi,
>>>
>>>    S
>>>
>>>>The draft has limited scope: it is for emergency calls wher= e the
>>>>endpoints support the draft (and additional-data, which is = a
>>>>normative reference).  So, confirming endpoints would = understand data
>>>>transferred in accordance with the draft and additional-dat= a.
>>>
>>>    I think it needs to be clear that an endpoin= t is not mandated to support
>>>    the additional-data XML schemas etc.
>>>
>>>    Regards,
>>>
>>>    Christer
>>
>>
>>   --
>>   Randall Gellens
>>   Opinions are personal;    facts are sus= pect;    I speak for myself only
>>   -------------- Randomly selected tag: ---------------&= nbsp; Inside every
>>  large problem is a small problem struggling to get out.
>
>
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect; = ;   I speak for myself only
>  -------------- Randomly selected tag: --------------- New Study = of
> Obesity Looks for Larger Test Group --Newspaper headline


--
Randall Gellens
Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only
-------------- Randomly selected tag: ---------------
I'm prepared for all emergencies but totally unprepared for
everyday life.
--_000_7594FB04B1934943A5C02806D1A2204B380446AEESESSMB209erics_-- From nobody Thu Jun 9 00:25:25 2016 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 78E1E12D518 for ; Thu, 9 Jun 2016 00:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvDvrVX2Xiqf for ; Thu, 9 Jun 2016 00:25:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E60E12D147 for ; Thu, 9 Jun 2016 00:25:15 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-ab-575919d94d64 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.29.27088.9D919575; Thu, 9 Jun 2016 09:25:13 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 09:25:13 +0200 From: Ivo Sedlacek To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD Thread-Index: AQHRvruykG4Q+4X4BE6p21kPXj2GJp/aNUKAgAABmQCABFxtAIABLCzHgAAvUmaAANJbYA== Date: Thu, 9 Jun 2016 07:25:12 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116420D6D@ESESSMB301.ericsson.se> References: , ,<7594FB04B1934943A5C02806D1A22 04B380360BE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3803614C@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF117BD@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF11A3F@FR712WXCHMBA11.zeu.alcatel-l ucent.com> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdVPemZGS4waf7ehaNi56yWmzYcpzF 4vvzLkYHZo8lS34yedy9dYnJY+udxywBzFFcNimpOZllqUX6dglcGaceHWAueOhZcaari7GB 8bplFyMnh4SAicTpc11MELaYxIV769m6GLk4hASOMEp8PfadBcJZzChx6lIrM0gVm4CexMQt R1hBEiIC+xklLjU2gLULC0RKrFzXDtTBAZSIkrjeGQsSFhEIkzh6uZkFxGYRUJFoPfUebA6v gK/E0wNvmCEWTGGR6JzVxwaS4AQ66XHbKbAiRgFZiat/ehlBbGYBcYlbT+ZDnSogsWTPeWYI W1Ti5eN/rCB7JQQUJZb3y0GU60gs2P2JDcLWlli28DXUXkGJkzOfsExgFJ2FZOosJC2zkLTM QtKygJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg9Bzc8ttgB+PL546HGAU4GJV4eBOm RoQLsSaWFVfmHmKU4GBWEuEtZo8MF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEk NTs1tSC1CCbLxMEp1cC4c8dzx1QDB5Eugxcv+pjcDGyvd3/IXNq9TYvr2mWfzrq054LNHWzG 0XNu71wxvTzy+GLpmt4ap5hdTavPzzq+LUZ7e65jvvrCuY5ff/e7bSlO8ODsq+eYZBrJNt/o hMdn8x6nshdhSoUfXlepbvo4jZF1noPZn+AdHue0j5+KedfhHzItUECJpTgj0VCLuag4EQCT xqAxmgIAAA== Archived-At: Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to transport MSD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:25:23 -0000 Hello, IMO, it does not make sense to have a part of the URN definition in the dra= ft and rest in 3GPP TSs.=20 I would like to see a text going in direction proposed by Keith. Kind regards Ivo Sedlacek -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Wednesday, June 08, 2016 8:47 PM To: Drage, Keith (Nokia - GB); Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy modem to t= ransport MSD Hi Keith, Especially since the car-crash draft references this draft and uses the sam= e URNs (per your request), it might be best to leave the URN registration h= ere, and add text such as "The semantics of these URNs when used with an IM= S-based eCall are defined by 3GPP." The draft already registers "ecall" as a child of the "test" service. --Randy At 4:24 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > Going the direction of 3GPP definition means the draft should remove=20 > the URNs entirely and leave their definition and registration to 3GPP.=20 > The document definiting the semantics should be referenced by the IANA=20 > registration. > > In terms of text that we need, my suggestion as a starting point=20 > would be something along the lines of: > > "ecall: This subtype of the sos URN represents a resource that is=20 > optimsed for handling emergency calls carrying ecall data. This URN=20 > represents a resource that supports both the data transfer mechanisms=20 > identified in this draft, and also those defined in 3GPP TS 26.267=20 > [ref]." > > You will need to work this definition into both 14.1 and into either=20 > clause 6 (area of last paragraph) or clause 7. > > Note that "ecall" is a subtype in its own right, and will need to=20 > defined separately to "manual" and "automatic", which are also=20 > subtypes in their own right. Theorectically, in terms of what you have=20 > defined sos.ecall is equally valid as sos.ecall.manual and=20 > sos.ecall.automatic. > > I notice that you will probably also need to register "ecall" as a=20 > subtype of "test.sos" in the IANA definitions. > > Regards > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 08 June 2016 16:57 > To: Drage, Keith (Nokia - GB); Christer Holmberg; ecrit@ietf.org > Subject: RE: [Ecrit] 3GPP impact on draft-ecall: usage of legacy=20 > modem to transport MSD > > Hi Keith, > > It seems to me that 3GPP is the entity that should define the=20 > semantics, since they define IMS and IMS emergency calls. > > If you feel that the draft needs to do so, could you send the text=20 > you suggest be added to the draft, so we can see it and see if it is=20 > in scope for the draft? > > --Randy > > At 12:27 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote: > >> I have made similar comments to Christer at least a couple of times. >> >> Firstly, the only usage of this draft is in 3GPP networks. Noone=20 >> has identified a use case or a deployment for this draft outside 3GPP. >> 3GPP has special usages of SIP for emergency calls, which=20 >> essentially require it to be used via IMS entities. Try and use SIP=20 >> outside this, and it will not be an emergency call in the 3GPP=20 >> network, and the call will probably fail for roaming users. The IMS=20 >> standards do specify what happens in regard to correlation with the=20 >> CS domain, and the URNs defined for emergency call usage must take acco= unt of it. >> >> The URNs identity the resource to which the call should be routed. >> >> For the existing sos URNs, the interworking with the CS domain has=20 >> no special capabilities and is handled within IMS. The media bearers=20 >> used for IMS based emergency calls are a superset of those used for=20 >> CS domain emergency call, and therefore there is no disparity in the=20 >> URN usage. >> >> In 3GPP ecall, that resource must be a resource capable of handling =20 >> both the data transfer mechanism specifically designed for IMS, but =20 >> also the existing data transfer mechanism using a modem based =20 >> mechanism. There is no interworking point defined for converting one =20 >> mechnanism to the other, and the PSAP is expected to handle both (as =20 >> is the calling UA). Therefore the URNs must identity a resource that =20 >> handles both. If transmission fails using the mechanism defined by =20 >> this draft (presumably because of >> interworking) then the UA and PSAP will drop back to trying to use=20 >> the > > existing modem based approach. >> >> Therefore the draft that defined the URN must define these=20 >> semantics for the resource addressed. >> >> No one is saying you need to write the rest of the story relating=20 >> to CS data transfer, but the URN definition must encompass it. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall =20 >> Gellens >> Sent: 08 June 2016 01:03 >> To: Christer Holmberg; ecrit@ietf.org >> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy =20 >> modem to transport MSD >> >> Hi Christer, >> >> The URNs are registered as child elements of the SOS service URN,=20 >> so they are in no way limited to INFO. >> >> At 5:27 AM +0000 6/5/16, Christer Holmberg wrote: >> >>> Clarification: the URNs cannot be limited to the INFO mechanism=20 >>> for transporting MSD. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> >>> From: Christer Holmberg >>> Sent: 05/06/2016 08:21 >>> To: Randall Gellens; =20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy =20 >>> modem to transport MSD >>> >>> Hi, >>> >>> The draft also defines eCall URNs, and those cannot be limited to SI= P. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> >>> From: Randall Gellens >>> Sent: 05/06/2016 02:49 >>> To: Christer Holmberg; =20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] 3GPP impact on draft-ecall: usage of legacy =20 >>> modem to transport MSD >>> >>> Hi Christer, >>> >>> I think in-band modem is out of scope of the draft. The draft is =20 >>> limited to SIP signaling aspects. >>> >>> --Randy >>> >>> At 11:35 AM +0000 6/3/16, Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> 3GPP agreed that, when communicating with a PSTN PSAP, it shall =20 >>>> be >> >> possible to transport MSD using a legacy modem on the media=20 >> plane. The >>>> reason is for not mandating the network to perform=20 >>>> "interworking between >>>> MSD transported in INVITE/INFO and MSD transported using a=20 >>>> legacy modem on >>>> the media plane". >>>> >>>> I don't think the ecall draft needs to consider WHEN the MSD will = be >>>> transported using a legacy modem on the media plane, but I=20 >>>> think the draft >>>> should describe the possibility, so that PSAPs are aware of it. >>>> >>>> Also, as the same eCall URNs will be used for calls where the MSD = is >>>> transported using a legacy modem on the media plane, the draft =20 >>>> must enable >>>> usage of the eCall URNs in setup of an IMS emergency call where MS= D is >>>> transported using the legacy modem on the media plane. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> >>>>=20 >>>> =20 >>>> https://www.ietf.org/m >>>> a >>>> i >>>> lman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself o= nly >>> -------------- Randomly selected tag: --------------- >>>>From new transmitters came the old stupidities. --Bertolt Brecht >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- True=20 >> patriotism hates injustice in its own land more than anywhere else. >> --Clarence Darrow >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- 37% of=20 > Americans agree that while they would hate being British, they=20 > wouldn't mind having a British accent. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Justice is incidental= to law and order. --J.Edgar Hoover _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Jun 9 23:48:30 2016 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 5721E12D94A for ; Thu, 9 Jun 2016 23:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZtF48GrtsWe for ; Thu, 9 Jun 2016 23:48:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B9912D529 for ; Thu, 9 Jun 2016 23:48:25 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-1f-575a62b7da6f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.81.27088.7B26A575; Fri, 10 Jun 2016 08:48:23 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 08:48:23 +0200 From: Ivo Sedlacek To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall Thread-Index: AQHRwSIM91Y/LnM8cEqXqOQ/4TgTPZ/iQtgg Date: Fri, 10 Jun 2016 06:48:22 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116421717@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-l ucent.com> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610116421717ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7ou72pKhwgwsX9SwaFz1ltdiw5TiL xffnXYwOzB5Llvxk8rh76xKTx9Y7j1kCmKO4bFJSczLLUov07RK4Mg5dmMZcsKeDsWJJXz9T A+OMki5GTg4JAROJWWumsEPYYhIX7q1n62Lk4hASOMIo8WFLP5SzhFGi/8gyVpAqNgE9iYlb jrCCJEQEOhkldl87yQiSEBawkWiauxKogwMoYSuxfqEkSFhEwEji7fduJhCbRUBVov/7PTYQ m1fAV+LK10XMEAvaGSUmnn3PCNLLCXTSm83iIDWMArISV//0go1nFhCXuPVkPhPEpQISS/ac Z4awRSVePv7HCmErSrQ/bYCqz5c49LCHBWKXoMTJmU9YJjCKzEIyahaSsllIyiDiOhILdn9i g7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMB4O7jlt8EO xpfPHQ8xCnAwKvHwPngWGS7EmlhWXJl7iFGCg1lJhFcsMCpciDclsbIqtSg/vqg0J7X4EKM0 B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA+OaS9O3rBJ7qijJeIPVWmlB1/RGwfMz124q OP9qne+e9M3TBWXbCnXfF6i/0tkeUr1rqUbw6q7sqTf+6bEHlfUo/mmfpfPJ71W45Z8jqRHL ndaHLT7wbd6Ca9rLk5amfLt/6mzoW0nnCM9ppXveaXks11ueEvLx2MnJ/XXrdF5N3up0aILZ qu/hSizFGYmGWsxFxYkA+kQpn7MCAAA= Archived-At: Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 06:48:28 -0000 --_000_39B5E4D390E9BD4890E2B3107900610116421717ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, > > 1) Any usage of the INFO method requires a full Info package > > definition. While there are various mentions of legacy usage, the > > draft is not trying to follow that direction, and in any case I am not > > convinced new registrations of relevant usage would be allowed down > > that route. So if the draft is to attempt to use the INFO method, it > > should formally define that method. > > I am not sure what you are saying is the problem with the draft. The > draft does not try to use INFO in a legacy (non-package) manner. It > does register an INFO package. Could you clarify the problem that you s= ee? In order to define and register an info package in IANA, a filled-in templa= te for info package definition described in RFC6086 section 10 needs to be = provided. According to RFC6086 section 10, the template consisting of: ------------- 10.2. Overall Description 10.3. Applicability 10.4. Info Package Name 10.5. Info Package Parameters 10.6. SIP Option-Tags 10.7. INFO Message Body Parts 10.8. Info Package Usage Restrictions 10.9. Rate of INFO Requests 10.10. Info Package Security Considerations 10.11. Implementation Details 10.12. Examples ------------- The draft can say e.g. the following. I am not expert on ecrit eCall draft = so text might need updates - feel free to update it according to the draft. ------------- 1. Overall Description The [I-D.ietf-ecrit-eCall] defines an NG-eCall protocol enabling a PSAP to = obtain a minimal set of data (MSD) from a UA located in a vehicle. The prot= ocol makes use of SIP INFO requests associated with the emergencyCallData.e= Call info package to transport NG-eCall messages. NG-eCall messages are: - request for MSD - acknowledgement of reception of request for MSD - MSD - acknowledgement of reception of MSD - ... 2. Applicability A number of solutions were discussed for the transportation of NG-eCall mes= sages between the UA and the PSAP. The solutions were: 1) use of subscription to an event package; 2) use of the session related methods (e.g. SIP 200 (OK) respons= e to the SIP INVITE request); 3) use of the SIP MESSAGE method; 4) use of media plane mechanisms; and 5) use of the SIP INFO method as described in IETF RFC 6086, by = defining a new info package. Furthermore, each of the solutions 1), 2), 3), 4) and 5) were evaluated. The use of an event package was discounted as the usage of subscribe/notify= mechanism for two-way communication is not appropriate since subscribe/not= ify mechanism is to provide one-way communication consisting of notificatio= ns from notifier to subscriber indicating that certain events in notifier h= ave occurred. The use of session related methods for messages other than the initial MSD = was discounted as it was concluded that usage of UPDATE method for transpor= t of USSD message would have side effect of impacting dialog configuration = (e.g. possibly changing the remote contact URI). Use of the SIP MESSAGE method was discounted since NG-eCall protocol is dia= log based and all NG-eCall messages has to be part of the related session. Use of the media plane mechanisms was discounted because the amount of NG-e= Call messages in a dialog is normally very small (normally only ????) and o= verhead caused by user plane setup (e.g. if MSRP is used as transport) woul= d be disproportionately big in comparion to the actual NG-eCall message siz= e. Based on the above analyses, the SIP INFO method was chosen to transport th= e NG-eCall message between the UA and the PSAP. 3. Info Package Name The info package name is emergencyCallData.eCall. 4. Info Package Parameters None defined. 5. SIP Option-Tags None defined. 6. INFO Message Body Parts The INFO request carries: 1) an application/EmergencyCallData:eCall-control+xml MIME body; or 2) an application/EmergencyCallData:eCall-control+xml MIME body part and an= application/emergencyCallData.eCall.MSD MIME body part. 7. Info Package Usage Restrictions None defined. 8. Rate of INFO Requests Maximum rate of SIP INFO requests associated with emergencyCallData.eCall i= nfo package is ...... 9. Info Package Security Considerations The security is based on the generic security mechanism provided for the un= derlying SIP signalling. No additional security mechanism is defined. 10. Implementation Details The [I-D.ietf-ecrit-eCall] describes the NG-eCall protocol details. 11. Examples The [I-D.ietf-ecrit-eCall] gives the NG-eCall protocol examples. ------------- Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610116421717ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

>  >  1)   Any usage of= the INFO method requires a full Info package

>  > definition. While there are vario= us mentions of legacy usage, the

> > draft is not trying to follow that dire= ction, and in any case I am not

> > convinced new registrations of relevant= usage would be allowed down 

> > that route. So if the draft is to attem= pt to use the INFO method, it 

> > should formally define that method.

> 

>  I am not sure what you are saying is t= he problem with the draft.  The

> draft  does not try to use INFO in a le= gacy (non-package) manner.  It

> does register  an INFO package.  C= ould you clarify the problem that you see?

 

In order to define and register an info package i= n IANA, a filled-in template for info package definition described in RFC60= 86 section 10 needs to be provided.

 

According to RFC6086 section 10, the template con= sisting of:

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

      10.2. Overall Desc= ription

      10.3. Applicabilit= y

      10.4. Info Package= Name

      10.5. Info Package= Parameters

      10.6. SIP Option-T= ags

      10.7. INFO Message= Body Parts

      10.8. Info Package= Usage Restrictions

      10.9. Rate of INFO= Requests

      10.10. Info Packag= e Security Considerations

      10.11. Implementat= ion Details

      10.12. Examples

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

 

The draft can say e.g. the following. I am not ex= pert on ecrit eCall draft so text might need updates - feel free to update = it according to the draft.

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

1. Overall Description

 

The [I-D.ietf-ecrit-eCall] defines an NG-eCall pr= otocol enabling a PSAP to obtain a minimal set of data (MSD) from a UA loca= ted in a vehicle. The protocol makes use of SIP INFO requests associated wi= th the emergencyCallData.eCall info package to transport NG-eCall messages.

 

NG-eCall messages are:

- request for MSD

- acknowledgement of reception of request for MSD=

- MSD

- acknowledgement of reception of MSD<= /p>

- ...

 

2. Applicability

 

A number of solutions were discussed for the tran= sportation of NG-eCall messages between the UA and the PSAP. The solutions = were:

1)        = ;    use of subscription to an event package;

2)        = ;    use of the session related methods (e.g. SIP 200 (OK) r= esponse to the SIP INVITE request);

3)        = ;    use of the SIP MESSAGE method;

4)        = ;    use of media plane mechanisms; and

5)        = ;    use of the SIP INFO method as described in IETF RFC 608= 6, by defining a new info package.

 

Furthermore, each of the solutions 1), 2), 3), 4)= and 5) were evaluated.

 

The use of an event package was discounted as the= usage of subscribe/notify mechanism for two-way communication is not appro= priate since subscribe/notify mechanism is to provide one-way communication= consisting of notifications from notifier to subscriber indicating that certain events in notifier have occ= urred.

 

The use of session related methods for messages o= ther than the initial MSD was discounted as it was concluded that usage of = UPDATE method for transport of USSD message would have side effect of impac= ting dialog configuration (e.g. possibly changing the remote contact URI).

 

Use of the SIP MESSAGE method was discounted sinc= e NG-eCall protocol is dialog based and all NG-eCall messages has to be par= t of the related session.

 

Use of the media plane mechanisms was discounted = because the amount of NG-eCall messages in a dialog is normally very small = (normally only ????) and overhead caused by user plane setup (e.g. if MSRP = is used as transport) would be disproportionately big in comparion to the actual NG-eCall message size.

 

Based on the above analyses, the SIP INFO method = was chosen to transport the NG-eCall message between the UA and the PSAP.

 

3. Info Package Name

 

The info package name is emergencyCallData.eCall.=

 

4. Info Package Parameters

 

None defined.

 

5. SIP Option-Tags

 

None defined.

 

6. INFO Message Body Parts

 

The INFO request carries:

1) an application/EmergencyCallData:eCall-control= +xml MIME body; or

2) an application/EmergencyCallData:eCall-control= +xml MIME body part and an application/emergencyCallData.eCall.MSD MIME= body part.

 

7. Info Package Usage Restrictions

 

None defined.

 

8. Rate of INFO Requests

 

Maximum rate of SIP INFO requests associated with= emergencyCallData.eCall info package is ......

 

9. Info Package Security Considerations

 

The security is based on the generic security mec= hanism provided for the underlying SIP signalling. No additional security m= echanism is defined.

 

10. Implementation Details

 

The [I-D.ietf-ecrit-eCall] describes the NG-eCall= protocol details.

 

11. Examples

 

The [I-D.ietf-ecrit-eCall] gives the NG-eCall pro= tocol examples.

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

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B3107900610116421717ESESSMB301erics_-- From nobody Fri Jun 10 04:48:05 2016 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 2A44B12D907 for ; Fri, 10 Jun 2016 04:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLCAEkAkO7o6 for ; Fri, 10 Jun 2016 04:47:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C431912B069 for ; Fri, 10 Jun 2016 04:47:45 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-11-575aa8dfafb7 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.DF.12926.FD8AA575; Fri, 10 Jun 2016 13:47:43 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 13:47:43 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ecall: Features not required by 3GPP and CEN Thread-Index: AdHDCkmlAyBjq5XgQ02ipGTIrwmtRQ== Date: Fri, 10 Jun 2016 11:47:42 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116421BB3@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610116421BB3ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2J7uO79FVHhBrde61k0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJZ3HcwFCx0qen+/YGxgPG/excjJISFgIvFz7yYmCFtM4sK9 9WxdjFwcQgJHGCW+PtvIDOEsYZRYe+oOG0gVm4CexMQtR1hBbBEBVYkNZ1YygtjCAs4SOzqn AdVwAMU9JNb2xECU6Ems2LwErJwFqPzE0lNgy3gFfCUa5+wDa2UUkJW4+qcXzGYWEJe49WQ+ 1EECEkv2nGeGsEUlXj7+xwphK0k0LnnCClGfL3HhywtWiJmCEidnPmGZwCg0C8moWUjKZiEp g4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYx AmPi4JbfqjsYL79xPMQowMGoxMP74FlkuBBrYllxZe4hRgkOZiUR3rVLo8KFeFMSK6tSi/Lj i0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MPJ2c4fyO1y0mS715V9ID99x 1htT8651LPLp+PJRpfaW2KN6n/g9UmbXZm3ffLLRqyPyvJuxRNrFibe1j2S9ZjGIkrpV4RyV qXS5OPm7/oyFM8KOzPqwtGR137+tCQGxDfd/vbY78MlpSnDfk9Idd1RenlIKjFpfmmGsLbHh /PxTuxljhfw47ZVYijMSDbWYi4oTAf7w91SFAgAA Archived-At: Subject: [Ecrit] draft-ecall: Features not required by 3GPP and CEN X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:47:52 -0000 --_000_39B5E4D390E9BD4890E2B3107900610116421BB3ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, ISSUE: 3GPP SA1 decided that eCall over IMS is required to solely tranfer MSD - se= e http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1= -162764.zip stating: -------------- SA1 service requirements for eCall over IMS only consider emergency call an= d transfer of the MSD (which shall not exceed 140 bytes) as defined by CEN = as the services to support. -------------- According to section 2 of the draft, the scope of the draft is supposed to = be limited to 3GPP and CEN scope: -------------- 2. Document Scope This document is limited to the signaling, data exchange, and protocol needs of next-generation eCall (NG-eCall, also referred to as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP framework for emergency calls, as described in [RFC6443] and [RFC6881]. >>eCall itself is specified by 3GPP and CEN<< and these specifications include far greater scope than is covered here. -------------- However, the draft content goes beyond it own scope since it e.g. defines t= he following actions: ------------- o Play and/or display static (pre-defined) message o Speak/display dynamic text (text supplied in action) o Flash or turn on or off a lamp (light) o Honk horn o Enable a camera ------------- PROPOSAL: Move text going beyond 3GPP and CEN requirements into anoth= er document. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610116421BB3ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

ISSUE:

 

3GPP SA1 decided that eCall over IMS is required = to solely tranfer MSD - see http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-= CN1/TSGC1_98_Osaka/docs/C1-162764.zip stating:

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

SA1 service requirements for eCall over IMS only = consider emergency call and transfer of the MSD (which shall not exceed 140= bytes) as defined by CEN as the services to support.

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

 

According to section 2 of the draft, the scope of= the draft is supposed to be limited to 3GPP and CEN scope:

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

2.  Document Scope

 

   This document is limited to the sign= aling, data exchange, and

   protocol needs of next-generation eC= all (NG-eCall, also referred to

   as packet-switched eCall (PS-eCall) = and all-IP eCall) within the SIP

   framework for emergency calls, as de= scribed in [RFC6443] and

   [RFC6881].  >>eCall itsel= f is specified by 3GPP and CEN<< and these

   specifications include far greater s= cope than is covered here.

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

 

However, the draft content goes beyond it own sco= pe since it e.g. defines the following actions:

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

   o  Play and/or display static (= pre-defined) message

   o  Speak/display dynamic text (= text supplied in action)

   o  Flash or turn on or off a la= mp (light)

   o  Honk horn

   o  Enable a camera

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

 

PROPOSAL:

 

        &= nbsp;       Move text going beyond 3GPP and C= EN requirements into another document.

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B3107900610116421BB3ESESSMB301erics_-- From nobody Wed Jun 15 07:58:38 2016 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 99EDF12D7A0 for ; Wed, 15 Jun 2016 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCFbfbQ4nuB1 for ; Wed, 15 Jun 2016 07:58:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CFAE12D77C for ; Wed, 15 Jun 2016 07:58:23 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-6d-57616d0de410 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.57.27088.D0D61675; Wed, 15 Jun 2016 16:58:21 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.113]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 16:58:20 +0200 From: Ivo Sedlacek To: Ivo Sedlacek , Randall Gellens , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall Thread-Index: AQHRwSIM91Y/LnM8cEqXqOQ/4TgTPZ/iQtgggABJPSA= Date: Wed, 15 Jun 2016 14:58:20 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116423FD4@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <39B5E4D390E9BD4890E2B3107900610116421717@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610116421717@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610116423FD4ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7li5vbmK4wZGvChaNi56yWmzYcpzF 4vvzLkYHZo8lS34yedy9dYnJY+udxywBzFFcNimpOZllqUX6dglcGQfP6xVMWs5YcevEccYG xjn9jF2MnBwSAiYSv9ZcYoOwxSQu3FsPZHNxCAkcYZSYdvc4M4SzhFHiR8MedpAqNgE9iYlb jrCCJEQEtjJKdL39B5YQFrCRaJq7EqidAyhhK7F+oSRIWETASmLThG1gJSwCqhJTv+1hArF5 BXwlNk9+BbXgNKNE2+/vLCAJTgE/iR1bDoOdxCggK3H1Ty/YqcwC4hK3nsxngjhVQGLJnvPM ELaoxMvH/1ghbEWJq9OXM4HcwCyQL7F2DyvELkGJkzOfsExgFJmFZNIshKpZSKogSnQkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB0XZwy2+D HYwvnzseYhTgYFTi4VVwSwgXYk0sK67MPcQowcGsJMK7PT0xXIg3JbGyKrUoP76oNCe1+BCj NAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVANjWPMWixate9tO3jdPPneS163My/f/i69S bzY2d/XemSGwo8srU/FsrNSrMtVAYfZbbpa//1YZZCfoR3/IO7igwWHGWfegG7MeTT0c3Jqv vjd+1vS/0V/3RK+9Uc244m/zJasQM76fTFXc11y/Psq4rrTEWeSuXc/l7SGJO51sdHp3ZBxd 9tpEiaU4I9FQi7moOBEAp8zE8LICAAA= Archived-At: Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:58:26 -0000 --_000_39B5E4D390E9BD4890E2B3107900610116423FD4ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I got some offline comments on text below of section 6 of the template so p= lease see below updated text. Kind regards Ivo Sedlacek From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Friday, June 10, 2016 8:48 AM To: Randall Gellens; Drage, Keith (Nokia - GB); ecrit@ietf.org Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall Hello, > > 1) Any usage of the INFO method requires a full Info package > > definition. While there are various mentions of legacy usage, the > > draft is not trying to follow that direction, and in any case I am not > > convinced new registrations of relevant usage would be allowed down > > that route. So if the draft is to attempt to use the INFO method, it > > should formally define that method. > > I am not sure what you are saying is the problem with the draft. The > draft does not try to use INFO in a legacy (non-package) manner. It > does register an INFO package. Could you clarify the problem that you s= ee? In order to define and register an info package in IANA, a filled-in templa= te for info package definition described in RFC6086 section 10 needs to be = provided. According to RFC6086 section 10, the template consisting of: ------------- 10.2. Overall Description 10.3. Applicability 10.4. Info Package Name 10.5. Info Package Parameters 10.6. SIP Option-Tags 10.7. INFO Message Body Parts 10.8. Info Package Usage Restrictions 10.9. Rate of INFO Requests 10.10. Info Package Security Considerations 10.11. Implementation Details 10.12. Examples ------------- The draft can say e.g. the following. I am not expert on ecrit eCall draft = so text might need updates - feel free to update it according to the draft. ------------- 1. Overall Description The [I-D.ietf-ecrit-eCall] defines an NG-eCall protocol enabling a PSAP to = obtain a minimal set of data (MSD) from a UA located in a vehicle. The prot= ocol makes use of SIP INFO requests associated with the emergencyCallData.e= Call info package to transport NG-eCall messages. NG-eCall messages are: - request for MSD - acknowledgement of reception of request for MSD - MSD - acknowledgement of reception of MSD - ... 2. Applicability A number of solutions were discussed for the transportation of NG-eCall mes= sages between the UA and the PSAP. The solutions were: 1) use of subscription to an event package; 2) use of the session related methods (e.g. SIP 200 (OK) respons= e to the SIP INVITE request); 3) use of the SIP MESSAGE method; 4) use of media plane mechanisms; and 5) use of the SIP INFO method as described in IETF RFC 6086, by = defining a new info package. Furthermore, each of the solutions 1), 2), 3), 4) and 5) were evaluated. The use of an event package was discounted as the usage of subscribe/notify= mechanism for two-way communication is not appropriate since subscribe/not= ify mechanism is to provide one-way communication consisting of notificatio= ns from notifier to subscriber indicating that certain events in notifier h= ave occurred. The use of session related methods for messages other than the initial MSD = was discounted as it was concluded that usage of UPDATE method for transpor= t of USSD message would have side effect of impacting dialog configuration = (e.g. possibly changing the remote contact URI). Use of the SIP MESSAGE method was discounted since NG-eCall protocol is dia= log based and all NG-eCall messages has to be part of the related session. Use of the media plane mechanisms was discounted because the amount of NG-e= Call messages in a dialog is normally very small (normally only ????) and o= verhead caused by user plane setup (e.g. if MSRP is used as transport) woul= d be disproportionately big in comparion to the actual NG-eCall message siz= e. Based on the above analyses, the SIP INFO method was chosen to transport th= e NG-eCall message between the UA and the PSAP. 3. Info Package Name The info package name is emergencyCallData.eCall. 4. Info Package Parameters None defined. 5. SIP Option-Tags None defined. 6. INFO Message Body Parts application/EmergencyCallData:eCall-control+xml message body parts and appl= ication/emergencyCallData.eCall.MSD message body parts carried in SIP INFO = requests are associated with the emergencyCallData.eCall info package. If both an application/EmergencyCallData:eCall-control+xml message body par= t and an application/emergencyCallData.eCall.MSD message body part are carr= ied in a SIP INFO request, they are included in a multipart/mixed message b= ody. The application/EmergencyCallData:eCall-control+xml MIME type and the appli= cation/emergencyCallData.eCall.MSD MIME type are defined in [I-D.ietf-ecrit= -eCall]. The Content-Disposition value of a message body part associated with the em= ergencyCallData.eCall info package is "info-package". 7. Info Package Usage Restrictions None defined. 8. Rate of INFO Requests Maximum rate of SIP INFO requests associated with emergencyCallData.eCall i= nfo package is ...... 9. Info Package Security Considerations The security is based on the generic security mechanism provided for the un= derlying SIP signalling. No additional security mechanism is defined. 10. Implementation Details The [I-D.ietf-ecrit-eCall] describes the NG-eCall protocol details. 11. Examples The [I-D.ietf-ecrit-eCall] gives the NG-eCall protocol examples. ------------- Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610116423FD4ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got some offline com= ments on text below of section 6 of the template so please see below update= d text.

 

Kind regards

 

Ivo Sedlacek

 

From: Ecrit [<= a href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: Friday, June 10, 2016 8:48 AM
To: Randall Gellens; Drage, Keith (Nokia - GB); ecrit@ietf.org
Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall

 

Hello,

 

>  >  1)   Any usage of= the INFO method requires a full Info package

>  > definition. While there are vario= us mentions of legacy usage, the

> > draft is not trying to follow that dire= ction, and in any case I am not

> > convinced new registrations of relevant= usage would be allowed down 

> > that route. So if the draft is to attem= pt to use the INFO method, it 

> > should formally define that method.

> 

>  I am not sure what you are saying is t= he problem with the draft.  The

> draft  does not try to use INFO in a le= gacy (non-package) manner.  It

> does register  an INFO package.  C= ould you clarify the problem that you see?

 

In order to define and register an info package i= n IANA, a filled-in template for info package definition described in RFC60= 86 section 10 needs to be provided.

 

According to RFC6086 section 10, the template con= sisting of:

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

      10.2. Overall Desc= ription

      10.3. Applicabilit= y

      10.4. Info Package= Name

      10.5. Info Package= Parameters

      10.6. SIP Option-T= ags

      10.7. INFO Message= Body Parts

      10.8. Info Package= Usage Restrictions

      10.9. Rate of INFO= Requests

      10.10. Info Packag= e Security Considerations

      10.11. Implementat= ion Details

      10.12. Examples

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

 

The draft can say e.g. the following. I am not ex= pert on ecrit eCall draft so text might need updates - feel free to update = it according to the draft.

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

1. Overall Description

 

The [I-D.ietf-ecrit-eCall] defines an NG-eCall pr= otocol enabling a PSAP to obtain a minimal set of data (MSD) from a UA loca= ted in a vehicle. The protocol makes use of SIP INFO requests associated wi= th the emergencyCallData.eCall info package to transport NG-eCall messages.

 

NG-eCall messages are:

- request for MSD

- acknowledgement of reception of request for MSD=

- MSD

- acknowledgement of reception of MSD<= /p>

- ...

 

2. Applicability

 

A number of solutions were discussed for the tran= sportation of NG-eCall messages between the UA and the PSAP. The solutions = were:

1)        = ;    use of subscription to an event package;

2)        = ;    use of the session related methods (e.g. SIP 200 (OK) r= esponse to the SIP INVITE request);

3)        = ;    use of the SIP MESSAGE method;

4)        = ;    use of media plane mechanisms; and

5)        = ;    use of the SIP INFO method as described in IETF RFC 608= 6, by defining a new info package.

 

Furthermore, each of the solutions 1), 2), 3), 4)= and 5) were evaluated.

 

The use of an event package was discounted as the= usage of subscribe/notify mechanism for two-way communication is not appro= priate since subscribe/notify mechanism is to provide one-way communication= consisting of notifications from notifier to subscriber indicating that certain events in notifier have occ= urred.

 

The use of session related methods for messages o= ther than the initial MSD was discounted as it was concluded that usage of = UPDATE method for transport of USSD message would have side effect of impac= ting dialog configuration (e.g. possibly changing the remote contact URI).

 

Use of the SIP MESSAGE method was discounted sinc= e NG-eCall protocol is dialog based and all NG-eCall messages has to be par= t of the related session.

 

Use of the media plane mechanisms was discounted = because the amount of NG-eCall messages in a dialog is normally very small = (normally only ????) and overhead caused by user plane setup (e.g. if MSRP = is used as transport) would be disproportionately big in comparion to the actual NG-eCall message size.

 

Based on the above analyses, the SIP INFO method = was chosen to transport the NG-eCall message between the UA and the PSAP.

 

3. Info Package Name

 

The info package name is emergencyCallData.eCall.=

 

4. Info Package Parameters

 

None defined.

 

5. SIP Option-Tags

 

None defined.

 

6. INFO Message Body Parts

 

application/Emergen= cyCallData:eCall-control+xml message body parts and application/emergen= cyCallData.eCall.MSD message body parts carried in SIP INFO requests are as= sociated with the emergencyCallData.eCall info package.

 

If both an applicat= ion/EmergencyCallData:eCall-control+xml message body part and an applic= ation/emergencyCallData.eCall.MSD message body part are carried in a SIP IN= FO request, they are included in a multipart/mixed message body.

 

The application/Eme= rgencyCallData:eCall-control+xml MIME type and the application/emergenc= yCallData.eCall.MSD MIME type are defined in [I-D.ietf-ecrit-eCall].

 

The Content-Disposi= tion value of a message body part associated with the emergencyCallData.eCa= ll info package is "info-package".

 

7. Info Package Usage Restrictions

 

None defined.

 

8. Rate of INFO Requests

 

Maximum rate of SIP INFO requests associated with= emergencyCallData.eCall info package is ......

 

9. Info Package Security Considerations

 

The security is based on the generic security mec= hanism provided for the underlying SIP signalling. No additional security m= echanism is defined.

 

10. Implementation Details

 

The [I-D.ietf-ecrit-eCall] describes the NG-eCall= protocol details.

 

11. Examples

 

The [I-D.ietf-ecrit-eCall] gives the NG-eCall pro= tocol examples.

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

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B3107900610116423FD4ESESSMB301erics_-- From nobody Fri Jun 24 09:03:47 2016 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7116312DC9C; Fri, 24 Jun 2016 09:00:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160044.10933.74861.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:44 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] ecrit - Requested session has been scheduled for IETF 96 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:44 -0000 Dear Roger Marshall, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ecrit Session 1 (1:00:00) Thursday, Afternoon Session III 1830-1930 Room Name: Potsdam I size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Emergency Context Resolution with Internet Technologies Area Name: Applications and Real-Time Area Session Requester: Roger Marshall Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: Special Requests: Not able to meet on Friday, please. --------------------------------------------------------- From nobody Mon Jun 27 03:25:18 2016 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 944BE12D0CE for ; Mon, 27 Jun 2016 03:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROSxQsh8_yZM for ; Mon, 27 Jun 2016 03:25:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715F112D0C3 for ; Mon, 27 Jun 2016 03:25:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-f1-5770ff084006 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.D0.18043.80FF0775; Mon, 27 Jun 2016 12:25:12 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.198]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Mon, 27 Jun 2016 12:25:10 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: New version of draft-ietf-ecrit-ecall Thread-Index: AdHQXg8n58Nq9nlIQQS+g8sDaCZHfA== Date: Mon, 27 Jun 2016 10:25:10 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610116455161@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM2J7uC7H/4Jwg2fPhS0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtJ1MgWbGCvuP9/N2sDYy9jFyMkhIWAi8e/kVDYIW0ziwr31 QDYXh5DAEUaJo5P/s0M4SxglDjdsZgKpYhPQk5i45QgriC0ioCqx4cxKsEnCQPFVjf/YIOLG Eo9vvmaHsIHqn50Ei7MA1Xc3vWcBsXkFfCVOH3oHFmcUkJW4+gfiImYBcYlbT+YzQVwkILFk z3lmCFtU4uXjf0B7OYBsJYlpW9MgynUkFuz+xAZha0ssW/iaGWK8oMTJmU9YJjAKz0IydRaS lllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzDAD275bbWD8eBzx0OMAhyM Sjy8CQEF4UKsiWXFlbmHGCU4mJVEeMX/AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcS SE8sSc1OTS1ILYLJMnFwSjUwzogO81t5v/n6s7oI7wc/M42O33yddaIgaXHUvu7TN45t1XX9 +Cno8+zp5S+TX25TXyc8wf3wHj+xtEf/Zju/rO64IVaqbezR5ePG/yu9gish7rzqoc8Hn3ZZ BRw5fz37Xavso56LfxO+vq7m31g091lLfaIS44U9qQ87m1muOmwKaQ/TnNZ4XImlOCPRUIu5 qDgRANjJhwZsAgAA Archived-At: Subject: [Ecrit] New version of draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:25:16 -0000 Hello, when will the next version of draft-ietf-ecrit-ecall be available? There we= re quite a lot of unaddressed comments raised until now. Kind regards Ivo Sedlacek From nobody Mon Jun 27 10:15:29 2016 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 677FF12D882 for ; Mon, 27 Jun 2016 10:15:28 -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: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOivMG-WsXyF for ; Mon, 27 Jun 2016 10:15:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9912D87B for ; Mon, 27 Jun 2016 10:15:26 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Jun 2016 10:15:28 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <39B5E4D390E9BD4890E2B3107900610116455161@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610116455161@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 27 Jun 2016 10:15:23 -0700 To: Ivo Sedlacek , "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 Archived-At: Subject: Re: [Ecrit] New version of draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 17:15:28 -0000 Hi Ivo, It should be available any day now. I have the bulk of the technical changes done, but I need to address some of the editorial comments. --Randy At 10:25 AM +0000 6/27/16, Ivo Sedlacek wrote: > Hello, > > when will the next version of draft-ietf-ecrit-ecall be available? > There were quite a lot of unaddressed comments raised until now. > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nothing is as irritating as a man who chats pleasantly while he's overcharging you. --Kin Hubbard From nobody Mon Jun 27 17:16:33 2016 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 34C8612DAB7 for ; Mon, 27 Jun 2016 17:16:31 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEXYk20vT6_V for ; Mon, 27 Jun 2016 17:16:29 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 23DB212D8C1 for ; Mon, 27 Jun 2016 17:16:29 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Jun 2016 17:16:30 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <39B5E4D390E9BD4890E2B3107900610116423FD4@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADEF7E2B@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <39B5E4D390E9BD4890E2B3107900610116421717@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610116423FD4@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 27 Jun 2016 17:08:43 -0700 To: Ivo Sedlacek , "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 Archived-At: Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 00:16:31 -0000 Hi Ivo, Thanks for pointing out that the draft hadn't fully complied with Section 10 of 6086. I've fixed it. --Randy At 2:58 PM +0000 6/15/16, Ivo Sedlacek wrote: > I got some offline comments on text below of section 6 of the > template so please see below updated text. > > Kind regards > > Ivo Sedlacek > > From: Ecrit > [mailto:ecrit-bounces@ietf.org] On > Behalf Of Ivo Sedlacek > Sent: Friday, June 10, 2016 8:48 AM > To: Randall Gellens; Drage, Keith (Nokia - GB); > ecrit@ietf.org > Subject: Re: [Ecrit] Usage of INFO by draft-ietf-ecrit-ecall > > Hello, > > > > 1) Any usage of the INFO method requires a full Info package > > > definition. While there are various mentions of legacy usage, the > > > draft is not trying to follow that direction, and in any case I am not > > > convinced new registrations of relevant usage would be allowed down > > > that route. So if the draft is to attempt to use the INFO method, it > > > should formally define that method. > > > > I am not sure what you are saying is the problem with the draft. The > > draft does not try to use INFO in a legacy (non-package) manner. It > > does register an INFO package. Could you clarify the problem > that you see? > > In order to define and register an info package in IANA, a > filled-in template for info package definition described in RFC6086 > section 10 needs to be provided. > > According to RFC6086 section 10, the template consisting of: > ------------- > 10.2. Overall Description > 10.3. Applicability > 10.4. Info Package Name > 10.5. Info Package Parameters > 10.6. SIP Option-Tags > 10.7. INFO Message Body Parts > 10.8. Info Package Usage Restrictions > 10.9. Rate of INFO Requests > 10.10. Info Package Security Considerations > 10.11. Implementation Details > 10.12. Examples > ------------- > > The draft can say e.g. the following. I am not expert on ecrit > eCall draft so text might need updates - feel free to update it > according to the draft. > ------------- > 1. Overall Description > > The [I-D.ietf-ecrit-eCall] defines an NG-eCall protocol enabling a > PSAP to obtain a minimal set of data (MSD) from a UA located in a > vehicle. The protocol makes use of SIP INFO requests associated > with the emergencyCallData.eCall info package to transport NG-eCall > messages. > > NG-eCall messages are: > - request for MSD > - acknowledgement of reception of request for MSD > - MSD > - acknowledgement of reception of MSD > - ... > > 2. Applicability > > A number of solutions were discussed for the transportation of > NG-eCall messages between the UA and the PSAP. The solutions were: > 1) use of subscription to an event package; > 2) use of the session related methods (e.g. SIP 200 (OK) > response to the SIP INVITE request); > 3) use of the SIP MESSAGE method; > 4) use of media plane mechanisms; and > 5) use of the SIP INFO method as described in IETF RFC > 6086, by defining a new info package. > > Furthermore, each of the solutions 1), 2), 3), 4) and 5) were evaluated. > > The use of an event package was discounted as the usage of > subscribe/notify mechanism for two-way communication is not > appropriate since subscribe/notify mechanism is to provide one-way > communication consisting of notifications from notifier to > subscriber indicating that certain events in notifier have occurred. > > The use of session related methods for messages other than the > initial MSD was discounted as it was concluded that usage of UPDATE > method for transport of USSD message would have side effect of > impacting dialog configuration (e.g. possibly changing the remote > contact URI). > > Use of the SIP MESSAGE method was discounted since NG-eCall > protocol is dialog based and all NG-eCall messages has to be part > of the related session. > > Use of the media plane mechanisms was discounted because the amount > of NG-eCall messages in a dialog is normally very small (normally > only ????) and overhead caused by user plane setup (e.g. if MSRP is > used as transport) would be disproportionately big in comparion to > the actual NG-eCall message size. > > Based on the above analyses, the SIP INFO method was chosen to > transport the NG-eCall message between the UA and the PSAP. > > 3. Info Package Name > > The info package name is emergencyCallData.eCall. > > 4. Info Package Parameters > > None defined. > > 5. SIP Option-Tags > > None defined. > > 6. INFO Message Body Parts > > application/EmergencyCallData:eCall-control+xml message body parts > and application/emergencyCallData.eCall.MSD message body parts > carried in SIP INFO requests are associated with the > emergencyCallData.eCall info package. > > If both an application/EmergencyCallData:eCall-control+xml message > body part and an application/emergencyCallData.eCall.MSD message > body part are carried in a SIP INFO request, they are included in a > multipart/mixed message body. > > The application/EmergencyCallData:eCall-control+xml MIME type and > the application/emergencyCallData.eCall.MSD MIME type are defined > in [I-D.ietf-ecrit-eCall]. > > The Content-Disposition value of a message body part associated > with the emergencyCallData.eCall info package is "info-package". > > 7. Info Package Usage Restrictions > > None defined. > > 8. Rate of INFO Requests > > Maximum rate of SIP INFO requests associated with > emergencyCallData.eCall info package is ...... > > 9. Info Package Security Considerations > > The security is based on the generic security mechanism provided > for the underlying SIP signalling. No additional security mechanism > is defined. > > 10. Implementation Details > > The [I-D.ietf-ecrit-eCall] describes the NG-eCall protocol details. > > 11. Examples > > The [I-D.ietf-ecrit-eCall] gives the NG-eCall protocol examples. > ------------- > > Kind regards > > Ivo Sedlacek > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Consistency is the last refuge of the unimaginative. --Oscar Wilde From nobody Mon Jun 27 17:36:59 2016 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 856DA12DABF for ; Mon, 27 Jun 2016 17:36:57 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8qyA4XND7uG for ; Mon, 27 Jun 2016 17:36:56 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD6812DAB5 for ; Mon, 27 Jun 2016 17:36:56 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Jun 2016 17:36:58 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 27 Jun 2016 17:36:53 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] draft-ecall: A few editorial change suggestions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 00:36:57 -0000 Hi Christer, Thanks very much for the editorial suggestions. Please see below. --Randy At 12:15 PM +0000 6/6/16, Christer Holmberg wrote: > Hi, > > A few (I will do a more detailed review once we get the changes > based on the 3GPP requirements implemented) editorial comments on > the ecall draft: > > Q1: The Abstract needs to be shorter. There are too many ecall > details that I think can be removed. I deleted some details to make it shorter. > > Q2: In section 3, I suggested to remove "Currently,". If you > really want to refer to the current time, you could say something > like "At the time of writing this document," but personally I don't > think it's needed in this case. In my overall walk-through while making the substantive changes, I deleted all uses of "currently" and "now" as I agree that it isn't needed nor especially helpful. > > Q3: Similar to Q2, I suggest to remove/replace "is now in process.". See above. > > Q4: Would it be possible to make sections 7 and 8 to subsections > of section 6? I made the old Section 7 (Call Routing) a subsection of Section 6 (Call setup) since that seems to fit well. I left the old Section 8 (Test Calls) its own section because it seems to me that it's talking about different call setup, but I'm open to reconsidering this. > > Q5: I suggest that we put the INFO package definition in a > separate main section instead of subsection (9.2). Good idea, especially with the longer and additional material for Section 10 of RFC 6086. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Information is the currency of democracy. --Thomas Jefferson From nobody Mon Jun 27 17:42:07 2016 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 5294E12DABF for ; Mon, 27 Jun 2016 17:42:06 -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: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seh-9jrHOL7g for ; Mon, 27 Jun 2016 17:42:04 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5E12DAB5 for ; Mon, 27 Jun 2016 17:42:04 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 27 Jun 2016 17:42:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38034EB6@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8BADF0F051@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <7594FB04B1934943A5C02806D1A2204B38034EB6@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 27 Jun 2016 17:41:58 -0700 To: Christer Holmberg , "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 Archived-At: Subject: Re: [Ecrit] ECRIT Interim meeting - June X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 00:42:06 -0000 Hi Christer, At 5:32 PM +0000 6/3/16, Christer Holmberg wrote: > I'd like to get some input e.g. on what changes will be done > regarding the ASN.1 encoding. > > Q1: Will ASN.1 be added in addition to XML? Or, will we remove XML? I've added the ASN.1 PER encoding from Annex A of EN 15722, deleted the registration for the XML encoding of the MSD, and added a parenthetical aside to explicit note that it isn't used. > > Q2: For ASN.1, which encoding will we use? CEN allows both UPER and > EXER. As 3GPP wants binary encoding, at least UPER needs to be > supported. What about EXER? Since EN 15722 specifically defines the PER encoding as normative in Annex A, and since that is what's used in CS-eCall, and since my understanding is this is what 3GPP prefers, that's what I've included. > > Q3: What will we do regarding the MSD max size of 140 bytes? We don't need to do anything in this draft. That's a 3GPP limitation, and the ASN.1 PER encoding meets that. > I'd also like to get some input regarding the > usage-of-modem-on-the-media-plane issue I raised earlier today. Do > we need to say something? What do we need to say? i don't believe we need to say anything in this draft. --Randy > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: 03 June 2016 19:52 > To: Drage, Keith (Nokia - GB) ; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > Keith: > I think you mean that you want to see all of your comments > addressed ahead of an updated draft, right? I see comments being > made and some responses. > > If you have comments that you believe haven't been addressed as > part of the list discussions, resend them. Be sure to offer > proposed text to what you believe may be deficiencies in the > current draft. > > -roger. > > From: Drage, Keith (Nokia - GB) > [mailto:keith.drage@nokia.com] > Sent: Friday, June 03, 2016 9:45 AM > To: Roger Marshall; ecrit@ietf.org > Subject: RE: ECRIT Interim meeting - June > > Can we see some response to the comments being made first. > > This is a WG document, and is meant to reflect the consensus of the > working group, and not the authors thoughts and considerations. > > Keith > > From: Ecrit > [mailto:ecrit-bounces@ietf.org] On > Behalf Of Roger Marshall > Sent: 03 June 2016 17:41 > To: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT Interim meeting - June > > Given a variety of factors, including individuals' availability, > the chairs have decided to Not schedule an interim meeting at this > time. We look forward to seeing continued list discussion in order > to work through the current issues, and it seems like progress is > being made. We also look forward to getting an updated draft soon, > so that folks can see the proposed text changes being discussed. > > Roger Marshall & Marc Linsner > ECRIT Chairs > > From: Ecrit > [mailto:ecrit-bounces@ietf.org] On > Behalf Of Roger Marshall > Sent: Wednesday, June 01, 2016 4:04 PM > To: ecrit@ietf.org > Subject: [Ecrit] ECRIT Interim meeting - June > > ECRIT: > The work group needs to figure out how it can address some of the > raised issues in order to make progress on > draft-ietf-ecrit-ecall-07. > > We've set up a doodle poll at the following link for next week: > > > http://doodle.com/poll/hnfhkvfgc7x6hesx > > Please mark your best available times to discuss. Bridge > information will follow, once we have a timeslot identified. > > > Roger Marshall & Marc Linsner > ECRIT Chairs > > > NOTICE TO RECIPIENT: This email, including attachments, may contain > information which is confidential, proprietary, attorney-client > privileged and/or controlled under U.S. export laws and regulations > and may be restricted from disclosure by applicable State and > Federal law. Nothing in this email shall create any legal binding > agreement between the parties unless expressly stated herein and > provided by an authorized representative of Comtech > Telecommunications Corp. or its subsidiaries. If you are not the > intended recipient of this message, be advised that any > dissemination, distribution, or use of the contents of this message > is strictly prohibited. If you received this message in error, > please notify us immediately by return email and permanently delete > all copies of the original email and any attached documentation > from any computer or other media. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Beware of programmers who carry screwdrivers. --Leonard Brandwein