From nobody Mon Aug 1 13:44: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 BC37412D880 for ; Mon, 1 Aug 2016 13:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6pO5bsp-Nyf3 for ; Mon, 1 Aug 2016 13:44:23 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (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 0DDDC12D8E8 for ; Mon, 1 Aug 2016 13:44:18 -0700 (PDT) Received: from [85.158.136.35] by server-6.bemta-5.messagelabs.com id F7/ED-29022-1A4BF975; Mon, 01 Aug 2016 20:44:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRWlGSWpSXmKPExsVybg1jsu6CLfP DDSZc17FoXPSU1YHRY8mSn0wBjFGsmXlJ+RUJrBmdz7oYC76pVTRv/MPSwPheoYuRk0NCwE/i 76pnbF2MXBxCAvsYJSZ828cIkhASuM4oMf+uEUTiFKPEic+LmbsYOTjYBPQkLr6yAakREVCV2 HBmJVi9sICpxJqPP5kg4mYSWzecYwUpFxEwkjg3Xx8kzCKgInF3z1VmEJtXwEdi3uUXUKsCJI 6s6Adr5RQIlNje2AAWZxSQldgw8RsLiM0sIC7x7ehKZoibBSSW7DkPZYtKvHz8jxXCNpDYunQ fC4QtL7FuxTNWiF49iRtTp7BB2NoSyxa+hrpBUOLkzCdQ9ZISB1fcYAE5WUhARmLrFkWIz2cx SkydvBdqvr3Ew8tfmSYwSs1CctIsJCtmIVkxC8mKBYwsqxg1ilOLylKLdA0t9JKKMtMzSnITM 3N0DQ1M9XJTi4sT01NzEpOK9ZLzczcxAqOUAQh2MDZt9zzEKMnBpCTK69k0P1yILyk/pTIjsT gjvqg0J7X4EKMMB4eSBO/szUA5waLU9NSKtMwcYLqASUtw8CiJ8EqDpHmLCxJzizPTIVKnGBW lxHmzQRICIImM0jy4NliKusQoKyXMywh0iBBPQWpRbmYJqvwrRnEORiVh3s0gU3gy80rgpr8C WswEtDjRfg7I4pJEhJRUA+OZU5Nif/j9P1UbueTkguqVPLbeiu97YicoWR1o8xWbveLDw4IsA QNFlQknGxflLIvR8FVUKv2y7lCQcp7TuosvH02coN7LrM7y8KaTc9YDOTET62/pKZ6L3lqHNi +7/PdqVorGET4JP3kby0r19RNjXuwqrHJ5NeP+yrSmjPQvt3favmHQP6HEUpyRaKjFXFScCAB qi+v6TAMAAA== X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-14.tower-125.messagelabs.com!1470084255!40642774!2 X-Originating-IP: [206.172.1.99] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25668 invoked from network); 1 Aug 2016 20:44:16 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-14.tower-125.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 Aug 2016 20:44:16 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca Received: from DG2MBX04-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; Mon, 1 Aug 2016 16:33:51 -0400 Received: from DG2MBX01-WYN.bell.corp.bce.ca (2002:8eb6:1213::8eb6:1213) by DG2MBX04-WYN.bell.corp.bce.ca (2002:8eb6:1216::8eb6:1216) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Aug 2016 16:44:14 -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; Mon, 1 Aug 2016 16:44:14 -0400 From: "Caron, Guy (A162859)" To: "ecrit@ietf.org" Thread-Topic: WGLC Announce: Data-Only Emergency Calls Thread-Index: AdHh/pGOyJxBPWiRSl6QnMmpW/luawKKmHgA Date: Mon, 1 Aug 2016 20:44:14 +0000 Message-ID: <191149acb26d4c5baad87376e14faf24@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.28.92.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Subject: Re: [Ecrit] WGLC Announce: Data-Only Emergency Calls 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, 01 Aug 2016 20:44:26 -0000 Hi ECRIT, I've reviewed this draft and finds it ready to move forward. My review comm= ents are in the sections below where PART A is for substantive comments and= PART B is for editorial/cosmetic comments. Thanks, Guy ////// START \\\\\\ PART A - Substantive Comments -------------------------------- Section 1 a. Second paragraph, 2nd sentence: Delete "or vehicles sending crash data" = as this is covered in another I-D and align the text with what is found in = the abstract: "Examples of such environments include alerts issued by a tem= perature sensor, burglar alarm or chemical spill sensor." b. Second paragraph, 3rd sentence: Delete "to emergency authorities" to cov= er both usage modes. Section 8 b. See comment on CAP v1.1 below. c. In both examples, delete "2" in the Content-ID field of the PIDF-LO body= to match what is declared in the Geolocation header field (abcdef@domain.c= om). Section 9 d. The section recommends use of RFC4474. There is work in the IETF STIR WG= to enhance this mechanism (RFC4474bis). Should RFC4474bis be referenced in= stead? Section 10.1 e. The hyperlink to the CAP protocol under Additional Information is broken= and should be updated. Normative References Section f. The Referenced CAP standard is version 1.1 published in October 2005. Ve= rsion 1.2 was published in 2010. Any reason not to reference the latest ver= sion? If it is agreed to reference v1.2, the examples in section 8 should b= e revisited to ensure they remain XML-valid with the v1.2 schema. Section B - Editorial/Cosmetic ------------------------------ Abstract Section 1. Second paragraph: In the 2nd sentence, remove the comma after alarm ("Ex= amples of such environments include alerts issued by a temperature sensor, = burglar alarm or chemical spill sensor"). 2. Second paragraph: In the 4th sentence, make "type" plural and "interacti= on" singular ("These types of interaction..."). Section 1 3. Second paragraph: In the 4th sentence, make "type" plural and "interacti= on" singular ("These types of interaction..."). 4. Last paragraph and all occurrences thereafter: Replace the Additional Da= ta I-D by RFC 7852. 5. Last paragraph: Replace "alert specific" by "alert-specific". Section 4.1 6. Second paragraph: in the 2nd sentence, replace the first "with" with "vi= a" (i.e., " Accordingly, it is introduced to the SIP message via a Call-Inf= o header field with a purpose of..."). 7. Second paragraph: In the 4th sentence, change "Alternative" to "Alternat= ively" and capitalize "url". Section 4.2 8. Fourth paragraph: In the second sentence, remove the comma after "preser= ved". 9. Fourth paragraph: In the last sentence, delete "original". 10. Eighth paragraph: Replace "sendor" by "sender". Section 5.2 11. In the paragraph starting with "The ErrorValue contains a 3-digit error= code...": In the third sentence, replace "are" with "is" since "string" is= appropriately singular. 12. In the paragraph starting with "The AlertMsg-Error header field MAY be = included...": In the second sentence, replace "an" by "a" before "MESSAGE". Section 8 13. Make the dateTime of the element of the CAP body consistent with= the dateTime of the and element of the PIDF= -LO body. Section 10.3 14. Add a colon after "added" in the first sentence. \\\\\\ END ////// -----Message d'origine----- De=A0: Ecrit [mailto:ecrit-bounces@ietf.org] De la part de Roger Marshall Envoy=E9=A0: 19 juillet 2016 16:46 =C0=A0: ecrit@ietf.org Objet=A0: [Ecrit] WGLC Announce: Data-Only Emergency Calls Today starts a new working group last call for: Data-Only Emergency Calls http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Please review the document and send comments to the ECRIT mail list by CoB,= July 30, 2016. Thanks, Marc & Roger ECRIT Chairs _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 1 18:17:07 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 CEE8212B012; Mon, 1 Aug 2016 18:17:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160802011705.3053.49151.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 18:17:05 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-11.txt 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: Tue, 02 Aug 2016 01:17:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-11.txt Pages : 42 Date : 2016-08-01 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Blocks for the eCall vehicle data and metadata/ control data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 1 18:17: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 ADB0D12B012; Mon, 1 Aug 2016 18:17:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160802011742.2947.77352.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 18:17:42 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-09.txt 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: Tue, 02 Aug 2016 01:17:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-09.txt Pages : 40 Date : 2016-08-01 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the eCall metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit- switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 3 16:08: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 4E4B912D812 for ; Wed, 3 Aug 2016 16:08:33 -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, 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 hIV-n-i2JrjL for ; Wed, 3 Aug 2016 16:08:31 -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 A71C312D193 for ; Wed, 3 Aug 2016 16:08:31 -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 u73N8Mug028787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2016 16:08:23 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Wed, 3 Aug 2016 16:08:22 -0700 From: Roger Marshall To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: Meeting Minutes Posted - IETF96 Thread-Index: AdHjh0/BFAEM1uEXT1yyuopVv4DvFAKUiLNQ Date: Wed, 3 Aug 2016 23:08:21 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Meeting Minutes Posted - IETF96 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, 03 Aug 2016 23:08:33 -0000 Our plan is to issue WGLC for both drafts soon, draft-ietf-ecrit-ecall-11 draft-ietf-ecrit-car-crash-09 which have now been updated a couple of times to resolve all significant is= sues (thanks Randy & Christer). =20 Anyone have any objections to doing so? Roger & Marc ECRIT Chairs -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, July 21, 2016 12:41 PM To: ecrit@ietf.org Subject: [Ecrit] Meeting Minutes Posted - IETF96 You can find the ECRIT/IETF96 meeting minutes for today's meeting in Berlin= , posted to the Materials Manager at: http://www.ietf.org/proceedings/96/minutes/minutes-96-ecrit Thanks to our anonymous etherpad note-taker! I've combined those notes wit= h ones I also recorded. Please let me know if there is any information that is not accurate, along = with the correction. Roger Marshall ECRIT Co-chair 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 3 16:10:26 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 DAE5212D8BC for ; Wed, 3 Aug 2016 16:10:20 -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, 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 EeBn3V3xkINA for ; Wed, 3 Aug 2016 16:10:16 -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 8BEE612D812 for ; Wed, 3 Aug 2016 16:10:16 -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 u73NA9UL005982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2016 16:10:10 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Wed, 3 Aug 2016 16:10:09 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AdHt3B9sbBpup4QKShyfkTKkLnlndw== Date: Wed, 3 Aug 2016 23:10:09 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 03 Aug 2016 23:10:21 -0000 Changing subject line & resending. *** Our plan is to issue WGLC for both drafts soon, draft-ietf-ecrit-ecall-11 draft-ietf-ecrit-car-crash-09 which have now been updated a couple of times to resolve all significant is= sues (thanks Randy & Christer). =20 Anyone have any objections to doing so? Roger & Marc 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. From nobody Thu Aug 4 05:29: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 F412512D18C for ; Thu, 4 Aug 2016 05:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9iOi9tgDdw_W for ; Thu, 4 Aug 2016 05:29:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B5012DA3D for ; Thu, 4 Aug 2016 05:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1470313733; x=1471523333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HZJf4nP37EMlLdYmbbYaMoCM2Ex0yPhXuiNDW4xYxME=; b=E1/P/TNMsgV7DGcG7CMm4HDCMcVWHYDkUDnM5Su5m8ES9MbXx27kEbtk pAix/xQALBy+MAEN1IuqhfWtUEVk1XuBtf40ocL2qCsVWyiAquiBBFAJ9 KHYkwRwPNJuEEnHEHf2TzU6aw9vORHH272dJtGLoLoIBnyRMF79XKmG+k E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgA5NKNX/5hdJa1dg0WBUqVNk06Bf?= =?us-ascii?q?YYdAoFTOBQBAQEBAQEBXSeEXgEBBAE6PwULAgEIGB4QMiUBAQQOBYgpCL5mAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIYqgXgIgk2EEhEBHAcxgnSCLwEEmTQBjAiCe?= =?us-ascii?q?YFrF4REiHqMMYN2AR42g3puhheBNgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="132225383" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 12:28:52 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u74CSpZg029676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Aug 2016 12:28:51 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 Aug 2016 07:28:51 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Thu, 4 Aug 2016 07:28:51 -0500 From: "Marc Linsner (mlinsner)" To: Roger Marshall Thread-Topic: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AdHt3B9sbBpup4QKShyfkTKkLnlndwAb6I5E Date: Thu, 4 Aug 2016 12:28:50 +0000 Message-ID: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 04 Aug 2016 12:29:44 -0000 No objections from me...... I'm wondering what Keith will have to say.... -Marc- Sent from my iPad > On Aug 3, 2016, at 7:10 PM, Roger Marshall wrote: >=20 > Changing subject line & resending. >=20 > *** >=20 > Our plan is to issue WGLC for both drafts soon, >=20 > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 >=20 > which have now been updated a couple of times to resolve all significant = issues (thanks Randy & Christer). =20 > Anyone have any objections to doing so? >=20 > Roger & Marc > ECRIT Chairs >=20 >=20 >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain infor= mation which is confidential, proprietary, attorney-client privileged and/o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient 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 pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. From nobody Thu Aug 4 08:37:58 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 7B2AF12D8BA for ; Thu, 4 Aug 2016 08:37:56 -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 NGiYqoQqOAOE for ; Thu, 4 Aug 2016 08:37:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 C269C12D8B8 for ; Thu, 4 Aug 2016 08:37:53 -0700 (PDT) X-AuditID: c1b4fb2d-fa6bb98000000190-ef-57a3614fd7ac Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 5B.CD.00400.F4163A75; Thu, 4 Aug 2016 17:37:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0301.000; Thu, 4 Aug 2016 17:37:35 +0200 From: Christer Holmberg To: "Marc Linsner (mlinsner)" , Roger Marshall Thread-Topic: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AQHR7kvmThAqZe1JQkW1XTmzj6mTm6A47thA Date: Thu, 4 Aug 2016 15:37:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4771FA8F@ESESSMB209.ericsson.se> References: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> In-Reply-To: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> 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+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdXTcgcXG4QUs/t0XjoqesFmcvX2e0 WPjrF4sDs8eU3xtZPS5taWX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxqq/51gK7gtW3H4+jbmB 8TBfFyMnh4SAicSs3e/YQGwhgfWMEld2iHcxcgHZixklOk/3sXQxcnCwCVhIdP/TBqkREUiR +Ne3jBnEZhZQlTjX+JgFxBYWCJd4v+AKK0RNhMT5m9PZIGwjiaPnNoDVswioSNzYehjM5hXw lZh0azMrxK5mRon+/W/YQRKcArYSO++tAytiFBCT+H5qDRPEMnGJW0/mM0EcLSCxZM95Zghb VOLl43+sELaSxIrtlxgh6nUkFuz+xAZha0ssW/gaarGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMHYObvmtu4Nx9WvHQ4wCHIxKPLwKhovC hVgTy4orcw8xSnAwK4nwusUtDhfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxIID2xJDU7 NbUgtQgmy8TBKdXAGKxU4PutbW2tfvUcW7+DHbtrThnMS2WXFLI1bL8VqPHnyCr9mp78jhQu PosNdfxF7y8q/uNWZX4kF+M+82f3u8Rv37YefMxXkLtwd3C6hfv8c5P/Je/mu8oic894/863 Rz6avpHTcvPbVKp4pvMDn/PGtc/kjxRLrIhkPXZwfipXPr8Az483SizFGYmGWsxFxYkASGpC wJkCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 04 Aug 2016 15:37:56 -0000 Hi, I have provided comments to the authors. Many of my issues have been addres= sed, but there are still some issues that still need work. But, as I'm curr= ently on vacation I am slow with e-mails. I am not saying that should prevent the WGLC to be issued, but just to make= you aware. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlin= sner) Sent: 04 August 2016 15:29 To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-= ecrit-car-crash-09 No objections from me...... I'm wondering what Keith will have to say.... -Marc- Sent from my iPad > On Aug 3, 2016, at 7:10 PM, Roger Marshall wrote: >=20 > Changing subject line & resending. >=20 > *** >=20 > Our plan is to issue WGLC for both drafts soon, >=20 > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 >=20 > which have now been updated a couple of times to resolve all significant = issues (thanks Randy & Christer). =20 > Anyone have any objections to doing so? >=20 > Roger & Marc > ECRIT Chairs >=20 >=20 >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain infor= mation which is confidential, proprietary, attorney-client privileged and/o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient 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 pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 4 08:38:26 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 1BA7A12B032 for ; Thu, 4 Aug 2016 08:38:25 -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, 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 SVDAOkXE1b5U for ; Thu, 4 Aug 2016 08:38:23 -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 BA5F3127058 for ; Thu, 4 Aug 2016 08:38:12 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id u74FbweN028171 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 08:37:58 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 08:37:58 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Correcting Milestone descriptions - RFC type for 3 IDs Thread-Index: AdHuZdaxlp01Bq0UTuWzcAXn34oaQw== Date: Thu, 4 Aug 2016 15:37:56 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Correcting Milestone descriptions - RFC type for 3 IDs 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, 04 Aug 2016 15:38:25 -0000 As was mentioned in Berlin at IETF96 during the Chairs discussion, there is= a need to align Milestone descriptions with what is in 3 Internet Drafts (= links below). The reason for these changes is to correct errors made durin= g the original milestone submission process. These IDs have been labeled a= ppropriately as Stds Track RFCs from their inception at -00, we just need t= o properly list them in the Milestone list as the same. Changed from: Nov 2016 Submit 'A LoST extension to return complete and similar location = info' to the IESG for consideration as an Informational RFC draft-ietf-ecrit-similar-location Nov 2016 Submit 'Next-Generation Pan-European eCall' to the IESG for consi= deration as an Informational RFC draft-ietf-ecrit-ecall Nov 2016 Submit 'Internet Protocol-based In-Vehicle Emergency Calls' to th= e IESG for consideration as an Informational RFC draft-ietf-ecrit-car-crash To: Nov 2016 Submit 'A LoST extension to return complete and similar location = info' to the IESG for consideration as a Standards Track RFC draft-ietf-ecrit-similar-location Nov 2016 Submit 'Next-Generation Pan-European eCall' to the IESG for consi= deration as a Standards Track RFC draft-ietf-ecrit-ecall Nov 2016 Submit 'Internet Protocol-based In-Vehicle Emergency Calls' to th= e IESG for consideration as a Standards Track RFC draft-ietf-ecrit-car-crash Reference links: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ Does anyone object to aligning these milestone descriptions with the docume= nt descriptions? Roger & Marc 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. From nobody Thu Aug 4 08:39: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 4888C127058 for ; Thu, 4 Aug 2016 08:39:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 G3JrvXpjmjZP for ; Thu, 4 Aug 2016 08:39:51 -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 7324612B032 for ; Thu, 4 Aug 2016 08:39:51 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id u74FdJqO028976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 08:39:19 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 08:39:19 -0700 From: Roger Marshall To: Christer Holmberg , "Marc Linsner (mlinsner)" Thread-Topic: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AdHt3B9sbBpup4QKShyfkTKkLnlndwAb6I5EABVCg4AADp+EMA== Date: Thu, 4 Aug 2016 15:39:18 +0000 Message-ID: References: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> <7594FB04B1934943A5C02806D1A2204B4771FA8F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4771FA8F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 04 Aug 2016 15:39:53 -0000 Thanks Christer for the heads up. -roger. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 04, 2016 8:38 AM To: Marc Linsner (mlinsner); Roger Marshall Cc: ecrit@ietf.org Subject: RE: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-ca= r-crash-09 Hi, I have provided comments to the authors. Many of my issues have been addres= sed, but there are still some issues that still need work. But, as I'm curr= ently on vacation I am slow with e-mails. I am not saying that should prevent the WGLC to be issued, but just to make= you aware. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlin= sner) Sent: 04 August 2016 15:29 To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-= ecrit-car-crash-09 No objections from me...... I'm wondering what Keith will have to say.... -Marc- Sent from my iPad > On Aug 3, 2016, at 7:10 PM, Roger Marshall wrote: >=20 > Changing subject line & resending. >=20 > *** >=20 > Our plan is to issue WGLC for both drafts soon, >=20 > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 >=20 > which have now been updated a couple of times to resolve all significant = issues (thanks Randy & Christer). =20 > Anyone have any objections to doing so? >=20 > Roger & Marc > ECRIT Chairs >=20 >=20 >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain infor= mation which is confidential, proprietary, attorney-client privileged and/o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient 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 pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 5 04:15: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 2AF6312D10B for ; Fri, 5 Aug 2016 04:15:40 -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 RDDyfV51sLrj for ; Fri, 5 Aug 2016 04:15:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D94E812D5D1 for ; Fri, 5 Aug 2016 04:15:27 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-1b-57a4754c9edb Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 40.CB.02553.C4574A75; Fri, 5 Aug 2016 13:15:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 13:15:24 +0200 From: Ivo Sedlacek To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AdHvCf2XvCTspod0Sfqn3Oqg2MqovQ== Date: Fri, 5 Aug 2016 11:15:24 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BDF85@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.146] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7h65f6ZJwg02/eCwaFz1ltVj46xeL A5PHpS2t7B5LlvxkCmCK4rJJSc3JLEst0rdL4MqY+nIVa0GTW8X9t0fYGxif2nQxcnJICJhI dO2ewt7FyMUhJLCeUeLDtN3MEM5iRomp196yglSxCehJTNxyBMwWEQiXWL7gJCOILSzgLLHp Zys7RNxD4t/CB0DNHEC2nsSJdRogJouAisSTO+kgFbwCvhIfuieCTWEUkJW4+qcXbAqzgLjE rSfzmSDuEZBYsuc8M4QtKvHy8T9WCFtJ4seGSywQ9fkS25quMkPMFJQ4OfMJywRGwVlIRs1C UjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKSXWpSZXFycn6eX l1qyiREYDQe3/DbYwfjyueMhRgEORiUe3gVNi8OFWBPLiitzDzFKcDArifDaliwJF+JNSays Si3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDokvnxm53z0elPOJb/ Vfy4j1ckzVemT7b5sQffsYV67UKXrk7ZU7Ini/VPwNpVGhvedGptPBpbuDTRiWPCv2v3JFPj LguvXyu/OK2lLunFBmXWymcL/skf4lBQyKzIeay4JeFW9ZKy3fH5H68nv3sqK7YygkP3DFNT xPnGk7Pnl+meblTfruOmxFKckWioxVxUnAgAD9qdYoICAAA= Archived-At: Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 11:15:40 -0000 --_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, COMMENT: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Inclusion of Call-Info header field with purpose=3DemergencyCallData.eCall.= MSD or purpose=3DemergencyCallData.eCall.control in requests and responses = does not seem to bring any value. It seems to only waste radio resources. For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the in= itial INVITE request: - if this is meant to be used by a proxy for routing of the eCall emergency= call to a PSAP supporting eCall emergency call, then this seems to be redu= ndant to the eCall URN included in the Request-URI and the Recv-Info header= field containing eCall specific info package (emergencyCallData.eCall.MSD)= . - if this is meant to be used by UAS (i.e. PSAP), then according to RFC3261= subclause 8.2.3, then the UAS anyway needs to check that all the bodies of= the INVITE request not marked with Content-Disposition: ...; handling=3Dop= tional are understood. So, application/emergencyCallData.eCall.MSD+per MIME= body will anyway be found by UAS during the INVITE request processing. For Call-Info with purpose=3DemergencyCallData.eCall.control included in a = response to the initial INVITE request - no routing decisions are done by proxies when receiving a response to the= initial INVITE request so this does not seem to have any value for the pro= xies - UAC includes Accept with supported MIME types in INVITE request so why wo= uld UAS send any MIME body not wished by the UAC? For Call-Info with purpose=3DemergencyCallData.eCall.control included in th= e INFO request - no routing decisions are done by proxies when receiving an in-dialog requ= est so this does not seem to have any value for the proxies - support of info package emergencyCallData.eCall.MSD in the call implies t= hat either application/EmergencyCallData.eCall.control+xml MIME body or app= lication/emergencyCallData.eCall.MSD+per MIME body is included. Again, acco= rding to RFC3261 subclause 8.2.3, the UAS anyway needs to check that all th= e bodies of the INFO request not marked with Content-Disposition: ...; hand= ling=3Doptional are understood. So, application/EmergencyCallData.eCall.con= trol+xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body= will anyway be found by UAS during the INFO request processing. ///////////////////////////////////////////////////////////////////////////= /// PROPOSED SOLUTION to COMMENT \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Remove insertion of Call-Info header field. ///////////////////////////////////////////////////////////////////////////= /// Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

COMMENT:

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Inclusion of Call-Info header field with purpose= =3DemergencyCallData.eCall.MSD or purpose=3DemergencyCallData.eCall.control= in requests and responses does not seem to bring any value. It seems to on= ly waste radio resources.

 

For Call-Info with purpose=3DemergencyCallData.eC= all.MSD included in the initial INVITE request:

- if this is meant to be used by a proxy for rout= ing of the eCall emergency call to a PSAP supporting eCall emergency call, = then this seems to be redundant to the eCall URN included in the Request-UR= I and the Recv-Info header field containing eCall specific info package (emergencyCallData.eCall.MSD).

- if this is meant to be used by UAS (i.e. PSAP),= then according to RFC3261 subclause 8.2.3, then the UAS anyway needs to ch= eck that all the bodies of the INVITE request not marked with Content-Dispo= sition: ...; handling=3Doptional are understood. So, application/emergencyCallData.eCall.MSD+per MIME body = will anyway be found by UAS during the INVITE request processing.

 

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in a response to the initial INVITE request=

- no routing decisions are done by proxies when r= eceiving a response to the initial INVITE request so this does not seem to = have any value for the proxies

- UAC includes Accept with supported MIME types i= n INVITE request so why would UAS send any MIME body not wished by the UAC?=

 

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in the INFO request

- no routing decisions are done by proxies when r= eceiving an in-dialog request so this does not seem to have any value for t= he proxies

- support of info package emergencyCallData.eCall= .MSD in the call implies that either application/EmergencyCallData.eCall.co= ntrol+xml MIME body or application/emergencyCallData.eCall.MSD+per = MIME body is included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway needs to check that all the bodies= of the INFO request not marked with Content-Disposition: ...; handling=3Do= ptional are understood. So, application/EmergencyCallData.eCall.control+= ;xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body will anyway be found by UAS during the INFO request processing.<= o:p>

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

PROPOSED SOLUTION to COMMENT

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Remove insertion of Call-Info header field.<= /o:p>

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

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_-- From nobody Fri Aug 5 04:41: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 73B8512D7B3; Fri, 5 Aug 2016 04:41:28 -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 HhCYEq1Z372N; Fri, 5 Aug 2016 04:41:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8C43212D782; Fri, 5 Aug 2016 04:41:26 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-07-57a47b62ac09 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 3E.56.02493.26B74A75; Fri, 5 Aug 2016 13:41:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 13:41:21 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 Thread-Index: AdHvCr3UqMZD6yUmRXGJoLQMM15tQQ== Date: Fri, 5 Aug 2016 11:41:22 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BDFB2@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM2J7oG5K9ZJwg+e/LSwaFz1ltfj6YxOb A5PHkiU/mQIYo7hsUlJzMstSi/TtErgybi7bxVJwSLDi/N8uxgbG5XxdjJwcEgImEodvzmTv YuTiEBJYzyix78I9KGcxo0TH399MIFVsAnoSE7ccYQWxRQRUJTacWckIYjMLaEo82rkXrEZY IEji9LopzBA1wRKn+w5B1etJHNi+mQ3EZhFQkfg6swfM5hXwlZh+9zc7iM0oICtx9U8v1Exx iVtP5jNBXCcgsWTPeWYIW1Ti5eN/rBC2ksSPDZdYIOp1JBbs/sQGYWtLLFv4mhlivqDEyZlP WCYwCs9CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw3A9u+W21 g/Hgc8dDjAIcjEo8vAuaFocLsSaWFVfmHmKU4GBWEuFVqFoSLsSbklhZlVqUH19UmpNafIhR moNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoHR5Pr3xq+v5mi7rXYvNohZ8z5TxXZv5WS2 QpvZt/+8a2V6kbbCQ2hjxdK0Dqt+79LSN5rW33tYTn3/LFW6W8Exj2vVi7D46PxQ44Obb/35 1HL02x6r5Q8fn53P67WgI9DzwNIc13jVd2Xal1Y/mM1+pKPOcX9+86Vtipcf1lQY/VwyjddX 7Xm1EktxRqKhFnNRcSIAQS6ZCXMCAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 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, 05 Aug 2016 11:41:28 -0000 Hello, COMMENT 2: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Usage of Call-Info: - in a response to an initial INVITE request; and - in a SIP INFO request sent from PSAP to the UE; is not aligned with semantic of call-info as defined in RFC3261: ----------------- The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. ----------------- In those cases, the Call-Info identifies a MIME body of application/Emergen= cyCallData.eCall.control+xml MIME type (draft-ietf-ecrit-ecall-11 section 6= , 4th paragraph and 9 and in Figure 9 and Figure 10), which carries: -------- A PSAP or IVS transmits >>a metadata/control object<< (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. >>The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message.<< -------- and -------- ... When the IVS includes an unsolicited MSD in a SIP request (e.g., the initial INVITE), the PSAP sends a metadata/control block indicating successful/unsuccessful receipt of the MSD in the SIP response to the request. =20 ... -------- In those cases, the MIME body indicates an delivery report (Figure 9) or re= quests an action to be performed at UAS (Figure 10). ///////////////////////////////////////////////////////////////////////////= /// PROPOSED SOLUTION to COMMENT 2 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Align the semantic of the Call-Info header field with RFC3261, remove usage= of Call-Info header field, or update RFC3261. ///////////////////////////////////////////////////////////////////////////= /// Kind regards Ivo Sedlacek From nobody Fri Aug 5 04:51:01 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 BB94412D808 for ; Fri, 5 Aug 2016 04:50:59 -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 vf3EcqTcPVEi for ; Fri, 5 Aug 2016 04:50:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 72F1912D7B5 for ; Fri, 5 Aug 2016 04:50:57 -0700 (PDT) X-AuditID: c1b4fb2d-bbfff70000000190-55-57a47d9e0c2d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id E1.FE.00400.E9D74A75; Fri, 5 Aug 2016 13:50:55 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 13:50:54 +0200 From: Ivo Sedlacek To: Roger Marshall , Christer Holmberg , "Marc Linsner (mlinsner)" Thread-Topic: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AQHR7kvmydFkH/618Umr9Eo1N8+wGaA4zh+AgAAAewCAAXOTwA== Date: Fri, 5 Aug 2016 11:50:53 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BEFDC@ESESSMB301.ericsson.se> References: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> <7594FB04B1934943A5C02806D1A2204B4771FA8F@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdV3d+7ZJwg3U7dC0aFz1ltTh7+Tqj xcJfv1gcmD2m/N7I6nFpSyu7x5IlP5kCmKO4bFJSczLLUov07RK4Mib+u81csEWq4tflDYwN jN9Fuxg5OCQETCTO/HfsYuTiEBJYzygx9eFJxi5GTiBnMaPE1sNhIDabgJ7ExC1HWEGKRARm MUps/7yPGSTBLKAqca7xMQuILSwQLvF+wRVWEFtEIELi/M3pbBC2k8T2lR2sIMtYBFQk2m+Z g4R5BXwl3n/fygqxuI9JYu6s7WD1nAKBEqd39YLZjAKyElf/9DJC7BKXuPVkPhOILSEgILFk z3lmCFtU4uXjf6wQtpLEjw2XWCDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKW WUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMHYObvmtu4Nx9WvHQ4wCHIxK PLwLmhaHC7EmlhVX5h5ilOBgVhLh7alZEi7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQ QHpiSWp2ampBahFMlomDU6qBUTlq6cm7LYXyTLVnEqd7He0WqV4wub/V0/y9sdOjF6JOe8zf XeOL/W++rHbGVkb+WacEI/hzeJjj3PpjJW9PeLqU97bhQZYnsspPYkUa0yvX3fj7l/FSasU6 njmW79Vt5nXZCc73nqfIHb9oloj6uZ//9EK2uGQE/8jmKFF+eUu7fuECrzYXJZbijERDLeai 4kQAu2joMZkCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 05 Aug 2016 11:50:59 -0000 Hello, I just raise two comments ("draft-ietf-ecrit-ecall-11- Call-Info usage brin= gs no value" and "draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wi= th RFC3261") against draft-ietf-ecrit-ecall-11. Please considered them as r= aised during WGLC for draft-ietf-ecrit-ecall. Kind regards Ivo Sedlacek -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Thursday, August 04, 2016 5:39 PM To: Christer Holmberg; Marc Linsner (mlinsner) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-= ecrit-car-crash-09 Thanks Christer for the heads up. -roger. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, August 04, 2016 8:38 AM To: Marc Linsner (mlinsner); Roger Marshall Cc: ecrit@ietf.org Subject: RE: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-ca= r-crash-09 Hi, I have provided comments to the authors. Many of my issues have been addres= sed, but there are still some issues that still need work. But, as I'm curr= ently on vacation I am slow with e-mails. I am not saying that should prevent the WGLC to be issued, but just to make= you aware. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlin= sner) Sent: 04 August 2016 15:29 To: Roger Marshall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-= ecrit-car-crash-09 No objections from me...... I'm wondering what Keith will have to say.... -Marc- Sent from my iPad > On Aug 3, 2016, at 7:10 PM, Roger Marshall wrote: >=20 > Changing subject line & resending. >=20 > *** >=20 > Our plan is to issue WGLC for both drafts soon, >=20 > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 >=20 > which have now been updated a couple of times to resolve all significant = issues (thanks Randy & Christer). =20 > Anyone have any objections to doing so? >=20 > Roger & Marc > ECRIT Chairs >=20 >=20 >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain infor= mation which is confidential, proprietary, attorney-client privileged and/o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient 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 pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. _______________________________________________ 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 Aug 5 07:43:10 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 F09CD12D885 for ; Fri, 5 Aug 2016 07:43:08 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 nQAh6UZXucWx for ; Fri, 5 Aug 2016 07:43:07 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 579D012D842 for ; Fri, 5 Aug 2016 07:43:06 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with SMTP id VgGib6qVy2NhqVgL3bBwlW; Fri, 05 Aug 2016 14:43:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id VgL2bgTHuCigVVgL3blkLd; Fri, 05 Aug 2016 14:43:05 +0000 To: ecrit@ietf.org References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> Date: Fri, 5 Aug 2016 10:43:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGP1Tn9acJFobWVMPG4SRuF4acHf2LzskLG3mXE5AHtPaFwuMTb3rHP1g8p65eYwP11sxubOmXcl1iiFLsII60SRBDcgqCc5tobenTJrPD9QpWO8NOog d38HjGeTP5pqvxSK87VJR/VsUGHyV64//MW2U6DZ/jMv7ER3nFR5uYfI7r6SrR8CrEBvlDy+IjV9Dw== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 14:43:09 -0000 Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecessary because the recipient will know what to do with the body even in the absence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other bodies or body parts was not well considered. Eventually this started to be a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Content-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I realize that there is one predominant reason for doing so, but that is not the only possible reason. (E.g., it might be included as context in an intended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely for the emergency call path, then alternatives may be of no concern. But ideally the call will largely be handled via standard library code that is also used for other call paths and other message processing. So processing body parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > Inclusion of Call-Info header field with > purpose=emergencyCallData.eCall.MSD or > purpose=emergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=emergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the > bodies of the INVITE request not marked with Content-Disposition: ...; > handling=optional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=emergencyCallData.eCall.control included in a > response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response to > the initial INVITE request so this does not seem to have any value for > the proxies > > - UAC includes Accept with supported MIME types in INVITE request so why > would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=emergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml MIME > body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=optional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////////////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////////////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Aug 5 07:46: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 3AF7212D89A for ; Fri, 5 Aug 2016 07:45:59 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ePfDhtc9Hy7L for ; Fri, 5 Aug 2016 07:45:57 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 AD2CB12D899 for ; Fri, 5 Aug 2016 07:45:57 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-07v.sys.comcast.net with SMTP id VgNCbB6lFqbrLVgNob8chu; Fri, 05 Aug 2016 14:45:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id VgNnbUNCtC5sCVgNobSpQl; Fri, 05 Aug 2016 14:45:56 +0000 To: ecrit@ietf.org References: <01C3E188-7311-4B1B-BB6E-61EBE35A1E8A@cisco.com> <7594FB04B1934943A5C02806D1A2204B4771FA8F@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164BEFDC@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <72bf9bdf-3289-f5c3-fffe-07c95c34dffe@alum.mit.edu> Date: Fri, 5 Aug 2016 10:45:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164BEFDC@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfD6pCmim9nRBzCBZuFBshHdzcXOOGd8wn0/U3no4g1oNW4lc++4mCLuNXX2aPoCNrOmedwZjG+EjPE1BhPxU+nwLQJo+n93ZeE9yTvdDgGP0hNMAk+Ua V87aZ7TylLaCzs82jzMfa2raIMNGugSeJHn21ibGgBBqOeeZeVqP4QxxKkzZ1xjmfzYef68e300yJg== Archived-At: Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 05 Aug 2016 14:45:59 -0000 I see the two as closely related. I replied to one. You can consider that reply to apply to the general discussion. Thanks, Paul On 8/5/16 7:50 AM, Ivo Sedlacek wrote: > Hello, > > I just raise two comments ("draft-ietf-ecrit-ecall-11- Call-Info usage brings no value" and "draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261") against draft-ietf-ecrit-ecall-11. Please considered them as raised during WGLC for draft-ietf-ecrit-ecall. > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: Thursday, August 04, 2016 5:39 PM > To: Christer Holmberg; Marc Linsner (mlinsner) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 > > Thanks Christer for the heads up. > > -roger. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, August 04, 2016 8:38 AM > To: Marc Linsner (mlinsner); Roger Marshall > Cc: ecrit@ietf.org > Subject: RE: Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 > > Hi, > > I have provided comments to the authors. Many of my issues have been addressed, but there are still some issues that still need work. But, as I'm currently on vacation I am slow with e-mails. > > I am not saying that should prevent the WGLC to be issued, but just to make you aware. > > Regards, > > Christer > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlinsner) > Sent: 04 August 2016 15:29 > To: Roger Marshall > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 > > No objections from me...... I'm wondering what Keith will have to say.... > > -Marc- > > Sent from my iPad > >> On Aug 3, 2016, at 7:10 PM, Roger Marshall wrote: >> >> Changing subject line & resending. >> >> *** >> >> Our plan is to issue WGLC for both drafts soon, >> >> draft-ietf-ecrit-ecall-11 >> draft-ietf-ecrit-car-crash-09 >> >> which have now been updated a couple of times to resolve all significant issues (thanks Randy & Christer). >> Anyone have any objections to doing so? >> >> Roger & Marc >> 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 > > _______________________________________________ > 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 Aug 5 08:00: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 460F312D513 for ; Fri, 5 Aug 2016 08:00:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wepvLuEBS_kN for ; Fri, 5 Aug 2016 08:00:43 -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 7669612D89A for ; Fri, 5 Aug 2016 08:00:43 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id u75F0Neg004174 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 5 Aug 2016 08:00:23 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0248.002; Fri, 5 Aug 2016 08:00:22 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: WGLC Announce: Data-Only Emergency Calls Thread-Index: AdHh/pGOyJxBPWiRSl6QnMmpW/luawNKzhMQ Date: Fri, 5 Aug 2016 15:00:22 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] WGLC Announce: Data-Only Emergency Calls 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, 05 Aug 2016 15:00:45 -0000 We received some comments on this draft during WGLC (thank you Guy Caron!).= We'd like to get more review comments, either things that need changing o= r a show of support. Please post to the list if you support this draft mov= ing ahead. Roger & Marc ECRIT Chairs -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, July 19, 2016 1:46 PM To: ecrit@ietf.org Subject: [Ecrit] WGLC Announce: Data-Only Emergency Calls Today starts a new working group last call for: Data-Only Emergency Calls http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Please review the document and send comments to the ECRIT mail list by CoB,= July 30, 2016. Thanks, Marc & Roger ECRIT Chairs _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 5 08:10: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 7EA4D12D8E0 for ; Fri, 5 Aug 2016 08:10:04 -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, 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 GBhNg7pepn_v for ; Fri, 5 Aug 2016 08:10:03 -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 2DB1612D105 for ; Fri, 5 Aug 2016 08:10:03 -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 u75F9pqj029371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 5 Aug 2016 08:09:51 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Fri, 5 Aug 2016 08:09:51 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change Thread-Index: AdHvKsi62k3+D/glTIKre9YaB1QRKg== Date: Fri, 5 Aug 2016 15:09:50 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change 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, 05 Aug 2016 15:10:04 -0000 Since we received no comments during open WGLC, we need to know whether you= support this lost-planned-changes draft moving forward toward IESG submiss= ion. Also, if you still would like to send comments to the list, please do= so along with your support for this draft. Roger & Marc ECRIT Chairs -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, July 19, 2016 1:52 PM To: ecrit@ietf.org Subject: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Ch= ange Today starts a working group last call for: Validation of Locations Around a Planned Change http://tools.ietf.org/html/= draft-ecrit-lost-planned-changes/ Please review the document and send comments to the ECRIT mail list by CoB,= July 30, 2016. Thanks, Marc & Roger ECRIT Chairs _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 5 08:12: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 F3EF612D541 for ; Fri, 5 Aug 2016 08:12:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 lzYA5OUtDr_N for ; Fri, 5 Aug 2016 08:12:08 -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 9F90D12D105 for ; Fri, 5 Aug 2016 08:12:08 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id u75FBx5o012240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 5 Aug 2016 08:12:00 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.50]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0248.002; Fri, 5 Aug 2016 08:11:59 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info Thread-Index: AdHh/5kM7KlxIdBsQ4SdBwiTXBZrqgNK9wXw Date: Fri, 5 Aug 2016 15:11:58 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info 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, 05 Aug 2016 15:12:10 -0000 We received no comments during WGLC for this similar-location draft, yet we= need to know whether you support this draft moving forward for IESG submis= sion. We'll still take comments along with your statement of support for t= his draft. Roger & Marc ECRIT Chairs -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, July 19, 2016 1:53 PM To: ecrit@ietf.org Subject: [Ecrit] WGLC Announce: A LoST extension to return complete and sim= ilar location info Today starts a working group last call for: A LoST extension to return complete and similar location info http://datatr= acker.ietf.org/doc/draft-ietf-ecrit-similar-location/ Please review the document and send comments to the ECRIT mail list by CoB,= July 30, 2016. Thanks, Marc & Roger ECRIT Chairs _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 5 08:14: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 04FD812D5CE for ; Fri, 5 Aug 2016 08:14: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 vx4Lot2JC5Jt for ; Fri, 5 Aug 2016 08:14:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 E3A4C12D145 for ; Fri, 5 Aug 2016 08:14:48 -0700 (PDT) X-AuditID: c1b4fb2d-bbfff70000000190-83-57a4ad656b17 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id D8.20.00400.56DA4A75; Fri, 5 Aug 2016 17:14:46 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 17:14:45 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR7yexZXEidAcmwUSilgoJSeYOa6A6eeKm Date: Fri, 5 Aug 2016 15:14:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se>, <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> In-Reply-To: <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BBA6C3DESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7vW7a2iXhBqsum1s0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj4sP3TAWr0iv67r1hbGCcF97FyMkhIWAi seTRLuYuRi4OIYH1jBJblr1lg3AWM0os+3WcsYuRg4NNwEKi+582SIOIgLfEn9/f2EBsYYFA ibWf9rJCxIMkrh88xw5hG0mcWX0ArIZFQEXi+5wtYDavgK/EvC1fmCDmNzJK7D0+hQUkwSng IDH7yXmwZkYBMYnvp9YwgdjMAuISTV9WskJcKiCxZM95ZghbVOLl43+sILcxC+RL7PkoAzFf UOLkzCcsExiFZiHpnoVQNQtJFUSJgcSX97ehbG2JZQtfM0PY+hLd708zIYsvYGRfxShanFpc nJtuZKyXWpSZXFycn6eXl1qyiREYJQe3/Nbdwbj6teMhRgEORiUe3gVNi8OFWBPLiitzDzFK cDArifAeXLMkXIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwen VAPjopRW002fj/4Py5Bc9eHH0a3f4vdN4j2jfyLo3aH5EWpSVek3FdmfTEmSKvSTOJavwrns 34POaiV5y7ojeYFrrafPy2ZVuWMtsrWc+6PYQ4eA3bdP+x/jetgjN18zcrlHr/uSfVXPbVxK D8pKrV8oqzK5Kmnb2olhk9sag31FFukcZJn7tJpZiaU4I9FQi7moOBEAgtHH1o4CAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 15:14:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBA6C3DESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Paul, In INFOs, the info package specification shall indicate WHY a message body = is included. That was one of the main reason for doing the info package mec= hanism. And, as Ivo also indicated, INFOs will be routed according to the establish= ed route set. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD05/=FD08/=FD2016 17:43 To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecessary because the recipient will know what to do with the body even in the absence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other bodies or body parts was not well considered. Eventually this started to be a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Content-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I realize that there is one predominant reason for doing so, but that is not the only possible reason. (E.g., it might be included as context in an intended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely for the emergency call path, then alternatives may be of no concern. But ideally the call will largely be handled via standard library code that is also used for other call paths and other message processing. So processing body parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the > bodies of the INVITE request not marked with Content-Disposition: ...; > handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in = a > response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response to > the initial INVITE request so this does not seem to have any value for > the proxies > > - UAC includes Accept with supported MIME types in INVITE request so why > would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml MIME > body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > /////////////////////////////////////////////////////////////////////////= ///// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\ > > Remove insertion of Call-Info header field. > > /////////////////////////////////////////////////////////////////////////= ///// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_7594FB04B1934943A5C02806D1A2204B4BBA6C3DESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Paul,

In INFOs, the info package specification shall indicate WHY a message body = is included. That was one of the main reason for doing the info package mec= hanism.

And, as Ivo also indicated, INFOs will be routed according to the establish= ed route set.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD05= /=FD08/=FD2016 17:43
To: ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
Ivo,

IIUC, you are saying that the Call-Info that refers to the body is
unnecessary because the recipient will know what to do with the body
even in the absence of the Call-Info. Is that right?

This assumption mixes up two things:
- understanding a body syntactically
- understanding *why* the body is present and how it should be used.

Historically, processing of body parts in sip was very poorly defined.
Initially the only body of interest was SDP, so how one might process
other bodies or body parts was not well considered. Eventually this
started to be a liability, so RFC5621 was published to clarify it.

Processing of body parts is governed by a complex interaction between
Content-Type, Content-Disposition, Content-ID.

So the call-info header indicates the reason that body is being
included. I realize that there is one predominant reason for doing so,
but that is not the only possible reason. (E.g., it might be included as context in an intended discussion about problems handling a call in the past.)

If all the handling of the call is coded in a special purpose way,
solely for the emergency call path, then alternatives may be of no
concern. But ideally the call will largely be handled via standard
library code that is also used for other call paths and other message
processing. So processing body parts in a "standard" way, rather = than
special casing, is desirable.

        Thanks,
        Paul

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
> Hello,
>
>
>
> COMMENT:
>
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\
>
> Inclusion of Call-Info header field with
> purpose=3DemergencyCallData.eCall.MSD or
> purpose=3DemergencyCallData.eCall.control in requests and responses do= es
> not seem to bring any value. It seems to only waste radio resources. >
>
>
> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in t= he
> initial INVITE request:
>
> - if this is meant to be used by a proxy for routing of the eCall
> emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and=
> the Recv-Info header field containing eCall specific info package
> (emergencyCallData.eCall.MSD).
>
> - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all t= he
> bodies of the INVITE request not marked with Content-Disposition: ...;=
> handling=3Doptional are understood. So,
> application/emergencyCallData.eCall.MSD+per MIME body will anyway = be
> found by UAS during the INVITE request processing.
>
>
>
> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in a
> response to the initial INVITE request
>
> - no routing decisions are done by proxies when receiving a response t= o
> the initial INVITE request so this does not seem to have any value for=
> the proxies
>
> - UAC includes Accept with supported MIME types in INVITE request so w= hy
> would UAS send any MIME body not wished by the UAC?
>
>
>
> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in
> the INFO request
>
> - no routing decisions are done by proxies when receiving an in-dialog=
> request so this does not seem to have any value for the proxies
>
> - support of info package emergencyCallData.eCall.MSD in the call
> implies that either application/EmergencyCallData.eCall.control+xm= l MIME
> body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway<= br> > needs to check that all the bodies of the INFO request not marked with=
> Content-Disposition: ...; handling=3Doptional are understood. So,
> application/EmergencyCallData.eCall.control+xml MIME body or
> application/emergencyCallData.eCall.MSD+per MIME body will anyway = be
> found by UAS during the INFO request processing.
>
> //////////////////////////////////////////////////////////////////////= ////////
>
> PROPOSED SOLUTION to COMMENT
>
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\
>
> Remove insertion of Call-Info header field.
>
> //////////////////////////////////////////////////////////////////////= ////////
>
>
>
> Kind regards
>
>
>
> Ivo Sedlacek
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit
 --_000_7594FB04B1934943A5C02806D1A2204B4BBA6C3DESESSMB208erics_-- From nobody Fri Aug 5 08:17: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 3AC6112D8F0 for ; Fri, 5 Aug 2016 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 5LVdIKuxxelb for ; Fri, 5 Aug 2016 08:17:26 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 4CF6112D8EF for ; Fri, 5 Aug 2016 08:17:24 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x25so175577593qtx.2 for ; Fri, 05 Aug 2016 08:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E7KoEsi0hMc45gDDJG/8XAplJhEjapMaNwxqlD4goMM=; b=kTUVFhQeSPH3cNfF2ziZO1toQiNaxJmpmJrbZyIadHrHWnfUG3OpQnGLCjn83HVuu0 VzvZujfM2X38STFV97PVXH2YeysAxcpaoLYTs2Ka8dsnuOLDEPN+ARS/9MkdzAp97tc0 oKZ0Cr0h5DqtmMxwbibLJoa/ml5vfGvS+Fq02/y/XJ2hURbYWqtXD9ODpWTtNZlWyCMe UrQ8R/KuOWkz1XL7HrDUD6FfDs0npvUnTMdSX/ZMGpCV5/xswSQITp/TlvSDp7Kk03mp 8SKviPdK7EJMhdFe3N1HnM4h8Plvdk/+TonGO0Z83AeBK/QkfylQsYA5j2TO7D9b8Zkf cZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E7KoEsi0hMc45gDDJG/8XAplJhEjapMaNwxqlD4goMM=; b=AXzlT7qApWApqu8aL6XTU1u02n8Qy5SX686oRXAEh/4E7kKZNmiV6GyvAVk8CNdvVp NfiK64spyDhn1Lesj9SPFQVUoUYff9h2ARf4qAalq8ZbxdLl/mEywo28PI5rGhF1tQJQ XFVtqkoTnQaE1cGibD5/vwlP3zX5G0t0zqUwwjMm6DMl+lEIyPm6ZAqASOmW6ipSl3Sm z/p/CdyzPGJJP1eo/xvL4nTRwwXoTYXo9YTSqxDsl8cxdG91EVSwQ9SWpLVbgjsUV8pW JgX/HN2V8yyUG4vhU1U6i/fvlyfBGcydH824zeQuGay4UZ1KOqAP5aoSO2Q8IOA2u/34 UnLw== X-Gm-Message-State: AEkooutWYtrace/KwPAzbrnK3UJa6lTajfz5Bj03AxPzy4D0AA2H4FD5CExK1MYBVtSMGw== X-Received: by 10.200.35.215 with SMTP id r23mr13529674qtr.140.1470410243354; Fri, 05 Aug 2016 08:17:23 -0700 (PDT) Received: from [10.33.193.6] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id y67sm9801550qka.45.2016.08.05.08.17.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 Aug 2016 08:17:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> Date: Fri, 5 Aug 2016 11:17:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 15:17:28 -0000 Also, since ecall is a form of =E2=80=9Cadditional data=E2=80=9D, it = should conform to the syntax for all the other additional data blocks = that may be included in the call. Brian > On Aug 5, 2016, at 10:43 AM, Paul Kyzivat = wrote: >=20 > Ivo, >=20 > IIUC, you are saying that the Call-Info that refers to the body is = unnecessary because the recipient will know what to do with the body = even in the absence of the Call-Info. Is that right? >=20 > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. >=20 > Historically, processing of body parts in sip was very poorly defined. = Initially the only body of interest was SDP, so how one might process = other bodies or body parts was not well considered. Eventually this = started to be a liability, so RFC5621 was published to clarify it. >=20 > Processing of body parts is governed by a complex interaction between = Content-Type, Content-Disposition, Content-ID. >=20 > So the call-info header indicates the reason that body is being = included. I realize that there is one predominant reason for doing so, = but that is not the only possible reason. (E.g., it might be included as = context in an intended discussion about problems handling a call in the = past.) >=20 > If all the handling of the call is coded in a special purpose way, = solely for the emergency call path, then alternatives may be of no = concern. But ideally the call will largely be handled via standard = library code that is also used for other call paths and other message = processing. So processing body parts in a "standard" way, rather than = special casing, is desirable. >=20 > Thanks, > Paul >=20 > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >>=20 >>=20 >>=20 >> COMMENT: >>=20 >> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\ >>=20 >> Inclusion of Call-Info header field with >> purpose=3DemergencyCallData.eCall.MSD or >> purpose=3DemergencyCallData.eCall.control in requests and responses = does >> not seem to bring any value. It seems to only waste radio resources. >>=20 >>=20 >>=20 >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in = the >> initial INVITE request: >>=20 >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI = and >> the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >>=20 >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all = the >> bodies of the INVITE request not marked with Content-Disposition: = ...; >> handling=3Doptional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >>=20 >>=20 >>=20 >> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in a >> response to the initial INVITE request >>=20 >> - no routing decisions are done by proxies when receiving a response = to >> the initial INVITE request so this does not seem to have any value = for >> the proxies >>=20 >> - UAC includes Accept with supported MIME types in INVITE request so = why >> would UAS send any MIME body not wished by the UAC? >>=20 >>=20 >>=20 >> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in >> the INFO request >>=20 >> - no routing decisions are done by proxies when receiving an = in-dialog >> request so this does not seem to have any value for the proxies >>=20 >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml = MIME >> body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked = with >> Content-Disposition: ...; handling=3Doptional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >>=20 >> = //////////////////////////////////////////////////////////////////////////= //// >>=20 >> PROPOSED SOLUTION to COMMENT >>=20 >> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\ >>=20 >> Remove insertion of Call-Info header field. >>=20 >> = //////////////////////////////////////////////////////////////////////////= //// >>=20 >>=20 >>=20 >> Kind regards >>=20 >>=20 >>=20 >> Ivo Sedlacek >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 5 08:27:57 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 775DD12D89F for ; Fri, 5 Aug 2016 08:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AIqqpOV2Ekg0 for ; Fri, 5 Aug 2016 08:27:54 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.119]) (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 AA85D12D5D7 for ; Fri, 5 Aug 2016 08:27:53 -0700 (PDT) Received: from [194.106.220.35] by server-15.bemta-14.messagelabs.com id EC/36-01659-770B4A75; Fri, 05 Aug 2016 15:27:51 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRWlGSWpSXmKPExsXi7PqsVbd8w5J wg1/nGC0aFz1ltVj46xeLA5PHpS2t7B5LlvxkCmCKYs3MS8qvSGDNuLZvFUvBQuGKC70T2BoY Dwt0MXJySAj4SfReusbWxcjFISSwh1Fiy9+XjBDOdUaJ5wcXMEM4pxgl5t+YCORwcLAJ6Elcf GUD0i0iECbRve4nE4gtLBAisfzfeSaIeKjEqn2XWSFsI4n2NfvZQWwWARWJ1a9Ps4HYvAI+Eu ++fgarERIIkPjy7TQLiM0pECix79gDRhCbUUBWYsPEb2BxZgFxiW9HVzJDXC0gsWTPeShbVOL l43+sELaBxNal+1ggbHmJbz9nMEL06kncmDqFDcLWlli28DUzxA2CEidnPoGql5Q4uOIGC8iL QgIyElu3KEK8PpNR4sn9P1A19hL/L/1gnMAoNQvJSbOQrJiFZMUsJCsWMLKsYtQoTi0qSy3SN TTTSyrKTM8oyU3MzNE1NDTRy00tLk5MT81JTCrWS87P3cQIjN56BgbGHYxfT3seYpTkYFIS5V 2XuCRciC8pP6UyI7E4I76oNCe1+BCjDAeHkgQv23qgnGBRanpqRVpmDjCNwKQlOHiURHifrAN K8xYXJOYWZ6ZDpE4xKkqJ8waD9AmAJDJK8+DaYKnrEqOslDAvIwMDgxBPQWpRbmYJqvwrRnEO RiVh3hyQKTyZeSVw018BLWYCWvzRCmxxSSJCSqqBUUdEWZCp/V8JSzwPT8WrE95Om64t/Px68 QT5xj99v1e8Nqi4MH++x6sVTMtPejc+XrlBzkVY7OPt2e9svXI3eHz+IGNwXq74X+8Uw/Z6qw cf4z+e0kxm70ws25zKpnbLS2/97YbtuwXCy2+F/evTWB+9ObmYc8EFQx7Gx6ujz7Bve2T12F7 0kBJLcUaioRZzUXEiAEnJVilYAwAA X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-15.tower-91.messagelabs.com!1470410854!45233508!6 X-Originating-IP: [67.69.230.133] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12290 invoked from network); 5 Aug 2016 15:27:50 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-15.tower-91.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 Aug 2016 15:27:50 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca Received: from DG2MBX01-WYN.bell.corp.bce.ca (198.235.102.32) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1076.9; Sat, 6 Aug 2016 00:16:03 -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; Fri, 5 Aug 2016 11:27:35 -0400 Received: from DG2MBX01-WYN.bell.corp.bce.ca ([fe80::71fd:9536:8cfc:aac1]) by DG2MBX01-WYN.bell.corp.bce.ca ([fe80::71fd:9536:8cfc:aac1%21]) with mapi id 15.00.1104.000; Fri, 5 Aug 2016 11:27:35 -0400 From: "Caron, Guy (A162859)" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change Thread-Index: AdHvKsi62k3+D/glTIKre9YaB1QRKgAAh/7w Date: Fri, 5 Aug 2016 15:27:35 +0000 Message-ID: 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.28.92.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning g.caron@bell.ca discourages use of 198.235.102.32 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca Archived-At: Subject: Re: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change 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, 05 Aug 2016 15:27:56 -0000 Roger, I did provide comments on this draft on July 26. Thanks for considering the= m before moving to IESG. Thanks, Guy -----Message d'origine----- De=A0: Ecrit [mailto:ecrit-bounces@ietf.org] De la part de Roger Marshall Envoy=E9=A0: 5 ao=FBt 2016 11:10 =C0=A0: ecrit@ietf.org Objet=A0: Re: [Ecrit] WGLC Announce: Validation of Locations Around a Plann= ed Change Since we received no comments during open WGLC, we need to know whether you= support this lost-planned-changes draft moving forward toward IESG submiss= ion. Also, if you still would like to send comments to the list, please do= so along with your support for this draft. Roger & Marc ECRIT Chairs -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: Tuesday, July 19, 2016 1:52 PM To: ecrit@ietf.org Subject: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Ch= ange Today starts a working group last call for: Validation of Locations Around a Planned Change http://tools.ietf.org/html/= draft-ecrit-lost-planned-changes/ Please review the document and send comments to the ECRIT mail list by CoB,= July 30, 2016. Thanks, Marc & Roger ECRIT Chairs _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit 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. _______________________________________________ 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 Aug 5 09:49: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 3A7E012D908 for ; Fri, 5 Aug 2016 09:49:58 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Pa8HjSJwuCTM for ; Fri, 5 Aug 2016 09:49:56 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 92F6712D906 for ; Fri, 5 Aug 2016 09:49:56 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with SMTP id ViH2bGA71xBKTViJnbNfKg; Fri, 05 Aug 2016 16:49:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id ViJmbs2Xrn4NUViJnbD3sV; Fri, 05 Aug 2016 16:49:55 +0000 To: Christer Holmberg , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 5 Aug 2016 12:49:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDAXqOSuwBSqANKYmJV5qYK4cdkYmDIxfGsI9cvYNRM0jOfEfWCS0ZEgFosESdnejmm7KOVkTW7oKEtb0hZinQnbtWTM280NaJNZsRATGoe+pT/awcV1 JHPdHXZXnCU69se6EiLVLgOh4pZvXgKZvvPgSiJPST8od1WN6C1DEkig7zgAQMH+LBwE6XJ4E1t2nzP3MIU15JlxFtx+3GlPh3QDx2ZSYDnwDRfv+1u5ORqA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 16:49:58 -0000 On 8/5/16 11:14 AM, Christer Holmberg wrote: > Hi Paul, > > In INFOs, the info package specification shall indicate WHY a message > body is included. That was one of the main reason for doing the info > package mechanism. > > And, as Ivo also indicated, INFOs will be routed according to the > established route set. I didn't think this was about INFO. I agree that in INFO, as long as the body is properly marked as the package body for the INFO that a call-info pointing to it isn't needed, and not appropriate. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý05/ý08/ý2016 17:43 > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is > unnecessary because the recipient will know what to do with the body > even in the absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. > Initially the only body of interest was SDP, so how one might process > other bodies or body parts was not well considered. Eventually this > started to be a liability, so RFC5621 was published to clarify it. > > Processing of body parts is governed by a complex interaction between > Content-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being > included. I realize that there is one predominant reason for doing so, > but that is not the only possible reason. (E.g., it might be included as > context in an intended discussion about problems handling a call in the > past.) > > If all the handling of the call is coded in a special purpose way, > solely for the emergency call path, then alternatives may be of no > concern. But ideally the call will largely be handled via standard > library code that is also used for other call paths and other message > processing. So processing body parts in a "standard" way, rather than > special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >> >> >> >> COMMENT: >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> >> Inclusion of Call-Info header field with >> purpose=emergencyCallData.eCall.MSD or >> purpose=emergencyCallData.eCall.control in requests and responses does >> not seem to bring any value. It seems to only waste radio resources. >> >> >> >> For Call-Info with purpose=emergencyCallData.eCall.MSD included in the >> initial INVITE request: >> >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI and >> the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >> >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the >> bodies of the INVITE request not marked with Content-Disposition: ...; >> handling=optional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >> >> >> >> For Call-Info with purpose=emergencyCallData.eCall.control included in a >> response to the initial INVITE request >> >> - no routing decisions are done by proxies when receiving a response to >> the initial INVITE request so this does not seem to have any value for >> the proxies >> >> - UAC includes Accept with supported MIME types in INVITE request so why >> would UAS send any MIME body not wished by the UAC? >> >> >> >> For Call-Info with purpose=emergencyCallData.eCall.control included in >> the INFO request >> >> - no routing decisions are done by proxies when receiving an in-dialog >> request so this does not seem to have any value for the proxies >> >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml MIME >> body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked with >> Content-Disposition: ...; handling=optional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >> >> ////////////////////////////////////////////////////////////////////////////// >> >> PROPOSED SOLUTION to COMMENT >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> >> Remove insertion of Call-Info header field. >> >> ////////////////////////////////////////////////////////////////////////////// >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> 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 Aug 5 11:45: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 718E312D79D for ; Fri, 5 Aug 2016 11:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 hLEoYcWeCDXd for ; Fri, 5 Aug 2016 11:45:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E977F12D169 for ; Fri, 5 Aug 2016 11:45:42 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u75IiTOc028020; Fri, 5 Aug 2016 14:45:41 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 24myp3hjw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 14:45:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75Ijeru017819; Fri, 5 Aug 2016 14:45:40 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75IjYLP017694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Aug 2016 14:45:37 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 5 Aug 2016 18:45:14 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.66]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 14:45:14 -0400 From: "STARK, BARBARA H" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change Thread-Index: AdHvKsi62k3+D/glTIKre9YaB1QRKgAHmRRA Date: Fri, 5 Aug 2016 18:45:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611426F9CF5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050221 Archived-At: Subject: Re: [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change 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, 05 Aug 2016 18:45:45 -0000 > Since we received no comments during open WGLC, we need to know > whether you support this lost-planned-changes draft moving forward toward > IESG submission. Also, if you still would like to send comments to the l= ist, > please do so along with your support for this draft. I've just finished reading this draft. I support it and have no substantive= comments. I sent Brian editorial nits, separately. Barbara From nobody Fri Aug 5 12:03: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 5772612D162 for ; Fri, 5 Aug 2016 12:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 1EpXwOWo0i-c for ; Fri, 5 Aug 2016 12:03:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.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 A51F712B019 for ; Fri, 5 Aug 2016 12:03:36 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u75IsccS014301; Fri, 5 Aug 2016 15:03:35 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 24myybuamt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 15:03:34 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75J3Wko010238; Fri, 5 Aug 2016 15:03:33 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75J3T5l010188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Aug 2016 15:03:30 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 5 Aug 2016 19:03:20 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.66]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 15:03:19 -0400 From: "STARK, BARBARA H" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: WGLC Announce: Data-Only Emergency Calls Thread-Index: AdHh/pGOyJxBPWiRSl6QnMmpW/luawNKzhMQAAhQ2sA= Date: Fri, 5 Aug 2016 19:03:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611426F9D75@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050223 Archived-At: Subject: Re: [Ecrit] WGLC Announce: Data-Only Emergency Calls 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, 05 Aug 2016 19:03:38 -0000 > We received some comments on this draft during WGLC (thank you Guy > Caron!). We'd like to get more review comments, either things that need > changing or a show of support. Please post to the list if you support th= is draft > moving ahead. I've read this draft and support it. I have no substantive comments, but se= nt editorial nits directly to the authors. I'll mention 2 of those nits her= e, though, just in case someone doesn't think they're nits. In Section 9: "...the usage of TLS is MANDATORY." "MANDATORY" is not a RFC 2119 word. I suggest "REQUIRED". In Section 8 Figure 3: " Call-ID: asd88asd77a@1.2.3.4" If "1.2.3.4" is supposed to represent an example IPv4 address, I suggest us= ing one of the IANA reserved-for-documentation address blocks (search for d= ocumentation at http://www.iana.org/assignments/iana-ipv4-special-registry/= iana-ipv4-special-registry.xhtml). If you really want to make IETF-powers-t= hat-be happy, change this to a documentation IPv6 address (http://www.iana.= org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml= ). =20 Barbara From nobody Fri Aug 5 12:12:19 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 7121012D0C9 for ; Fri, 5 Aug 2016 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 NoDDDsNVIs9C for ; Fri, 5 Aug 2016 12:12:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 198BF12B019 for ; Fri, 5 Aug 2016 12:12:16 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u75J8q8w016184; Fri, 5 Aug 2016 15:12:14 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 24myp3ngsj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 15:12:13 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75JCCf1018789; Fri, 5 Aug 2016 15:12:13 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u75JC7Im018686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Aug 2016 15:12:09 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 5 Aug 2016 19:11:52 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.66]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 15:11:52 -0400 From: "STARK, BARBARA H" To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info Thread-Index: AdHh/5kM7KlxIdBsQ4SdBwiTXBZrqgNK9wXwAAhWkBA= Date: Fri, 5 Aug 2016 19:11:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611426F9DDD@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050225 Archived-At: Subject: Re: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info 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, 05 Aug 2016 19:12:17 -0000 > We received no comments during WGLC for this similar-location draft, yet = we > need to know whether you support this draft moving forward for IESG > submission. We'll still take comments along with your statement of suppo= rt > for this draft. I've read and support. I've sent the authors the nits I found. I have one substantive comment. Section 6: " The verbose form is included in a later section [to be supplied in a later version of this draft]." No verbose form appears to be included in this draft, and it seems to be ge= tting a bit late for it to be supplied in a later version. I suggest either= removing this sentence or supplying the verbose form. Barbara From nobody Fri Aug 5 12:39: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 741F212D099 for ; Fri, 5 Aug 2016 12:39: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 lq8E4D7bap1d for ; Fri, 5 Aug 2016 12:39:23 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 4ED7E12D0AD for ; Fri, 5 Aug 2016 12:39:23 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-3e-57a4eb693ab9 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id DC.11.02493.96BE4A75; Fri, 5 Aug 2016 21:39:21 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 21:39:20 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR7zlmFDnYrToLfk2nO/1DVjgJbqA6w6tm Date: Fri, 5 Aug 2016 19:39:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBB030B@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.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_7594FB04B1934943A5C02806D1A2204B4BBB030BESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7q27m6yXhBmtuqFo0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjwsH5jAWL6iqavzs2MD7M6mLk5JAQMJF4 0rCFBcQWEljPKDH9ZXYXIxeQvZhRoq/zI3sXIwcHm4CFRPc/bZAaEQFviT+/v7GB2MICgRLr zq1hhIgHSfx8uB7KNpLYdOAmWA2LgIrE7XfTwObzCvhK7DmwhBli/m9GiWXP2phAEpwCDhLL Z2xlBrEZBcQkvp9aAxZnFhCXaPqykhXiUAGJJXvOM0PYohIvH/9jhajJl1iw8iMTxAJBiZMz n7BMYBSahaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82ELL6AkX0Vo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCUHNzy22oH48HnjocYBTgYlXh4Fa4sCRdiTSwrrsw9xCjBwawk wsv9CijEm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBcXHm PHklzuajmjcqrvInrJQ8++jCC7bbNx+ZiK+a0phT/exg9fmyVb77v84v6+AxzeSr7WjVyYu1 +GDad1lV6cNhiTl5Hz72qpid28fhcNThxeV1xtEf5lwO1yrss1RiuqaVeV4oMPZO0oxHpfaH 0zUvHo66Z8/5k41T2IapUWJ24SqFZ61eSizFGYmGWsxFxYkAtLmxh44CAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 19:39:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBB030BESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, As far as I understand, usage of Call-Info is defined for both INVITE and I= NFO. I have not read the latest version of the draft, though, so please dis= card my comment if that's not the case. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD05/=FD08/=FD2016 19:49 To: Christer Holmberg; ecrit@ietf.or= g Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue On 8/5/16 11:14 AM, Christer Holmberg wrote: > Hi Paul, > > In INFOs, the info package specification shall indicate WHY a message > body is included. That was one of the main reason for doing the info > package mechanism. > > And, as Ivo also indicated, INFOs will be routed according to the > established route set. I didn't think this was about INFO. I agree that in INFO, as long as the body is properly marked as the package body for the INFO that a call-info pointing to it isn't needed, and not appropriate. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: =FD05/=FD08/=FD2016 17:43 > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is > unnecessary because the recipient will know what to do with the body > even in the absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. > Initially the only body of interest was SDP, so how one might process > other bodies or body parts was not well considered. Eventually this > started to be a liability, so RFC5621 was published to clarify it. > > Processing of body parts is governed by a complex interaction between > Content-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being > included. I realize that there is one predominant reason for doing so, > but that is not the only possible reason. (E.g., it might be included as > context in an intended discussion about problems handling a call in the > past.) > > If all the handling of the call is coded in a special purpose way, > solely for the emergency call path, then alternatives may be of no > concern. But ideally the call will largely be handled via standard > library code that is also used for other call paths and other message > processing. So processing body parts in a "standard" way, rather than > special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >> >> >> >> COMMENT: >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Inclusion of Call-Info header field with >> purpose=3DemergencyCallData.eCall.MSD or >> purpose=3DemergencyCallData.eCall.control in requests and responses does >> not seem to bring any value. It seems to only waste radio resources. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the >> initial INVITE request: >> >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI and >> the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >> >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the >> bodies of the INVITE request not marked with Content-Disposition: ...; >> handling=3Doptional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in= a >> response to the initial INVITE request >> >> - no routing decisions are done by proxies when receiving a response to >> the initial INVITE request so this does not seem to have any value for >> the proxies >> >> - UAC includes Accept with supported MIME types in INVITE request so why >> would UAS send any MIME body not wished by the UAC? >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in >> the INFO request >> >> - no routing decisions are done by proxies when receiving an in-dialog >> request so this does not seem to have any value for the proxies >> >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml MIME >> body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked with >> Content-Disposition: ...; handling=3Doptional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> PROPOSED SOLUTION to COMMENT >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Remove insertion of Call-Info header field. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> 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 --_000_7594FB04B1934943A5C02806D1A2204B4BBB030BESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

As far as I understand, usage of Call-Info is defined for both INVITE and I= NFO. I have not read the latest version of the draft, though, so please dis= card my comment if that's not the case.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD05= /=FD08/=FD2016 19:49
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
On 8/5/16 11:14 AM, Christer Holmberg wrote:
> Hi Paul,
>
> In INFOs, the info package specification shall indicate WHY a message<= br> > body is included. That was one of the main reason for doing the info > package mechanism.
>
> And, as Ivo also indicated, INFOs will be routed according to the
> established route set.

I didn't think this was about INFO. I agree that in INFO, as long as the body is properly marked as the package body for the INFO that a
call-info pointing to it isn't needed, and not appropriate.

        Thanks,
        Paul

> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------= --
> From: Paul Kyzivat <mailto= :pkyzivat@alum.mit.edu>
> Sent: =FD05/=FD08/=FD2016 17:43
> To: ecrit@ietf.org <mailto:ecrit@= ietf.org>
> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings=
> no value
>
> Ivo,
>
> IIUC, you are saying that the Call-Info that refers to the body is
> unnecessary because the recipient will know what to do with the body > even in the absence of the Call-Info. Is that right?
>
> This assumption mixes up two things:
> - understanding a body syntactically
> - understanding *why* the body is present and how it should be used. >
> Historically, processing of body parts in sip was very poorly defined.=
> Initially the only body of interest was SDP, so how one might process<= br> > other bodies or body parts was not well considered. Eventually this > started to be a liability, so RFC5621 was published to clarify it.
>
> Processing of body parts is governed by a complex interaction between<= br> > Content-Type, Content-Disposition, Content-ID.
>
> So the call-info header indicates the reason that body is being
> included. I realize that there is one predominant reason for doing so,=
> but that is not the only possible reason. (E.g., it might be included = as
> context in an intended discussion about problems handling a call in th= e
> past.)
>
> If all the handling of the call is coded in a special purpose way,
> solely for the emergency call path, then alternatives may be of no
> concern. But ideally the call will largely be handled via standard
> library code that is also used for other call paths and other message<= br> > processing. So processing body parts in a "standard" way, ra= ther than
> special casing, is desirable.
>
>         Thanks,
>         Paul
>
> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
>> Hello,
>>
>>
>>
>> COMMENT:
>>
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>>
>> Inclusion of Call-Info header field with
>> purpose=3DemergencyCallData.eCall.MSD or
>> purpose=3DemergencyCallData.eCall.control in requests and response= s does
>> not seem to bring any value. It seems to only waste radio resource= s.
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included = in the
>> initial INVITE request:
>>
>> - if this is meant to be used by a proxy for routing of the eCall<= br> >> emergency call to a PSAP supporting eCall emergency call, then thi= s
>> seems to be redundant to the eCall URN included in the Request-URI= and
>> the Recv-Info header field containing eCall specific info package<= br> >> (emergencyCallData.eCall.MSD).
>>
>> - if this is meant to be used by UAS (i.e. PSAP), then according t= o
>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that a= ll the
>> bodies of the INVITE request not marked with Content-Disposition: = ...;
>> handling=3Doptional are understood. So,
>> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INVITE request processing.
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in a
>> response to the initial INVITE request
>>
>> - no routing decisions are done by proxies when receiving a respon= se to
>> the initial INVITE request so this does not seem to have any value= for
>> the proxies
>>
>> - UAC includes Accept with supported MIME types in INVITE request = so why
>> would UAS send any MIME body not wished by the UAC?
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in
>> the INFO request
>>
>> - no routing decisions are done by proxies when receiving an in-di= alog
>> request so this does not seem to have any value for the proxies >>
>> - support of info package emergencyCallData.eCall.MSD in the call<= br> >> implies that either application/EmergencyCallData.eCall.control= 3;xml MIME
>> body or application/emergencyCallData.eCall.MSD+per MIME body = is
>> included. Again, according to RFC3261 subclause 8.2.3, the UAS any= way
>> needs to check that all the bodies of the INFO request not marked = with
>> Content-Disposition: ...; handling=3Doptional are understood. So,<= br> >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INFO request processing.
>>
>> //////////////////////////////////////////////////////////////////= ////////////
>>
>> PROPOSED SOLUTION to COMMENT
>>
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>>
>> Remove insertion of Call-Info header field.
>>
>> //////////////////////////////////////////////////////////////////= ////////////
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Ivo Sedlacek
>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/ecrit
>>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ecrit

 --_000_7594FB04B1934943A5C02806D1A2204B4BBB030BESESSMB208erics_-- From nobody Fri Aug 5 12:57:56 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 30C7412D18A for ; Fri, 5 Aug 2016 12:57: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 dJARyW9nBUS6 for ; Fri, 5 Aug 2016 12:57:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5150412B01B for ; Fri, 5 Aug 2016 12:57:49 -0700 (PDT) X-AuditID: c1b4fb2d-bbfff70000000190-31-57a4efb9b867 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id EF.BA.00400.9BFE4A75; Fri, 5 Aug 2016 21:57:47 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 21:57:44 +0200 From: Christer Holmberg To: Brian Rosen , Paul Kyzivat Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR7yexZXEidAcmwUSilgoJSeYOa6A6WROAgABv4AY= Date: Fri, 5 Aug 2016 19:57:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBB146A@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu>, 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_7594FB04B1934943A5C02806D1A2204B4BBB146AESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7iu7u90vCDR6cZLd4en8am0Xjoqes Fis2HGB1YPb4+/4Dk8f9b3/ZPZYs+ckUwBzFZZOSmpNZllqkb5fAldE9NbXgaGnF2y8H2BoY dyd3MXJySAiYSLT+ucrexcjFISSwnlHi/dL3TBDOYkaJgwv6gBwODjYBC4nuf9ogDSICnhJz H05nBLGZBVQlzjU+ZgGxhQUCJdZ+2ssKURMkcf3gOXYI20pi1eFNTCA2i4CKxMXFm9hAbF4B X4mzrYtYIXbtZJS42dMONpRTwEni6Ib7YM2MAmIS30+tYYJYJi7R9GUlK8TVAhJL9pxnhrBF JV4+/scKUZMvse/6HRaIBYISJ2c+YZnAKDwLSfssJGWzkJRBxA0kvry/DWVrSyxb+JoZwtaX 6H5/mglZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwJg6uOW37g7G1a8dDzEKcDAq 8fAqXFkSLsSaWFZcmXuIUYKDWUmE99A7oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC 6YklqdmpqQWpRTBZJg5OqQZGBVc5vjdzJxxcV6K3ryy+UXDTk7++C7n/bnLna33OsFh6gvI5 aXalvw9+/X79LrrIJOr0roJnIlas4orXfzWrhesc8y+xanR41ModbNg2//+G5YXtWZ+lAh5K Kr+JX8LP65mUW7e6cef6Bvd9dv4fHqz4+umjpV3AXTuzdzq3oj0qL2/i2D5DiaU4I9FQi7mo OBEAWcGFvKUCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 19:57:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBB146AESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Brian, As far as I remember, additional data does not say anything about info pack= ages. The text might be general, but whenever you are going to use an info = package you must define an info package specification that describes the de= tails associated with that info package. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: =FD05/=FD08/=FD2016 18:17 To: Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Also, since ecall is a form of =93additional data=94, it should conform to = the syntax for all the other additional data blocks that may be included in= the call. Brian > On Aug 5, 2016, at 10:43 AM, Paul Kyzivat wrote: > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is unnece= ssary because the recipient will know what to do with the body even in the = absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. In= itially the only body of interest was SDP, so how one might process other b= odies or body parts was not well considered. Eventually this started to be = a liability, so RFC5621 was published to clarify it. > > Processing of body parts is governed by a complex interaction between Con= tent-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being included.= I realize that there is one predominant reason for doing so, but that is n= ot the only possible reason. (E.g., it might be included as context in an i= ntended discussion about problems handling a call in the past.) > > If all the handling of the call is coded in a special purpose way, solely= for the emergency call path, then alternatives may be of no concern. But i= deally the call will largely be handled via standard library code that is a= lso used for other call paths and other message processing. So processing b= ody parts in a "standard" way, rather than special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >> >> >> >> COMMENT: >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Inclusion of Call-Info header field with >> purpose=3DemergencyCallData.eCall.MSD or >> purpose=3DemergencyCallData.eCall.control in requests and responses does >> not seem to bring any value. It seems to only waste radio resources. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the >> initial INVITE request: >> >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI and >> the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >> >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the >> bodies of the INVITE request not marked with Content-Disposition: ...; >> handling=3Doptional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in= a >> response to the initial INVITE request >> >> - no routing decisions are done by proxies when receiving a response to >> the initial INVITE request so this does not seem to have any value for >> the proxies >> >> - UAC includes Accept with supported MIME types in INVITE request so why >> would UAS send any MIME body not wished by the UAC? >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in >> the INFO request >> >> - no routing decisions are done by proxies when receiving an in-dialog >> request so this does not seem to have any value for the proxies >> >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml MIME >> body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked with >> Content-Disposition: ...; handling=3Doptional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> PROPOSED SOLUTION to COMMENT >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Remove insertion of Call-Info header field. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_7594FB04B1934943A5C02806D1A2204B4BBB146AESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Brian,

As far as I remember, additional data does not say anything about info pack= ages. The text might be general, but whenever you are going to use an info = package you must define an info package specification that describes the de= tails associated with that info package.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: =FD05= /=FD08/=FD2016 18:17
To: Paul Kyzivat
Cc: ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
Also, since ecall is a form of =93additional data= =94, it should conform to the syntax for all the other additional data bloc= ks that may be included in the call.

Brian

> On Aug 5, 2016, at 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
>
> Ivo,
>
> IIUC, you are saying that the Call-Info that refers to the body is unn= ecessary because the recipient will know what to do with the body even in t= he absence of the Call-Info. Is that right?
>
> This assumption mixes up two things:
> - understanding a body syntactically
> - understanding *why* the body is present and how it should be used. >
> Historically, processing of body parts in sip was very poorly defined.= Initially the only body of interest was SDP, so how one might process othe= r bodies or body parts was not well considered. Eventually this started to = be a liability, so RFC5621 was published to clarify it.
>
> Processing of body parts is governed by a complex interaction between = Content-Type, Content-Disposition, Content-ID.
>
> So the call-info header indicates the reason that body is being includ= ed. I realize that there is one predominant reason for doing so, but that i= s not the only possible reason. (E.g., it might be included as context in a= n intended discussion about problems handling a call in the past.)
>
> If all the handling of the call is coded in a special purpose way, sol= ely for the emergency call path, then alternatives may be of no concern. Bu= t ideally the call will largely be handled via standard library code that i= s also used for other call paths and other message processing. So processing body parts in a "standard&quo= t; way, rather than special casing, is desirable.
>
>        Thanks,
>        Paul
>
> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
>> Hello,
>>
>>
>>
>> COMMENT:
>>
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>>
>> Inclusion of Call-Info header field with
>> purpose=3DemergencyCallData.eCall.MSD or
>> purpose=3DemergencyCallData.eCall.control in requests and response= s does
>> not seem to bring any value. It seems to only waste radio resource= s.
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included = in the
>> initial INVITE request:
>>
>> - if this is meant to be used by a proxy for routing of the eCall<= br> >> emergency call to a PSAP supporting eCall emergency call, then thi= s
>> seems to be redundant to the eCall URN included in the Request-URI= and
>> the Recv-Info header field containing eCall specific info package<= br> >> (emergencyCallData.eCall.MSD).
>>
>> - if this is meant to be used by UAS (i.e. PSAP), then according t= o
>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that a= ll the
>> bodies of the INVITE request not marked with Content-Disposition: = ...;
>> handling=3Doptional are understood. So,
>> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INVITE request processing.
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in a
>> response to the initial INVITE request
>>
>> - no routing decisions are done by proxies when receiving a respon= se to
>> the initial INVITE request so this does not seem to have any value= for
>> the proxies
>>
>> - UAC includes Accept with supported MIME types in INVITE request = so why
>> would UAS send any MIME body not wished by the UAC?
>>
>>
>>
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in
>> the INFO request
>>
>> - no routing decisions are done by proxies when receiving an in-di= alog
>> request so this does not seem to have any value for the proxies >>
>> - support of info package emergencyCallData.eCall.MSD in the call<= br> >> implies that either application/EmergencyCallData.eCall.control= 3;xml MIME
>> body or application/emergencyCallData.eCall.MSD+per MIME body = is
>> included. Again, according to RFC3261 subclause 8.2.3, the UAS any= way
>> needs to check that all the bodies of the INFO request not marked = with
>> Content-Disposition: ...; handling=3Doptional are understood. So,<= br> >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INFO request processing.
>>
>> //////////////////////////////////////////////////////////////////= ////////////
>>
>> PROPOSED SOLUTION to COMMENT
>>
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>>
>> Remove insertion of Call-Info header field.
>>
>> //////////////////////////////////////////////////////////////////= ////////////
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Ivo Sedlacek
>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/ecrit
>>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit
 --_000_7594FB04B1934943A5C02806D1A2204B4BBB146AESESSMB208erics_-- From nobody Fri Aug 5 14:02: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 B0C3A12D1C1 for ; Fri, 5 Aug 2016 14:02:34 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 hyKqQjsIMEz3 for ; Fri, 5 Aug 2016 14:02:31 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 757B212B076 for ; Fri, 5 Aug 2016 14:02:31 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 52so180037256qtq.3 for ; Fri, 05 Aug 2016 14:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=OLAcyfaDKBItmJzwyTbTYLorsz1it6jGwipoKf/264s=; b=j4BdaCHsxo/CmEKNaH/Ape1NP9/QMKrr/Ky3JhdlsFh4VxQNX+Oc/JS/dN5lSVMz5D 3r4nPnYZrIOQx5C27RjMZJcR2rxjPEDQBshbsFtO0Z4vQa0sKqkC2JTCVx7PSrD5m2xV FJCKOeXAbjExRva6Ty1O6Sz4Unv6gueGyWiDsoiMdkgLrCrLPZNB3gpSdxvVTyhiq2uJ Vm6s8794QJYW4GY5ZWxZszbqJ7Hxi32wQghBmlimP49JrH13t2/Z+r3z9n+pAzkiJZfk mH0fpwe980Xg02FLaeZxtBjob6xnDoqmxXEddzCET3jJNdpoe0GA4yzDtEh3pw5Mden5 h//Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OLAcyfaDKBItmJzwyTbTYLorsz1it6jGwipoKf/264s=; b=Aqt6HFaEwWrkHomViBLQuWNXjR+lX7Gluf3ZKKzDbPZVLWYNuP2VzmaKntWVW2z3eN Ajv9bh0aGIbYV6tiaw3xwwIoUUqTCthaoC3oJXEENsdV6yMu5gIFJ/HyajMj+3Kg52pT KzkJABdl+fLS7YSHteeOqbrb4AovKWmCLPdYcZQWJOsbrIf46Ainknb0PfapxyiCu5+S YflP4HQbd8RddWYext6Lmiy4AXR/A4vGOBTZbfm9dCcAiTe5lD9EjuIuwgtMo5oR9d4N Ubf8shYhRv2Ub1dMTVI0YS/UoVWE9FNAbcHvDKUIg6SI9wWjKd75XITGKUZAv3qr9lQG yA6w== X-Gm-Message-State: AEkoouvqidiZmm9hM3omKAN0n/T2rWclhHQtZiBybU5YBipxzkI6PUsKAbRL7ybHp3LfSQ== X-Received: by 10.200.53.214 with SMTP id l22mr15140015qtb.117.1470430950439; Fri, 05 Aug 2016 14:02:30 -0700 (PDT) Received: from [10.33.193.6] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id i13sm10604990qte.42.2016.08.05.14.02.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 Aug 2016 14:02:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1ABD9A35-F791-470F-B011-CBC1F5348A01" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBB146A@ESESSMB208.ericsson.se> Date: Fri, 5 Aug 2016 17:02:26 -0400 Message-Id: <58760FC9-AA8B-4BB8-B9E2-C994C12D1EA5@brianrosen.net> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBB146A@ESESSMB208.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 21:02:35 -0000 --Apple-Mail=_1ABD9A35-F791-470F-B011-CBC1F5348A01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure. But the INFO is a way to send additional data update in the middle of a = session. You don=E2=80=99t use it with the INVITE. I=E2=80=99d like the mechanisms to be as similar as possible. Brian > On Aug 5, 2016, at 3:57 PM, Christer Holmberg = wrote: >=20 > Hi Brian, >=20 > As far as I remember, additional data does not say anything about info = packages. The text might be general, but whenever you are going to use = an info package you must define an info package specification that = describes the details associated with that info package. >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Brian Rosen > Sent: =E2=80=8E05/=E2=80=8E08/=E2=80=8E2016 18:17 > To: Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings = no value >=20 > Also, since ecall is a form of =E2=80=9Cadditional data=E2=80=9D, it = should conform to the syntax for all the other additional data blocks = that may be included in the call. >=20 > Brian >=20 > > On Aug 5, 2016, at 10:43 AM, Paul Kyzivat > wrote: > >=20 > > Ivo, > >=20 > > IIUC, you are saying that the Call-Info that refers to the body is = unnecessary because the recipient will know what to do with the body = even in the absence of the Call-Info. Is that right? > >=20 > > This assumption mixes up two things: > > - understanding a body syntactically > > - understanding *why* the body is present and how it should be used. > >=20 > > Historically, processing of body parts in sip was very poorly = defined. Initially the only body of interest was SDP, so how one might = process other bodies or body parts was not well considered. Eventually = this started to be a liability, so RFC5621 was published to clarify it. > >=20 > > Processing of body parts is governed by a complex interaction = between Content-Type, Content-Disposition, Content-ID. > >=20 > > So the call-info header indicates the reason that body is being = included. I realize that there is one predominant reason for doing so, = but that is not the only possible reason. (E.g., it might be included as = context in an intended discussion about problems handling a call in the = past.) > >=20 > > If all the handling of the call is coded in a special purpose way, = solely for the emergency call path, then alternatives may be of no = concern. But ideally the call will largely be handled via standard = library code that is also used for other call paths and other message = processing. So processing body parts in a "standard" way, rather than = special casing, is desirable. > >=20 > > Thanks, > > Paul > >=20 > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > >> Hello, > >>=20 > >>=20 > >>=20 > >> COMMENT: > >>=20 > >> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\ > >>=20 > >> Inclusion of Call-Info header field with > >> purpose=3DemergencyCallData.eCall.MSD or > >> purpose=3DemergencyCallData.eCall.control in requests and responses = does > >> not seem to bring any value. It seems to only waste radio = resources. > >>=20 > >>=20 > >>=20 > >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included = in the > >> initial INVITE request: > >>=20 > >> - if this is meant to be used by a proxy for routing of the eCall > >> emergency call to a PSAP supporting eCall emergency call, then this > >> seems to be redundant to the eCall URN included in the Request-URI = and > >> the Recv-Info header field containing eCall specific info package > >> (emergencyCallData.eCall.MSD). > >>=20 > >> - if this is meant to be used by UAS (i.e. PSAP), then according to > >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that = all the > >> bodies of the INVITE request not marked with Content-Disposition: = ...; > >> handling=3Doptional are understood. So, > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway = be > >> found by UAS during the INVITE request processing. > >>=20 > >>=20 > >>=20 > >> For Call-Info with purpose=3DemergencyCallData.eCall.control = included in a > >> response to the initial INVITE request > >>=20 > >> - no routing decisions are done by proxies when receiving a = response to > >> the initial INVITE request so this does not seem to have any value = for > >> the proxies > >>=20 > >> - UAC includes Accept with supported MIME types in INVITE request = so why > >> would UAS send any MIME body not wished by the UAC? > >>=20 > >>=20 > >>=20 > >> For Call-Info with purpose=3DemergencyCallData.eCall.control = included in > >> the INFO request > >>=20 > >> - no routing decisions are done by proxies when receiving an = in-dialog > >> request so this does not seem to have any value for the proxies > >>=20 > >> - support of info package emergencyCallData.eCall.MSD in the call > >> implies that either application/EmergencyCallData.eCall.control+xml = MIME > >> body or application/emergencyCallData.eCall.MSD+per MIME body is > >> included. Again, according to RFC3261 subclause 8.2.3, the UAS = anyway > >> needs to check that all the bodies of the INFO request not marked = with > >> Content-Disposition: ...; handling=3Doptional are understood. So, > >> application/EmergencyCallData.eCall.control+xml MIME body or > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway = be > >> found by UAS during the INFO request processing. > >>=20 > >> = //////////////////////////////////////////////////////////////////////////= //// > >>=20 > >> PROPOSED SOLUTION to COMMENT > >>=20 > >> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\ > >>=20 > >> Remove insertion of Call-Info header field. > >>=20 > >> = //////////////////////////////////////////////////////////////////////////= //// > >>=20 > >>=20 > >>=20 > >> Kind regards > >>=20 > >>=20 > >>=20 > >> Ivo Sedlacek > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit = > >>=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit = >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_1ABD9A35-F791-470F-B011-CBC1F5348A01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure.

But = the INFO is a way to send additional data update in the middle of a = session.

You = don=E2=80=99t use it with the INVITE.

I=E2=80=99d like the mechanisms to be = as similar as possible.

Brian

On Aug 5, 2016, at 3:57 PM, = Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi= Brian,

As far as I remember, additional = data does not say anything about info packages. The text might be = general, but whenever you are going to use an info package you must = define an info package specification that describes the details = associated with that info package.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: =E2=80=8E05/=E2=80=8E08/=E2=80=8E2016 18:17
To: Paul = Kyzivat
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings = no value

Also, since ecall is a form of =E2=80=9Cadditional = data=E2=80=9D, it should conform to the syntax for all the other = additional data blocks that may be included in the call.
Brian

> On Aug 5, 2016, at = 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Ivo,
> 
> IIUC, you are saying that the Call-Info that refers to = the body is unnecessary because the recipient will know what to do with = the body even in the absence of the Call-Info. Is that right?
> 
> This assumption mixes up two things:
> = - understanding a body syntactically
> - understanding = *why* the body is present and how it should be used.
> 
> Historically, processing of body parts in sip was very = poorly defined. Initially the only body of interest was SDP, so how one = might process other bodies or body parts was not well considered. = Eventually this started to be a liability, so RFC5621 was published to = clarify it.
> 
> = Processing of body parts is governed by a complex interaction between = Content-Type, Content-Disposition, Content-ID.
> 
> So the = call-info header indicates the reason that body is being included. I = realize that there is one predominant reason for doing so, but that is = not the only possible reason. (E.g., it might be included as context in = an intended discussion about problems handling a call in the past.)
> 
> If all the handling of the call is coded in a special = purpose way, solely for the emergency call path, then alternatives may = be of no concern. But ideally the call will largely be handled via = standard library code that is also used for other call paths and other = message processing. So processing body parts in a "standard" way, rather = than special casing, is desirable.
> 
>        Thanks,
>        Paul
> 
> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
>> Hello,
>> 
>> 
>> 
>> = COMMENT:
>> 
>> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\
>> 
>> = Inclusion of Call-Info header field with
>> = purpose=3DemergencyCallData.eCall.MSD or
>> = purpose=3DemergencyCallData.eCall.control in requests and responses = does
>> not seem to bring any value. It seems to = only waste radio resources.
>> 
>> 
>> 
>> For = Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the
>> initial INVITE request:
>> 
>> - = if this is meant to be used by a proxy for routing of the eCall
>> emergency call to a PSAP supporting eCall emergency = call, then this
>> seems to be redundant to the = eCall URN included in the Request-URI and
>> the = Recv-Info header field containing eCall specific info package
>> (emergencyCallData.eCall.MSD).
>> 
>> - if this is meant to be used by UAS (i.e. PSAP), = then according to
>> RFC3261 subclause 8.2.3, then = the UAS anyway needs to check that all the
>> bodies = of the INVITE request not marked with Content-Disposition: ...;
>> handling=3Doptional are understood. So,
>> application/emergencyCallData.eCall.MSD+per MIME = body will anyway be
>> found by UAS during the = INVITE request processing.
>> 
>> 
>> 
>> For = Call-Info with purpose=3DemergencyCallData.eCall.control included in = a
>> response to the initial INVITE request
>> 
>> - no routing decisions are done by proxies when = receiving a response to
>> the initial INVITE = request so this does not seem to have any value for
>>= the proxies
>> 
>> - = UAC includes Accept with supported MIME types in INVITE request so = why
>> would UAS send any MIME body not wished by = the UAC?
>> 
>> 
>> 
>> For = Call-Info with purpose=3DemergencyCallData.eCall.control included in
>> the INFO request
>> 
>> - = no routing decisions are done by proxies when receiving an in-dialog
>> request so this does not seem to have any value for = the proxies
>> 
>> - = support of info package emergencyCallData.eCall.MSD in the call
>> implies that either = application/EmergencyCallData.eCall.control+xml MIME
>> body or application/emergencyCallData.eCall.MSD+per = MIME body is
>> included. Again, according to = RFC3261 subclause 8.2.3, the UAS anyway
>> needs to = check that all the bodies of the INFO request not marked with
>> Content-Disposition: ...; handling=3Doptional are = understood. So,
>> = application/EmergencyCallData.eCall.control+xml MIME body or
>> application/emergencyCallData.eCall.MSD+per MIME = body will anyway be
>> found by UAS during the INFO = request processing.
>> 
>> = //////////////////////////////////////////////////////////////////////////= ////
>> 
>> = PROPOSED SOLUTION to COMMENT
>> 
>> = \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\
>> 
>> = Remove insertion of Call-Info header field.
>> 
>> = //////////////////////////////////////////////////////////////////////////= ////
>> 
>> 
>> 
>> = Kind regards
>> 
>> 
>> 
>> Ivo = Sedlacek
>> 
>> 
>> 
>> = _______________________________________________
>> = Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_1ABD9A35-F791-470F-B011-CBC1F5348A01-- From nobody Fri Aug 5 15:06: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 38E6912D0B4 for ; Fri, 5 Aug 2016 15:06:08 -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 s-KOC6nhIsMr for ; Fri, 5 Aug 2016 15:06:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8106112B01E for ; Fri, 5 Aug 2016 15:06:05 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-92-57a50dcbcb34 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id E0.BC.04209.BCD05A75; Sat, 6 Aug 2016 00:06:03 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Sat, 6 Aug 2016 00:06:02 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR71yvYtWCud4/3EakLyvQMjRBX6A67GIx Date: Fri, 5 Aug 2016 22:06:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBB3F15@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBB146A@ESESSMB208.ericsson.se>, <58760FC9-AA8B-4BB8-B9E2-C994C12D1EA5@brianrosen.net> In-Reply-To: <58760FC9-AA8B-4BB8-B9E2-C994C12D1EA5@brianrosen.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BBB3F15ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7se5p3qXhBmfapSye3p/GZtG46Cmr xYoNB1gdmD3+vv/A5HH/2192jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcz/8ZqtYMs2xopvax4x NzCems/YxcjJISFgInFpyiq2LkYuDiGB9YwSn3/dYYVwFjNKXH77k7mLkYODTcBCovufNkiD iICyxM5bnewgYWYBb4m1+yVBwsICgRLrzq1hhCgJkvj5cD2UbSSxf+53FhCbRUBFYv7JBcwg Nq+Ar8SWPTOYIFZtZZLo2vyZCSTBKeAk8ahzDlgRo4CYxPdTa8DizALiEk1fVrJCHC0gsWTP eWYIW1Ti5eN/rBA1+RKTJ+1ihVggKHFy5hOWCYzCs5C0z0JSNgtJGUTcQOLL+9tQtrbEsoWv mSFsfYnu96eZkMUXMLKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMq4NbfqvuYLz8xvEQ owAHoxIPr8KVJeFCrIllxZW5hxglOJiVRHiF2JaGC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1 f6kYLiSQnliSmp2aWpBaBJNl4uCUamAs5Psj5fnhrNHjnUkaX5acuZi46+PsDSWHeSRUGV9K zD78/MnryT+XXD3xTerJ+Z1vOEX2iO+8KTkz+/lK4Ud3ZyRfPHF+hUXaTBuT9TVbWOLOHdh3 po1neUMVk3Jm9jrdeFlRzvmyNSnX/K88X7z/Qn1LhenqBVM5t3I6T039KGdiV3XRIWD2ciWW 4oxEQy3mouJEACr4LyqnAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 05 Aug 2016 22:06:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBB3F15ESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, Unless you've defined an info package for sending additional data, you can'= t use INFO for doing it. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: =FD06/=FD08/=FD2016 00:02 To: Christer Holmberg Cc: Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Sure. But the INFO is a way to send additional data update in the middle of a ses= sion. You don=92t use it with the INVITE. I=92d like the mechanisms to be as similar as possible. Brian On Aug 5, 2016, at 3:57 PM, Christer Holmberg > wrote: Hi Brian, As far as I remember, additional data does not say anything about info pack= ages. The text might be general, but whenever you are going to use an info = package you must define an info package specification that describes the de= tails associated with that info package. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: =FD05/=FD08/=FD2016 18:17 To: Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Also, since ecall is a form of =93additional data=94, it should conform to = the syntax for all the other additional data blocks that may be included in= the call. Brian > On Aug 5, 2016, at 10:43 AM, Paul Kyzivat > wrote: > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is unnece= ssary because the recipient will know what to do with the body even in the = absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. In= itially the only body of interest was SDP, so how one might process other b= odies or body parts was not well considered. Eventually this started to be = a liability, so RFC5621 was published to clarify it. > > Processing of body parts is governed by a complex interaction between Con= tent-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being included.= I realize that there is one predominant reason for doing so, but that is n= ot the only possible reason. (E.g., it might be included as context in an i= ntended discussion about problems handling a call in the past.) > > If all the handling of the call is coded in a special purpose way, solely= for the emergency call path, then alternatives may be of no concern. But i= deally the call will largely be handled via standard library code that is a= lso used for other call paths and other message processing. So processing b= ody parts in a "standard" way, rather than special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >> >> >> >> COMMENT: >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Inclusion of Call-Info header field with >> purpose=3DemergencyCallData.eCall.MSD or >> purpose=3DemergencyCallData.eCall.control in requests and responses does >> not seem to bring any value. It seems to only waste radio resources. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the >> initial INVITE request: >> >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI and >> the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >> >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all the >> bodies of the INVITE request not marked with Content-Disposition: ...; >> handling=3Doptional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in= a >> response to the initial INVITE request >> >> - no routing decisions are done by proxies when receiving a response to >> the initial INVITE request so this does not seem to have any value for >> the proxies >> >> - UAC includes Accept with supported MIME types in INVITE request so why >> would UAS send any MIME body not wished by the UAC? >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included in >> the INFO request >> >> - no routing decisions are done by proxies when receiving an in-dialog >> request so this does not seem to have any value for the proxies >> >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml MIME >> body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked with >> Content-Disposition: ...; handling=3Doptional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> PROPOSED SOLUTION to COMMENT >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\ >> >> Remove insertion of Call-Info header field. >> >> ////////////////////////////////////////////////////////////////////////= ////// >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_7594FB04B1934943A5C02806D1A2204B4BBB3F15ESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

Unless you've defined an info package for sending additional data, you can'= t use INFO for doing it.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: =FD06= /=FD08/=FD2016 00:02
To: Christer Holmberg Cc: Paul Kyzivat; ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
Sure.

But the INFO is a way to send additional data update in the= middle of a session.

You don=92t use it with the INVITE.

I=92d like the mechanisms to be as similar as possible.

Brian

On Aug 5, 2016, at 3:57 PM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:

Hi= Brian,

As far as I remember, additional data does not say anything about info pack= ages. The text might be general, but whenever you are going to use an info = package you must define an info package specification that describes the de= tails associated with that info package.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: =FD05/=FD08/=FD2016 18:17
To: Paul Kyzivat
Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Also, since ecall is a form of =93additional data= =94, it should conform to the syntax for all the other additional data bloc= ks that may be included in the call.

Brian

> On Aug 5, 2016, at 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Ivo,
> 
> IIUC, you are saying that the Call-Info that refers to the body is unn= ecessary because the recipient will know what to do with the body even in t= he absence of the Call-Info. Is that right?
> 
> This assumption mixes up two things:
> - understanding a body syntactically
> - understanding *why* the body is present and how it should be used. > 
> Historically, processing of body parts in sip was very poorly defined.= Initially the only body of interest was SDP, so how one might process othe= r bodies or body parts was not well considered. Eventually this started to = be a liability, so RFC5621 was published to clarify it.
> 
> Processing of body parts is governed by a complex interaction between = Content-Type, Content-Disposition, Content-ID.
> 
> So the call-info header indicates the reason that body is being includ= ed. I realize that there is one predominant reason for doing so, but that i= s not the only possible reason. (E.g., it might be included as context in a= n intended discussion about problems handling a call in the past.)
> 
> If all the handling of the call is coded in a special purpose way, sol= ely for the emergency call path, then alternatives may be of no concern. Bu= t ideally the call will largely be handled via standard library code that i= s also used for other call paths and other message processing. So processing body parts in a "standard&quo= t; way, rather than special casing, is desirable.
> 
>        Thanks,
>        Paul
> 
> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
>> Hello,
>> 
>> 
>> 
>> COMMENT:
>> 
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>> 
>> Inclusion of Call-Info header field with
>> purpose=3DemergencyCallData.eCall.MSD or
>> purpose=3DemergencyCallData.eCall.control in requests and response= s does
>> not seem to bring any value. It seems to only waste radio resource= s.
>> 
>> 
>> 
>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included = in the
>> initial INVITE request:
>> 
>> - if this is meant to be used by a proxy for routing of the eCall<= br class=3D""> >> emergency call to a PSAP supporting eCall emergency call, then thi= s
>> seems to be redundant to the eCall URN included in the Request-URI= and
>> the Recv-Info header field containing eCall specific info package<= br class=3D""> >> (emergencyCallData.eCall.MSD).
>> 
>> - if this is meant to be used by UAS (i.e. PSAP), then according t= o
>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that a= ll the
>> bodies of the INVITE request not marked with Content-Disposition: = ...;
>> handling=3Doptional are understood. So,
>> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INVITE request processing.
>> 
>> 
>> 
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in a
>> response to the initial INVITE request
>> 
>> - no routing decisions are done by proxies when receiving a respon= se to
>> the initial INVITE request so this does not seem to have any value= for
>> the proxies
>> 
>> - UAC includes Accept with supported MIME types in INVITE request = so why
>> would UAS send any MIME body not wished by the UAC?
>> 
>> 
>> 
>> For Call-Info with purpose=3DemergencyCallData.eCall.control inclu= ded in
>> the INFO request
>> 
>> - no routing decisions are done by proxies when receiving an in-di= alog
>> request so this does not seem to have any value for the proxies >> 
>> - support of info package emergencyCallData.eCall.MSD in the call<= br class=3D""> >> implies that either application/EmergencyCallData.eCall.control= 3;xml MIME
>> body or application/emergencyCallData.eCall.MSD+per MIME body = is
>> included. Again, according to RFC3261 subclause 8.2.3, the UAS any= way
>> needs to check that all the bodies of the INFO request not marked = with
>> Content-Disposition: ...; handling=3Doptional are understood. So,<= br class=3D""> >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will any= way be
>> found by UAS during the INFO request processing.
>> 
>> //////////////////////////////////////////////////////////////////= ////////////
>> 
>> PROPOSED SOLUTION to COMMENT
>> 
>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\
>> 
>> Remove insertion of Call-Info header field.
>> 
>> //////////////////////////////////////////////////////////////////= ////////////
>> 
>> 
>> 
>> Kind regards
>> 
>> 
>> 
>> Ivo Sedlacek
>> 
>> 
>> 
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mai= lman/listinfo/ecrit
>> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman= /listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://= www.ietf.org/mailman/listinfo/ecrit

--_000_7594FB04B1934943A5C02806D1A2204B4BBB3F15ESESSMB208erics_-- From nobody Fri Aug 5 22:44: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 7CCF712B03D for ; Fri, 5 Aug 2016 22:44:02 -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.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.247] 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 FQc6827o6ObL for ; Fri, 5 Aug 2016 22:44:01 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5EB12B076 for ; Fri, 5 Aug 2016 22:44:01 -0700 (PDT) Received: from [10.20.4.205] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 5 Aug 2016 22:44:00 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Fri, 5 Aug 2016 22:43:58 -0700 To: Paul Kyzivat , 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-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 06 Aug 2016 05:44:02 -0000 eCall makes use of the additional-data mechanism as defined in RFC 7852. This makes all data that's sent as part of an emergency call consistent. Call-Info is used as defined in RFC 7852 for all data blocks sent as part of the emergency call. It allows the PSAP (and ESInet where deployed) to know which data blocks are attached, and process those it is interested in. The eCall draft is used by the car-crash draft, which covers NG-AACN in North America and other regions that don't use pan-European eCall. This makes it simpler for multi-region (global) vehicles, and for common PSAP equipment. Especially in North America, carriers will add RFC 7852 data blocks (e.g., to identify the carrier). I see value in having all data blocks be attached the same way. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I see in the near future a crisis approaching that unnerves me and causes me to tremble for the safety of my country...corporations have been enthroned and an era of corruption in high places will follow, and the money of the country will endeavor to prolong its reign by working upon the prejudices of the people until all wealth is aggregated in a few hands and the Republic is destroyed. I feel at this moment more anxiety for the safety of my country than ever before, even in the midst of war. --Abraham Lincoln From nobody Sat Aug 6 09:01: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 B867412B006 for ; Sat, 6 Aug 2016 09:01: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 eld6BKYvqdhK for ; Sat, 6 Aug 2016 09:01:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D4EE812B026 for ; Sat, 6 Aug 2016 09:01:06 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-14-57a609c0081c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id F1.94.04209.0C906A75; Sat, 6 Aug 2016 18:01:05 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Sat, 6 Aug 2016 18:01:03 +0200 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AdHt3B9sbBpup4QKShyfkTKkLnlndwCHzWEg Date: Sat, 6 Aug 2016 16:01:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBB575C@ESESSMB208.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+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7oO5BzmXhBu2vOC0aFz1ltVj46xeL A5PHpS2t7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4cP8FU8FM/or9xz0bGE/ydDFyckgImEgs PdHE0sXIxSEksJ5R4umJHiYIZzGjxJSppxi7GDk42AQsJLr/aYM0iAiESyxfcJIRxBYWiJc4 ve8hI0Q8QeLy+dvsELaRxIxTB1hBbBYBFYn1zW/YQGxeAV+JT3M3MIHYQgIBEkc2HwCzOQUC JT6c/cUCYjMKiEl8P7UGLM4sIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaSaFzyhBWiXkdi we5PbBC2tsSyha+ZIfYKSpyc+YRlAqPILCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9VKL MpOLi/Pz9PJSSzYxAqPh4JbfqjsYL79xPMQowMGoxMOrcGVJuBBrYllxZe4hRgkOZiUR3oks y8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MAZy3Pvw +2pptsNUpw9Z/ye1bV3Ksm5XO3PJhz2J4f+ll10J4upfum8lk5Qdt7Dc1qO9G9456Kps4/Xm WXxJ1S71neGca3v3hXCEqbMWXj/3IepeClfpzZnh315U/WFyP7ro8F071qg3TDsC/AoOq513 tn/ZomMj6hJ06/D1gkWej/uTLprF8CuxFGckGmoxFxUnAgBju+gNggIAAA== Archived-At: Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 06 Aug 2016 16:01:10 -0000 Hi, Note that draft-ecall defines the core metadata/control mechanism, which dr= aft-car-crash then reverences, so, I am not sure whether we should initiate= WGLC for both drafts in parallel. At least my experience (e.g. from MMUSIC= ) is that we try to get the dependencies stable first. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall Sent: 04 August 2016 02:10 To: ecrit@ietf.org Subject: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecri= t-car-crash-09 Changing subject line & resending. *** Our plan is to issue WGLC for both drafts soon, draft-ietf-ecrit-ecall-11 draft-ietf-ecrit-car-crash-09 which have now been updated a couple of times to resolve all significant is= sues (thanks Randy & Christer). =20 Anyone have any objections to doing so? Roger & Marc 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Sun Aug 7 14:06: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 80B5512D591 for ; Sun, 7 Aug 2016 14:06: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 DNAkL3gPssL4 for ; Sun, 7 Aug 2016 14:06:40 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3236412B069 for ; Sun, 7 Aug 2016 14:06:40 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 7 Aug 2016 14:06:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBB575C@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BBB575C@ESESSMB208.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 7 Aug 2016 14:06:32 -0700 To: Christer Holmberg , 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] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 07 Aug 2016 21:06:41 -0000 Hi Christer, In the case of eCall and car-crash, I think doing both docs together makes sense. --Randy At 4:01 PM +0000 8/6/16, Christer Holmberg wrote: > Hi, > > Note that draft-ecall defines the core metadata/control mechanism, > which draft-car-crash then reverences, so, I am not sure whether we > should initiate WGLC for both drafts in parallel. At least my > experience (e.g. from MMUSIC) is that we try to get the > dependencies stable first. > > Regards, > > Christer > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: 04 August 2016 02:10 > To: ecrit@ietf.org > Subject: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & > draft-ietf-ecrit-car-crash-09 > > Changing subject line & resending. > > *** > > Our plan is to issue WGLC for both drafts soon, > > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 > > which have now been updated a couple of times to resolve all > significant issues (thanks Randy & Christer). > Anyone have any objections to doing so? > > Roger & Marc > 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 > > _______________________________________________ > 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: --------------- Consistency is the last refuge of the unimaginative. --Oscar Wilde From nobody Sun Aug 7 14:38: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 2D07E12D6AE for ; Sun, 7 Aug 2016 14:38:02 -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 Qi8V8PKeQOmL for ; Sun, 7 Aug 2016 14:38:00 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D142112D6AA for ; Sun, 7 Aug 2016 14:37:59 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-01-57a7aa35a2bb Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 61.B6.02553.53AA7A75; Sun, 7 Aug 2016 23:37:57 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Sun, 7 Aug 2016 23:37:29 +0200 From: Christer Holmberg To: Randall Gellens , Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 Thread-Index: AQHR8PG1lWjrnpDhpkeMq4B9GqPkIaA+Becp Date: Sun, 7 Aug 2016 21:37:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBB8A03@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BBB575C@ESESSMB208.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_7594FB04B1934943A5C02806D1A2204B4BBB8A03ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdXtd01fJwg86l+haNi56yWnx/3sVo sfDXLxYHZo9LW1rZPZYs+cnksfXOY5YA5igum5TUnMyy1CJ9uwSujFlX7Aveuldcm7CCrYFx hW0XIyeHhICJxK6Np9i6GLk4hATWM0pcazjBAuEsZpT4838rUIaDg03AQqL7nzZIg4hAC6NE +1FREFtYIEHi+rOv7BDxRIlj828zQthGEvtWTgOzWQRUJC6fPMEMYvMK+Ersef6XCWL+HkaJ bcdfgBVxAl0xqXktWBGjgJjE91NrmEBsZgFxiaYvK1khLhWQWLLnPDOELSrx8vE/VoiafInt 2xexQSwQlDg58wnLBEahWUjaZyEpm4WkDCJuIPHl/W0oW1ti2cLXzBC2vkT3+9NMyOILGNlX MYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTGzsEtvw12ML587niIUYCDUYmHV6F8ebgQa2JZ cWXuIUYJDmYlEd7ny4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbB ZJk4OKUaGHurvvrGHDlxRbO99+RTS/Pn3lafOI8HL3to5fa/u0BC5uBDyYNSQu4Kv+1fHu7/ OnXRTJmYL/fPxvFfePDoevTKduvquULO1eXW6enyczco3XHtSJ04k2XlgoUOP/surFxoGtXj 4H7414Sfuskbt5jqTMz/Vvvh51TTCTXhek5r2Av0tkRdtFNiKc5INNRiLipOBAAbQd7amQIA AA== Archived-At: Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf-ecrit-car-crash-09 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, 07 Aug 2016 21:38:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBB8A03ESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We can work on both documents, but one cannot perform a proper WGLC review = of car-crash until the dependencies in ecall are stable. Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD08/=FD08/=FD2016 00:21 To: Christer Holmberg; Roger Marshal= l; ecrit@ietf.org Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & draft-ietf= -ecrit-car-crash-09 Hi Christer, In the case of eCall and car-crash, I think doing both docs together makes sense. --Randy At 4:01 PM +0000 8/6/16, Christer Holmberg wrote: > Hi, > > Note that draft-ecall defines the core metadata/control mechanism, > which draft-car-crash then reverences, so, I am not sure whether we > should initiate WGLC for both drafts in parallel. At least my > experience (e.g. from MMUSIC) is that we try to get the > dependencies stable first. > > Regards, > > Christer > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: 04 August 2016 02:10 > To: ecrit@ietf.org > Subject: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & > draft-ietf-ecrit-car-crash-09 > > Changing subject line & resending. > > *** > > Our plan is to issue WGLC for both drafts soon, > > draft-ietf-ecrit-ecall-11 > draft-ietf-ecrit-car-crash-09 > > which have now been updated a couple of times to resolve all > significant issues (thanks Randy & Christer). > Anyone have any objections to doing so? > > Roger & Marc > 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 > > _______________________________________________ > 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: --------------- Consistency is the last refuge of the unimaginative. --Oscar Wilde --_000_7594FB04B1934943A5C02806D1A2204B4BBB8A03ESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We can work on both documents, but one cannot perform a proper WGLC review = of car-crash until the dependencies in ecall are stable.

Regards,

Christer

Sent from my Windows Phone
From: Randall Gellens
Sent: =FD08= /=FD08/=FD2016 00:21
To: Christer Holmberg; Roger Marshall; ecrit@ietf.org
Subject: Re: [= Ecrit] Next steps for draft-ietf-ecrit-ecall-11 &  draft-ietf-ecri= t-car-crash-09

Hi Christer,

In the case of eCall and car-crash, I think doing both docs together
makes sense.

--Randy

At 4:01 PM +0000 8/6/16, Christer Holmberg wrote:

>  Hi,
>
>  Note that draft-ecall defines the core metadata/control mechanis= m,
> which draft-car-crash then reverences, so, I am not sure whether we > should initiate WGLC for both drafts in parallel. At least my
> experience (e.g. from MMUSIC) is that we try to get the
> dependencies stable first.
>
>  Regards,
>
>  Christer
>
>  -----Original Message-----
>  From: Ecrit [mailto:ec= rit-bounces@ietf.org] On Behalf Of Roger Marshall
>  Sent: 04 August 2016 02:10
>  To: ecrit@ietf.org
>  Subject: [Ecrit] Next steps for draft-ietf-ecrit-ecall-11 & =
> draft-ietf-ecrit-car-crash-09
>
>  Changing subject line & resending.
>
>  ***
>
>  Our plan is to issue WGLC for both drafts soon,
>
>  draft-ietf-ecrit-ecall-11
>  draft-ietf-ecrit-car-crash-09
>
>  which have now been updated a couple of times to resolve all > significant issues (thanks Randy & Christer).
>  Anyone have any objections to doing so?
>
>  Roger & Marc
>  ECRIT Chairs
>
>
>
>  NOTICE TO RECIPIENT: This email, including attachments, may cont= ain
> 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
>
>  _______________________________________________
>  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: ---------------
Consistency is the last refuge of the unimaginative.
            &nb= sp;            =             &nb= sp; --Oscar Wilde
 --_000_7594FB04B1934943A5C02806D1A2204B4BBB8A03ESESSMB208erics_-- From nobody Mon Aug 8 00:43: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 38CD512D0B7 for ; Mon, 8 Aug 2016 00:43:25 -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 5on8yEB-AWOX for ; Mon, 8 Aug 2016 00:43:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1C7E612B02A for ; Mon, 8 Aug 2016 00:43:21 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-86-57a838178770 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 5F.9B.02493.71838A75; Mon, 8 Aug 2016 09:43:20 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 09:43:18 +0200 From: Ivo Sedlacek To: Paul Kyzivat , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR7yexzjzhoQPLfkKT6I4BtTjh96A6WFoAgAAalwCABD6foA== Date: Mon, 8 Aug 2016 07:43:18 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/mixed; boundary="_004_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfyyUcRzH933uubuHuXo65JNq1WVlNT+SYvRD/dFsrRVN16+trjzDcKd7 UEqLWsqVcekq1/IrYgmHk36Z3ORXJowU2ZIrXSjDFoV1zz2PZfXf6/P+vL+f7+f7+XwJnrhB 4EiEyaMppVwWIRFY4xkHqwJcwLtQ6t72ZaF3Yu5nvneh7iXfD/Of+TGK+eflTWH7sMPWW4Kp iLBYSum27bh1qLqmG49KbcTOfJ3uxROQMRNTISsCSE+oHhjCVciaEJOlCC4bMxEb3EeQobok YFwC0hXU+jo+w3ZkIoL3dQsYtiUDoHismtMDobu2VcjyTnicPIsYxkknqH+ab9FF5B7omsgW sBfMIEgeucFjElakHxTcqbQwIpdD13SK5TCPdIAeYxbXqh30t78WsGwPpoFZPssSyO0dN3sI sz8M0vQH2LsWQVOGEU9Dttp5lbR/Xdp5LtaigIvvangsu0NrVZmQ5fXwIGeI092gqjeD/7++ DCo0yYjlywj6f5k9zCt1CFqargrYIBUDzXA+zgbpCFIMPznbIwSJdZlcph1B6d0+7kwpBt1V FVymDMFkdhKXMW9I83bE0svchrSW6UuhILvJ0ostuRueJ+bhrO4PszkfecwI7Mz+xhJn1rIG UjpKhIzMLMv4IUTL7Wr0mtpS0Yb0gvRnaQKWlZB1SyNkOQa01Tcx7by1/TtsILdCZ3lQNtrx ENnTFE1Hhnh4uFLKsJM0rZC7yqnocmT+0rX63z5PUO3gDgMiCSSxEa08XSAV82WxdFykATmZ S37SFbUhR1yukFMSO1Hd+kKpWBQsiztLKRXHlDERFG1ASwlc4iDaa1olFZMhsmgqnKKiKOVc FiOsHBPQCVOLTvP9fMmwZ7rbL/3NJadO52/yVUfOBhYNel7BwqP36+POOb8x7MxV9YwKw5Oa PzTnqbefqaRErkUv+oprBuOvD3toJhavNdzYfLR1rP7IZMnGQ1tNEytc7mkbJn3lxLgi6IFf z5WlqS7P46dvdxi/ebXuurBaEeJDXu08pHo1JcHpUNmGdTwlLfsDtMIJnNoDAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 08 Aug 2016 07:43:25 -0000 --_004_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_" --_000_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hello Paul, the comment explicitly referred to INVITE and to INFO. Excerpts from the attached: --------------- For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the in= itial INVITE request: ... For Call-Info with purpose=3DemergencyCallData.eCall.control included in a = response to the initial INVITE request ... For Call-Info with purpose=3DemergencyCallData.eCall.control included in th= e INFO request ... --------------- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 6:50 PM To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue On 8/5/16 11:14 AM, Christer Holmberg wrote: > Hi Paul, > > In INFOs, the info package specification shall indicate WHY a message > body is included. That was one of the main reason for doing the info > package mechanism. > > And, as Ivo also indicated, INFOs will be routed according to the > established route set. I didn't think this was about INFO. I agree that in INFO, as long as the bo= dy is properly marked as the package body for the INFO that a call-info poi= nting to it isn't needed, and not appropriate. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ---------------------------------------------------------------------- > -- > From: Paul Kyzivat > Sent: =FD05/=FD08/=FD2016 17:43 > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is > unnecessary because the recipient will know what to do with the body > even in the absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. > Initially the only body of interest was SDP, so how one might process > other bodies or body parts was not well considered. Eventually this > started to be a liability, so RFC5621 was published to clarify it. > > Processing of body parts is governed by a complex interaction between > Content-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being > included. I realize that there is one predominant reason for doing so, > but that is not the only possible reason. (E.g., it might be included > as context in an intended discussion about problems handling a call in > the > past.) > > If all the handling of the call is coded in a special purpose way, > solely for the emergency call path, then alternatives may be of no > concern. But ideally the call will largely be handled via standard > library code that is also used for other call paths and other message > processing. So processing body parts in a "standard" way, rather than > special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> Hello, >> >> >> >> COMMENT: >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> \\\\\\\\\ >> >> Inclusion of Call-Info header field with >> purpose=3DemergencyCallData.eCall.MSD or >> purpose=3DemergencyCallData.eCall.control in requests and responses >> does not seem to bring any value. It seems to only waste radio resources= . >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in >> the initial INVITE request: >> >> - if this is meant to be used by a proxy for routing of the eCall >> emergency call to a PSAP supporting eCall emergency call, then this >> seems to be redundant to the eCall URN included in the Request-URI >> and the Recv-Info header field containing eCall specific info package >> (emergencyCallData.eCall.MSD). >> >> - if this is meant to be used by UAS (i.e. PSAP), then according to >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >> the bodies of the INVITE request not marked with Content-Disposition: >> ...; handling=3Doptional are understood. So, >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INVITE request processing. >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included >> in a response to the initial INVITE request >> >> - no routing decisions are done by proxies when receiving a response >> to the initial INVITE request so this does not seem to have any value >> for the proxies >> >> - UAC includes Accept with supported MIME types in INVITE request so >> why would UAS send any MIME body not wished by the UAC? >> >> >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included >> in the INFO request >> >> - no routing decisions are done by proxies when receiving an >> in-dialog request so this does not seem to have any value for the >> proxies >> >> - support of info package emergencyCallData.eCall.MSD in the call >> implies that either application/EmergencyCallData.eCall.control+xml >> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> needs to check that all the bodies of the INFO request not marked >> with >> Content-Disposition: ...; handling=3Doptional are understood. So, >> application/EmergencyCallData.eCall.control+xml MIME body or >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> found by UAS during the INFO request processing. >> >> ///////////////////////////////////////////////////////////////////// >> ///////// >> >> PROPOSED SOLUTION to COMMENT >> >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> \\\\\\\\\ >> >> Remove insertion of Call-Info header field. >> >> ///////////////////////////////////////////////////////////////////// >> ///////// >> >> >> >> Kind regards >> >> >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hello Paul,

 

the comment explicitly referred to INVITE and to = INFO.  

 

Excerpts from the attached:

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

For Call-Info with purpose=3DemergencyCallData.eC= all.MSD included in the initial INVITE request:

...

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in a response to the initial INVITE request=

...

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in the INFO request

...

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

 

Kind regards

 

Ivo

 

 

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 6:50 PM
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

On 8/5/16 11:14 AM, Christer Holmberg wrote:=

> Hi Paul,

> 

> In INFOs, the info package specification sha= ll indicate WHY a message

> body is included. That was one of the main r= eason for doing the info

> package mechanism.

> 

> And, as Ivo also indicated, INFOs will be ro= uted according to the

> established route set.

 

I didn't think this was about INFO. I agree that = in INFO, as long as the body is properly marked as the package body for the= INFO that a call-info pointing to it isn't needed, and not appropriate.

 

        &= nbsp;       Thanks,

        &= nbsp;       Paul

 

> Regards,

> 

> Christer

> 

> Sent from my Windows Phone

> --------------------------------------------= --------------------------

> --

> From: Paul Kyzivat <m= ailto:pkyzivat@alum.mit.edu>

> Sent: =FD05/=FD08/=FD2016 17:43

> To: ecrit@ietf.org &= lt;mailto:ecrit@ietf.org>

> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-= 11- Call-Info usage brings

> no value

> 

> Ivo,

> 

> IIUC, you are saying that the Call-Info that= refers to the body is

> unnecessary because the recipient will know = what to do with the body

> even in the absence of the Call-Info. Is tha= t right?

> 

> This assumption mixes up two things:

> - understanding a body syntactically

> - understanding *why* the body is present an= d how it should be used.

> 

> Historically, processing of body parts in si= p was very poorly defined.

> Initially the only body of interest was SDP,= so how one might process

> other bodies or body parts was not well cons= idered. Eventually this

> started to be a liability, so RFC5621 was pu= blished to clarify it.

> 

> Processing of body parts is governed by a co= mplex interaction between

> Content-Type, Content-Disposition, Content-I= D.

> 

> So the call-info header indicates the reason= that body is being

> included. I realize that there is one predom= inant reason for doing so,

> but that is not the only possible reason. (E= .g., it might be included

> as context in an intended discussion about p= roblems handling a call in

> the

> past.)

> 

> If all the handling of the call is coded in = a special purpose way,

> solely for the emergency call path, then alt= ernatives may be of no

> concern. But ideally the call will largely b= e handled via standard

> library code that is also used for other cal= l paths and other message

> processing. So processing body parts in a &q= uot;standard" way, rather than

> special casing, is desirable.

> 

>       &nb= sp; Thanks,

>       &nb= sp; Paul

> 

> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:<= /o:p>

>> Hello,

>> 

>> 

>> 

>> COMMENT:

>> 

>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

>> \\\\\\\\\

>> 

>> Inclusion of Call-Info header field with=

>> purpose=3DemergencyCallData.eCall.MSD or=

>> purpose=3DemergencyCallData.eCall.contro= l in requests and responses

>> does not seem to bring any value. It see= ms to only waste radio resources.

>> 

>> 

>> 

>> For Call-Info with purpose=3DemergencyCa= llData.eCall.MSD included in

>> the initial INVITE request:

>> 

>> - if this is meant to be used by a proxy= for routing of the eCall

>> emergency call to a PSAP supporting eCal= l emergency call, then this

>> seems to be redundant to the eCall URN i= ncluded in the Request-URI

>> and the Recv-Info header field containin= g eCall specific info package

>> (emergencyCallData.eCall.MSD).

>> 

>> - if this is meant to be used by UAS (i.= e. PSAP), then according to

>> RFC3261 subclause 8.2.3, then the UAS an= yway needs to check that all

>> the bodies of the INVITE request not mar= ked with Content-Disposition:

>> ...; handling=3Doptional are understood.= So,

>> application/emergencyCallData.eCall.MSD&= #43;per MIME body will anyway be

>> found by UAS during the INVITE request p= rocessing.

>> 

>> 

>> 

>> For Call-Info with purpose=3DemergencyCa= llData.eCall.control included

>> in a response to the initial INVITE requ= est

>> 

>> - no routing decisions are done by proxi= es when receiving a response

>> to the initial INVITE request so this do= es not seem to have any value

>> for the proxies

>> 

>> - UAC includes Accept with supported MIM= E types in INVITE request so

>> why would UAS send any MIME body not wis= hed by the UAC?

>> 

>> 

>> 

>> For Call-Info with purpose=3DemergencyCa= llData.eCall.control included

>> in the INFO request

>> 

>> - no routing decisions are done by proxi= es when receiving an

>> in-dialog request so this does not seem = to have any value for the

>> proxies

>> 

>> - support of info package emergencyCallD= ata.eCall.MSD in the call

>> implies that either application/Emergenc= yCallData.eCall.control+xml

>> MIME body or application/emergencyCallDa= ta.eCall.MSD+per MIME body is

>> included. Again, according to RFC3261 su= bclause 8.2.3, the UAS anyway

>> needs to check that all the bodies of th= e INFO request not marked

>> with

>> Content-Disposition: ...; handling=3Dopt= ional are understood. So,

>> application/EmergencyCallData.eCall.cont= rol+xml MIME body or

>> application/emergencyCallData.eCall.MSD&= #43;per MIME body will anyway be

>> found by UAS during the INFO request pro= cessing.

>> 

>> ////////////////////////////////////////= /////////////////////////////

>> /////////

>> 

>> PROPOSED SOLUTION to COMMENT<= /p>

>> 

>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

>> \\\\\\\\\

>> 

>> Remove insertion of Call-Info header fie= ld.

>> 

>> ////////////////////////////////////////= /////////////////////////////

>> /////////

>> 

>> 

>> 

>> Kind regards

>> 

>> 

>> 

>> Ivo Sedlacek

>> 

>> 

>> 

>> ________________________________________= _______

>> Ecrit mailing list

>> Ecrit@ietf.org

>> https://www.ietf.org/= mailman/listinfo/ecrit

>> 

> 

> ____________________________________________= ___

> Ecrit mailing list

> Ecrit@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/ecrit

 

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ecrit

--_000_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_-- --_004_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 08 Aug 2016 07:43:16 GMT"; modification-date="Mon, 08 Aug 2016 07:43:16 GMT" Received: from sessmg14.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.64) with Microsoft SMTP Server id 14.3.301.0; Fri, 5 Aug 2016 13:15:45 +0200 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Mail Security) with SMTP id 26.55.04446.06574A75; Fri, 5 Aug 2016 13:15:44 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2464712D75D; Fri, 5 Aug 2016 04:15:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF6312D10B for ; Fri, 5 Aug 2016 04:15:40 -0700 (PDT) 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 RDDyfV51sLrj for ; Fri, 5 Aug 2016 04:15:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D94E812D5D1 for ; Fri, 5 Aug 2016 04:15:27 -0700 (PDT) Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 40.CB.02553.C4574A75; Fri, 5 Aug 2016 13:15:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Fri, 5 Aug 2016 13:15:24 +0200 From: Ivo Sedlacek To: Roger Marshall , "ecrit@ietf.org" Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Topic: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AdHvCf2XvCTspod0Sfqn3Oqg2MqovQ== Sender: Ecrit Date: Fri, 5 Aug 2016 11:15:24 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Exchange-Organization-AuthSource: ESESSHC015.ericsson.se X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7h65f6ZJwg02/eCwaFz1ltVj46xeL A5PHpS2t7B5LlvxkCmCK4rJJSc3JLEst0rdL4MqY+nIVa0GTW8X9t0fYGxif2nQxcnJICJhI dO2ewt7FyMUhJLCeUeLDtN3MEM5iRomp196yglSxCehJTNxyBMwWEQiXWL7gJCOILSzgLLHp Zys7RNxD4t/CB0DNHEC2nsSJdRogJouAisSTO+kgFbwCvhIfuieCTWEUkJW4+qcXbAqzgLjE rSfzmSDuEZBYsuc8M4QtKvHy8T9WCFtJ4seGSywQ9fkS25quMkPMFJQ4OfMJywRGwVlIRs1C UjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKSXWpSZXFycn6eX l1qyiREYDQe3/DbYwfjyueMhRgEORiUe3gVNi8OFWBPLiitzDzFKcDArifDaliwJF+JNSays Si3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDokvnxm53z0elPOJb/ Vfy4j1ckzVemT7b5sQffsYV67UKXrk7ZU7Ini/VPwNpVGhvedGptPBpbuDTRiWPCv2v3JFPj LguvXyu/OK2lLunFBmXWymcL/skf4lBQyKzIeay4JeFW9ZKy3fH5H68nv3sqK7YygkP3DFNT xPnGk7Pnl+meblTfruOmxFKckWioxVxUnAgAD9qdYoICAAA= x-auditid: c1b4fb3e-eafff7000000115e-ad-57a4755e39dc x-originating-ip: [153.88.183.146] x-virus-scanned: amavisd-new at amsl.com list-id: x-mailman-version: 2.1.17 delivered-to: ecrit@ietfa.amsl.com x-beenthere: ecrit@ietf.org x-original-to: ecrit@ietfa.amsl.com list-post: x-spam-flag: NO list-archive: errors-to: ecrit-bounces@ietf.org dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1470395742; bh=xQcw7vkXL/COYnAfxhCwZGgqTw6/A8sXEHm93rpqCc0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=TWCftE8eYHczKadnXGn9KG+N3Kz5FSCf+jYe0/mCYcHkw5xB7QpgBoPrCDxe+PzqO UVxrof9/Zxd6vu4ngUCEKIcgAiAsOuVqJ60GrRWbkq+R4gmM2nB+c/wjFEW7Y4T3Ub EkjfYIo51cQ4LwNoICh9WnzXmk8QawmBAjAOuUMs= 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 x-spam-score: -4.22 Content-Type: multipart/mixed; boundary="_004_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_" MIME-Version: 1.0 --_004_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_" --_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, COMMENT: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Inclusion of Call-Info header field with purpose=3DemergencyCallData.eCall.= MSD or purpose=3DemergencyCallData.eCall.control in requests and responses = does not seem to bring any value. It seems to only waste radio resources. For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the in= itial INVITE request: - if this is meant to be used by a proxy for routing of the eCall emergency= call to a PSAP supporting eCall emergency call, then this seems to be redu= ndant to the eCall URN included in the Request-URI and the Recv-Info header= field containing eCall specific info package (emergencyCallData.eCall.MSD)= . - if this is meant to be used by UAS (i.e. PSAP), then according to RFC3261= subclause 8.2.3, then the UAS anyway needs to check that all the bodies of= the INVITE request not marked with Content-Disposition: ...; handling=3Dop= tional are understood. So, application/emergencyCallData.eCall.MSD+per MIME= body will anyway be found by UAS during the INVITE request processing. For Call-Info with purpose=3DemergencyCallData.eCall.control included in a = response to the initial INVITE request - no routing decisions are done by proxies when receiving a response to the= initial INVITE request so this does not seem to have any value for the pro= xies - UAC includes Accept with supported MIME types in INVITE request so why wo= uld UAS send any MIME body not wished by the UAC? For Call-Info with purpose=3DemergencyCallData.eCall.control included in th= e INFO request - no routing decisions are done by proxies when receiving an in-dialog requ= est so this does not seem to have any value for the proxies - support of info package emergencyCallData.eCall.MSD in the call implies t= hat either application/EmergencyCallData.eCall.control+xml MIME body or app= lication/emergencyCallData.eCall.MSD+per MIME body is included. Again, acco= rding to RFC3261 subclause 8.2.3, the UAS anyway needs to check that all th= e bodies of the INFO request not marked with Content-Disposition: ...; hand= ling=3Doptional are understood. So, application/EmergencyCallData.eCall.con= trol+xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body= will anyway be found by UAS during the INFO request processing. ///////////////////////////////////////////////////////////////////////////= /// PROPOSED SOLUTION to COMMENT \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\ Remove insertion of Call-Info header field. ///////////////////////////////////////////////////////////////////////////= /// Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-ID: <7B46C293F93DFA4EA842004F58A27113@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hello,

 

COMMENT:

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Inclusion of Call-Info header field with purpose= =3DemergencyCallData.eCall.MSD or purpose=3DemergencyCallData.eCall.control= in requests and responses does not seem to bring any value. It seems to on= ly waste radio resources.

 

For Call-Info with purpose=3DemergencyCallData.eC= all.MSD included in the initial INVITE request:

- if this is meant to be used by a proxy for rout= ing of the eCall emergency call to a PSAP supporting eCall emergency call, = then this seems to be redundant to the eCall URN included in the Request-UR= I and the Recv-Info header field containing eCall specific info package (emergencyCallData.eCall.MSD).

- if this is meant to be used by UAS (i.e. PSAP),= then according to RFC3261 subclause 8.2.3, then the UAS anyway needs to ch= eck that all the bodies of the INVITE request not marked with Content-Dispo= sition: ...; handling=3Doptional are understood. So, application/emergencyCallData.eCall.MSD+per MIME body = will anyway be found by UAS during the INVITE request processing.

 

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in a response to the initial INVITE request=

- no routing decisions are done by proxies when r= eceiving a response to the initial INVITE request so this does not seem to = have any value for the proxies

- UAC includes Accept with supported MIME types i= n INVITE request so why would UAS send any MIME body not wished by the UAC?=

 

For Call-Info with purpose=3DemergencyCallData.eC= all.control included in the INFO request

- no routing decisions are done by proxies when r= eceiving an in-dialog request so this does not seem to have any value for t= he proxies

- support of info package emergencyCallData.eCall= .MSD in the call implies that either application/EmergencyCallData.eCall.co= ntrol+xml MIME body or application/emergencyCallData.eCall.MSD+per = MIME body is included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway needs to check that all the bodies= of the INFO request not marked with Content-Disposition: ...; handling=3Do= ptional are understood. So, application/EmergencyCallData.eCall.control+= ;xml MIME body or application/emergencyCallData.eCall.MSD+per MIME body will anyway be found by UAS during the INFO request processing.<= o:p>

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

PROPOSED SOLUTION to COMMENT

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Remove insertion of Call-Info header field.<= /o:p>

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

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_-- --_004_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Fri, 05 Aug 2016 11:15:45 GMT"; modification-date="Fri, 05 Aug 2016 11:15:45 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1h aWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCg== --_004_39B5E4D390E9BD4890E2B31079006101164BDF85ESESSMB301erics_-- --_004_39B5E4D390E9BD4890E2B31079006101164BF63FESESSMB301erics_-- From nobody Mon Aug 8 00:59: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 D583012D0A4 for ; Mon, 8 Aug 2016 00:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 yuCZpElu3i_w for ; Mon, 8 Aug 2016 00:59:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 83D0E12B02A for ; Mon, 8 Aug 2016 00:59:01 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-4b-57a83bc3118c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 7A.EE.02493.3CB38A75; Mon, 8 Aug 2016 09:58:59 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 09:58:57 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AdHxSd7IQNd8Woh9QnWvaqiB0LqRzw== Date: Mon, 8 Aug 2016 07:58:57 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164BF66F@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.154] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164BF66FESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7lu5h6xXhBmv+mFs0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjxZQvzAVHvzJWbNrSwNrAOOsqYxcjJ4eE gInE3dX7WbsYuTiEBNYzSqxd84cJwlnMKLH9/1k2kCo2AT2JiVuOsILYIgLeEn9+f2MDKRIW mM0osebxUjBHRGARo8S7f3sZIar0JN4/7mcCsVkEVCSuXlvNDmLzCvhK7LjUwwxiMwrISlz9 0wtWzywgLnHryXwmiJsEJJbsOc8MYYtKvHz8jxXCVpJYdPszE0R9vsTn7aehZgpKnJz5hGUC o+AsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tLs5NNzLSSy3K TC4uzs/Ty0st2cQIjIyDW35b7WA8+NzxEKMAB6MSD69C+fJwIdbEsuLK3EOMEhzMSiK8jyxX hAvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgZNE59HLL 7Xu1pRmxnyzLJ7H1/e+qXs3C/3Ou3vrMf1OvrM1ceVYzVjL80wb5Eq7JkmWuvI93FG1TeaD9 xqivbHLp+5KFT7uybgQ1bH+899z2I3/5GSYIFs4vvrei6J3Xh4mcDZO5zkmsuaB8d4/WVKZU 59+5YtZzmTNYUhJcm/89iEjjcOeWV2Ipzkg01GIuKk4EACVZpWWIAgAA Archived-At: Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 07:59:04 -0000 --_000_39B5E4D390E9BD4890E2B31079006101164BF66FESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_39B5E4D390E9BD4890E2B31079006101164BF66FESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

According to RFC3261, the Call-Info header field = provides additional information about the caller or callee.

 

According to draft-ietf-ecrit-ecall-11, the Call-= Info header field is used to form a "content-table" of pointers t= o bodies INVITE request (and of INVITE response, of INFO request) in header= s of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header field points to a body wh= ich describes the callers or callee, then Call-Info semantic fits (even tho= ugh I would still question usefulness of such Call-Info inclusion).

 

If the Call-Info header field points to a body wh= ich request an action in remote UE and which reports to remote UE an outcom= e of an action done by the local UE, then Call-Info semantic does not fit.<= o:p>

 

Particularly:

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

   A PSAP or IVS transmits a metadata/c= ontrol object (see Section 9) by

   encoding it per the description in t= his document and attaching it to

   a SIP message as a MIME body part pe= r [RFC7852].  The body part is

   identified by its MIME content-type = ('application/

   emergencyCallData.eCall.control+= xml') in the Content-Type header

   field of the body part.  The bo= dy part is assigned a unique

   identifier which is listed in a Cont= ent-ID header field in the body

   part.  The SIP message is marke= d as containing the metadata/control

   object by adding (or appending to) a= Call-Info header field at the

   top level of the SIP message.  = This Call-Info header field contains a

   CID URL referencing the body part's unique identifier, a= nd a

   'purpose' parameter identifying the data as an eCall met= adata/control

   block per the Emergency Call Additional Data Blocks regi= stry entry;

   the 'purpose' parameter's value is 'emergencyCallData.eC= all.control'.

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

and

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

SIP/2.0 200 OK

      To: <sip:+1= 3145551111@example.com>;tag=3D9fxced76sl

      From: Exemplar PSA= P <urn:service:sos.ecall.automatic>

      Call-ID: 384827629= 8220188511@atlanta.example.com

      Call-Info: cid:2345678901@atlanta.example.com;

           &nb= sp;     purpose=3DemergencyCallData.eCall.control;

      Accept: applicatio= n/sdp, application/pidf+xml,

        &= nbsp;     application/emergencyCallData.eCall.control&#= 43;xml,

        &= nbsp;     application/emergencyCallData.eCall.MSD+p= er

      CSeq: 31862 INVITE=

      Recv-Info: emergen= cyCallData.eCall.MSD

      Allow: INVITE, ACK= , PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,

        &= nbsp;    SUBSCRIBE, NOTIFY, UPDATE

      Content-Type: mult= ipart/mixed; boundary=3DboundaryX

      Content-Length: ..= .

 

      --boundaryX

      Content-Type: appl= ication/sdp

 

        &= nbsp;  ...Session Description Protocol (SDP) goes here...

 

      --boundaryX

      Content-Type: appl= ication/EmergencyCallData.eCall.control+xml

      Content-ID: 2345678901@atlanta.example.com

      Content-Dispositio= n: by-reference;handling=3Doptional

 

      <?xml version= =3D"1.0" encoding=3D"UTF-8"?>

      <EmergencyCallD= ata.eCall.Control

        &= nbsp; xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control&= quot;

        &= nbsp; xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

        &= nbsp; xsi:schemaLocation=3D

        &= nbsp;     "urn:ietf:params:xml:ns:EmergencyCallDat= a:eCall:control">

 

      <ack received=3D"true" ref=3D"1234567890@atlanta.example.= com"/>

 

      </EmergencyCall= Data.eCall.Control>

 

      --boundaryX--=

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

 

Kind regards

 

Ivo

 

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that the Call-Info that refe= rs to the body is unnecessary because the recipient will know what to do wi= th the body even in the absence of the Call-Info. Is that right?=

 

This assumption mixes up two things:

- understanding a body syntactically

- understanding *why* the body is present and how= it should be used.

 

Historically, processing of body parts in sip was= very poorly defined.

Initially the only body of interest was SDP, so h= ow one might process other bodies or body parts was not well considered. Ev= entually this started to be a liability, so RFC5621 was published to clarif= y it.

 

Processing of body parts is governed by a complex= interaction between Content-Type, Content-Disposition, Content-ID.

 

So the call-info header indicates the reason that= body is being included. I realize that there is one predominant reason for= doing so, but that is not the only possible reason. (E.g., it might be inc= luded as context in an intended discussion about problems handling a call in the

past.)

 

If all the handling of the call is coded in a spe= cial purpose way, solely for the emergency call path, then alternatives may= be of no concern. But ideally the call will largely be handled via standar= d library code that is also used for other call paths and other message processing. So processing body parts in= a "standard" way, rather than special casing, is desirable.=

 

        &= nbsp;       Thanks,

        &= nbsp;       Paul

 

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:=

> Hello,

> 

> 

> 

> COMMENT:

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Inclusion of Call-Info header field with

> purpose=3DemergencyCallData.eCall.MSD or

> purpose=3DemergencyCallData.eCall.control in= requests and responses does

> not seem to bring any value. It seems to onl= y waste radio resources.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.MSD included in the

> initial INVITE request:

> 

> - if this is meant to be used by a proxy for= routing of the eCall

> emergency call to a PSAP supporting eCall em= ergency call, then this

> seems to be redundant to the eCall URN inclu= ded in the Request-URI and

> the Recv-Info header field containing eCall = specific info package

> (emergencyCallData.eCall.MSD).

> 

> - if this is meant to be used by UAS (i.e. P= SAP), then according to

> RFC3261 subclause 8.2.3, then the UAS anyway= needs to check that all

> the bodies of the INVITE request not marked = with Content-Disposition:

> ...; handling=3Doptional are understood. So,=

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INVITE request proce= ssing.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> a response to the initial INVITE request

> 

> - no routing decisions are done by proxies w= hen receiving a response

> to the initial INVITE request so this does n= ot seem to have any value

> for the proxies

> 

> - UAC includes Accept with supported MIME ty= pes in INVITE request so

> why would UAS send any MIME body not wished = by the UAC?

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> the INFO request

> 

> - no routing decisions are done by proxies w= hen receiving an in-dialog

> request so this does not seem to have any va= lue for the proxies

> 

> - support of info package emergencyCallData.= eCall.MSD in the call

> implies that either application/EmergencyCal= lData.eCall.control+xml

> MIME body or application/emergencyCallData.e= Call.MSD+per MIME body is

> included. Again, according to RFC3261 subcla= use 8.2.3, the UAS anyway

> needs to check that all the bodies of the IN= FO request not marked with

> Content-Disposition: ...; handling=3Doptiona= l are understood. So,

> application/EmergencyCallData.eCall.control&= #43;xml MIME body or

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INFO request process= ing.

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> PROPOSED SOLUTION to COMMENT

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Remove insertion of Call-Info header field.<= o:p>

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> 

> 

> Kind regards

> 

> 

> 

> Ivo Sedlacek

> 

> 

> 

> ____________________________________________= ___

> Ecrit mailing list

> Ecrit@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/ecrit

> 

 

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ecrit

--_000_39B5E4D390E9BD4890E2B31079006101164BF66FESESSMB301erics_-- From nobody Mon Aug 8 02:45: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 472AA12B042 for ; Mon, 8 Aug 2016 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 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, RP_MATCHES_RCVD=-1.247, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 hHY1IE2qn_UY for ; Mon, 8 Aug 2016 02:45:20 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11C3127071 for ; Mon, 8 Aug 2016 02:45:18 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 08 Aug 2016 11:45:04 +0200 X-IronPort-AV: E=Sophos;i="5.28,489,1464645600"; d="scan'208,217";a="934519039" Received: from he105661.emea1.cds.t-internal.com ([10.169.119.57]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 08 Aug 2016 11:44:54 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105661.emea1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 8 Aug 2016 11:44:54 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Mon, 8 Aug 2016 11:44:54 +0200 From: To: , , Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AdHxSd7IQNd8Woh9QnWvaqiB0LqRzwACwAgw Date: Mon, 8 Aug 2016 09:44:54 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.244.116] Content-Type: multipart/alternative; boundary="_000_b753a314ae8e44eaac610da7e7592c9fHE105660emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 09:45:26 -0000 --_000_b753a314ae8e44eaac610da7e7592c9fHE105660emea1cdstintern_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ivo, using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly m= eans using the MSD within the Body. It could be also an interworked call wh= ere all ecall information is included inband using the In-band modem soluti= on. We have to think also on backwards compatibility issues. Thus when moving = PSAP's to SIP imply also that there must exist an interworking between the = old mobile world towards the new mobile world using SIP. Using the Call-Info header would help the PAST to distinguish the in-band a= nd outband solution. Perhaps it would be worth to define an additional valu= e for inband data, to identify ecalls coming from other networks not suppor= ting the MSD Body. Best Regards Roland. Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Montag, 8. August 2016 09:59 An: Paul Kyzivat; ecrit@ietf.org Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wit= h RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no val= ue) Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional "/> --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_b753a314ae8e44eaac610da7e7592c9fHE105660emea1cdstintern_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ivo,= <= /o:p>

using the ecall urn (urn:service:sos.ecall.au=
tomatic) does not implicitly means using the MSD within the Body. It could =
be also an interworked call where all ecall information is included inband =
using the In-band modem solution.
 
We have to think also on backwards compatibil=
ity issues.  Thus when moving PSAP’s to SIP imply also that ther=
e must exist an interworking between the old mobile world towards the new m=
obile world using SIP.
 
Using the Call-Info header would help the PAS=
T to distinguish the in-band and outband solution. Perhaps it would be wort=
h to define an additional value for inband data, to identify ecalls coming =
from other networks not supporting the MSD Body.
 
Best Regards

Roland.

 

 

Von: Ecrit [ma= ilto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; ecrit@ietf.org
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not alig= ned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings= no value)

 

Hello,

 

According to RFC3261, the Ca= ll-Info header field provides additional information about the caller or ca= llee.

 

According to draft-ietf-ecri= t-ecall-11, the Call-Info header field is used to form a "content-tabl= e" of pointers to bodies INVITE request (and of INVITE response, of IN= FO request) in headers of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header fiel= d points to a body which describes the callers or callee, then Call-Info se= mantic fits (even though I would still question usefulness of such Call-Inf= o inclusion).

 

If the Call-Info header fiel= d points to a body which request an action in remote UE and which reports t= o remote UE an outcome of an action done by the local UE, then Call-Info se= mantic does not fit.

 

Particularly:

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

   A PSAP or IVS t= ransmits a metadata/control object (see Section 9) by

   encoding it per= the description in this document and attaching it to

   a SIP message a= s a MIME body part per [RFC7852].  The body part is<= /p>

   identified by i= ts MIME content-type ('application/

   emergencyCallDa= ta.eCall.control+xml') in the Content-Type header

   field of the bo= dy part.  The body part is assigned a unique

   identifier whic= h is listed in a Content-ID header field in the body

   part.  The= SIP message is marked as containing the metadata/control=

   object by addin= g (or appending to) a Call-Info header field at the

   top level of th= e SIP message.  This Call-Info header field contains a

   CID URL referencing the body part's uniqu= e identifier, and a

   'purpose' parameter identifying the data = as an eCall metadata/control

   block per the Emergency Call Additional D= ata Blocks registry entry;

   the 'purpose' parameter's value is 'emerg= encyCallData.eCall.control'.<= /p>

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

and

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

SIP/2.0 200 OK

    &nbs= p; To: <sip:+1314555111= 1@example.com>;tag=3D9fxced76sl

    &nbs= p; From: Exemplar PSAP <urn:service:sos.ecall.automatic>

    &nbs= p; Call-ID: 3848276298220188511@atlanta.example.com

    &nbs= p; Call-Info: cid:2345678901@at= lanta.example.com;

         =         purpose=3DemergencyCallData.eCal= l.control;

    &nbs= p; Accept: application/sdp, application/pidf+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.control+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.MSD+per

    &nbs= p; CSeq: 31862 INVITE

    &nbs= p; Recv-Info: emergencyCallData.eCall.MSD

    &nbs= p; Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,=

    &nbs= p;        SUBSCRIBE, NOTIFY, UPDATE=

    &nbs= p; Content-Type: multipart/mixed; boundary=3DboundaryX

    &nbs= p; Content-Length: ...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/sdp

 

    &nbs= p;      ...Session Description Protocol (SDP) goes= here...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/EmergencyCallData.eCall.control+xml

    &nbs= p; Content-ID: 2345678901@at= lanta.example.com

    &nbs= p; Content-Disposition: by-reference;handling=3Doptional<= /p>

 

    &nbs= p; <?xml version=3D"1.0" encoding=3D"UTF-8"?>

    &nbs= p; <EmergencyCallData.eCall.Control

    &nbs= p;     xmlns=3D"urn:ietf:params:xml:ns:EmergencyCa= llData:eCall:control"

    &nbs= p;     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=

    &nbs= p;     xsi:schemaLocation=3D

    &nbs= p;         "urn:ietf:params:xm= l:ns:EmergencyCallData:eCall:control">

 

    &nbs= p; <ack received=3D"true" ref=3D"1234567890@atlanta.example.com"/>=

 

    &nbs= p; </EmergencyCallData.eCall.Control>

 

    &nbs= p; --boundaryX--

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

 

Kind regards

 

Ivo

 

-----Original Message----- From: Ecrit [mailto:ecrit-bounces= @ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that th= e Call-Info that refers to the body is unnecessary because the recipient wi= ll know what to do with the body even in the absence of the Call-Info. Is t= hat right?

 

This assumption mixes up two= things:

- understanding a body synta= ctically

- understanding *why* the bo= dy is present and how it should be used.

 

Historically, processing of = body parts in sip was very poorly defined.

Initially the only body of i= nterest was SDP, so how one might process other bodies or body parts was no= t well considered. Eventually this started to be a liability, so RFC5621 wa= s published to clarify it.

 

Processing of body parts is = governed by a complex interaction between Content-Type, Content-Disposition= , Content-ID.

 

So the call-info header indi= cates the reason that body is being included. I realize that there is one p= redominant reason for doing so, but that is not the only possible reason. (= E.g., it might be included as context in an intended discussion about problems handling a call in the=

past.)

 

If all the handling of the c= all is coded in a special purpose way, solely for the emergency call path, = then alternatives may be of no concern. But ideally the call will largely b= e handled via standard library code that is also used for other call paths and other message processing. So pr= ocessing body parts in a "standard" way, rather than special casi= ng, is desirable.

 

    &nbs= p;           Thanks,=

    &nbs= p;           Paul

 

On 8/5/16 7:15 AM, Ivo Sedla= cek wrote:

> Hello,

> =

> =

> =

> COMMENT:

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Inclusion of Call-Info = header field with

> purpose=3DemergencyCall= Data.eCall.MSD or

> purpose=3DemergencyCall= Data.eCall.control in requests and responses does

> not seem to bring any v= alue. It seems to only waste radio resources.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.MSD included in the

> initial INVITE request:=

> =

> - if this is meant to b= e used by a proxy for routing of the eCall

> emergency call to a PSA= P supporting eCall emergency call, then this

> seems to be redundant t= o the eCall URN included in the Request-URI and

> the Recv-Info header fi= eld containing eCall specific info package

> (emergencyCallData.eCal= l.MSD).

> =

> - if this is meant to b= e used by UAS (i.e. PSAP), then according to

> RFC3261 subclause 8.2.3= , then the UAS anyway needs to check that all

> the bodies of the INVIT= E request not marked with Content-Disposition:

> ...; handling=3Doptiona= l are understood. So,

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INVITE request processing.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> a response to the initi= al INVITE request

> =

> - no routing decisions = are done by proxies when receiving a response

> to the initial INVITE r= equest so this does not seem to have any value

> for the proxies

> =

> - UAC includes Accept w= ith supported MIME types in INVITE request so

> why would UAS send any = MIME body not wished by the UAC?

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> the INFO request

> =

> - no routing decisions = are done by proxies when receiving an in-dialog

> request so this does no= t seem to have any value for the proxies

> =

> - support of info packa= ge emergencyCallData.eCall.MSD in the call

> implies that either app= lication/EmergencyCallData.eCall.control+xml

> MIME body or applicatio= n/emergencyCallData.eCall.MSD+per MIME body is

> included. Again, accord= ing to RFC3261 subclause 8.2.3, the UAS anyway

> needs to check that all= the bodies of the INFO request not marked with

> Content-Disposition: ..= .; handling=3Doptional are understood. So,

> application/EmergencyCa= llData.eCall.control+xml MIME body or

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INFO request processing.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> PROPOSED SOLUTION to CO= MMENT

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Remove insertion of Cal= l-Info header field.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> =

> =

> Kind regards=

> =

> =

> =

> Ivo Sedlacek=

> =

> =

> =

> _______________________= ________________________

> Ecrit mailing list=

> Ecrit@ietf= .org

> https://www.ietf.org/= mailman/listinfo/ecrit

> =

 

____________________________= ___________________

Ecrit mailing list

Ecrit@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/ecrit

--_000_b753a314ae8e44eaac610da7e7592c9fHE105660emea1cdstintern_-- From nobody Mon Aug 8 03:12: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 7131412D168 for ; Mon, 8 Aug 2016 03:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 m_RVQ2TR2acR for ; Mon, 8 Aug 2016 03:12:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EBBB112B076 for ; Mon, 8 Aug 2016 03:12:23 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-f6-57a85b0513ed Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id C9.F9.04209.50B58A75; Mon, 8 Aug 2016 12:12:21 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 12:12:18 +0200 From: Christer Holmberg To: "R.Jesske@telekom.de" , Ivo Sedlacek , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+1eOQ Date: Mon, 8 Aug 2016 10:12:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBBD15B@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BBBD15BESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2J7uC5r9Ipwg1cfbCwaFz1ltVix4QCr RdOdLjYHZo+/7z8weSxZ8pPJo+2lQgBzFJdNSmpOZllqkb5dAlfG9iMrWQpWNDFXTDnXxdLA +PMyUxcjJ4eEgInEvZ8/GbsYuTiEBNYzSpx4ewjKWcwo8frBYuYuRg4ONgELie5/2iANIgIb GSW2vXUGsYUFFjJKPFweAxFfxCixeLkchG0kcezfR3YQm0VARWJ683dWEJtXwFdi17wZUPOn MErcXNTGBpLgFAiU2PjiBFgRo4CYxPdTa8CuYxYQl7j1ZD7UpQISS/acZ4awRSVePv7HCmEr SSy6/RmqPl9i84FuRohlghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3m wGMmZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLj6uCW36o7GC+/cTzEKMDBqMTD q1C+PFyINbGsuDL3EKMEB7OSCO/ryBXhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmk J5akZqemFqQWwWSZODilGhgrAsSPzC44dXjKrTfvbl9cznfswIrJWg1BG0P6/9if3v8qITNE 6u4xkZPdTHsXsPO+tdyyeKNVk+Dvx6b7P89W3W7ddGcLg82jZ8cXx+3nqfju8Tade4/FfKcF t0//Fv9085LzttUt+VpSe3UPb4wvz1qyhPnpG4uXey5v0p9kLLzSae9lf404ZiWW4oxEQy3m ouJEAMDYo3enAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 10:12:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBBD15BESESSMB208erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We really need to separate the initial request (INVITE) of the call, and mi= d-call requests (INFO). People seem to claim that Call-Info can be usable for routing and describin= g the semantics of the call. When it comes to routing, once you've established the call mid-call request= s will be routed using normal SIP procedures (using the route set). So, not= hing additional is needed for routing. When it comes to semantics, the info package description shall describe the= semantics of the INFO. So, nothing additional is needed for that (at least= nobody has indicated why it would be needed). Just referencing additional-data is not a valid justification - especially = since additional-data doesn't say anything about usage of INFO. Also, in general, there are a number of SIP header fields that are included= only in the INVITE. We don't insert header fields in mid-call requests jus= t because they happen to be included in the initial INVITE. There shall be = a reason for including header fields. Regards, Christer From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.d= e Sent: 08 August 2016 12:45 To: Ivo Sedlacek ; pkyzivat@alum.mit.edu; ecrit@= ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Ivo, using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly m= eans using the MSD within the Body. It could be also an interworked call wh= ere all ecall information is included inband using the In-band modem soluti= on. We have to think also on backwards compatibility issues. Thus when moving = PSAP's to SIP imply also that there must exist an interworking between the = old mobile world towards the new mobile world using SIP. Using the Call-Info header would help the PAST to distinguish the in-band a= nd outband solution. Perhaps it would be worth to define an additional valu= e for inband data, to identify ecalls coming from other networks not suppor= ting the MSD Body. Best Regards Roland. Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Montag, 8. August 2016 09:59 An: Paul Kyzivat; ecrit@ietf.org Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wit= h RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no val= ue) Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional "/> --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_7594FB04B1934943A5C02806D1A2204B4BBBD15BESESSMB208erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We really need to separate the initial request (INVITE) of the call, a= nd mid-call requests (INFO).

 

People seem to claim that Call-Info can be usable for routing and desc= ribing the semantics of the call.

 

When it comes to routing, once you’ve established the call mid-c= all requests will be routed using normal SIP procedures (using the route se= t). So, nothing additional is needed for routing.

 

When it comes to semantics, the info package description shall describ= e the semantics of the INFO. So, nothing additional is needed for that (at = least nobody has indicated why it would be needed).

 

Just referencing additional-data is not a valid justification – = especially since additional-data doesn’t say anything about usage of = INFO.

 

Also, in general, there are a number of SIP header fields that are inc= luded only in the INVITE. We don’t insert header fields in mid-call r= equests just because they happen to be included in the initial INVITE. There shall be a reason for including header fields= .

 

Regards,

 

Christer

 

From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
Sent: 08 August 2016 12:45
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>; pkyzivat@alum.mi= t.edu; ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage br= ings no value)

 

Hi Ivo,= <= /o:p>

using the ecall urn (urn:service:sos.ecall.automatic) doe=
s not implicitly means using the MSD within the Body. It could be also an i=
nterworked call where all ecall information is included inband using the In=
-band modem solution.
 
We have to think also on backwards compatibility issues. =
 Thus when moving PSAP’s to SIP imply also that there must exist=
 an interworking between the old mobile world towards the new mobile world =
using SIP.
 
Using the Call-Info header would help the PAST to disting=
uish the in-band and outband solution. Perhaps it would be worth to define =
an additional value for inband data, to identify ecalls coming from other n=
etworks not supporting the MSD Body.
 
Best Regards

Roland.

 = ;

 = ;

Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; ecrit@ietf.org
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not alig= ned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings= no value)

 

Hello,

 

According to RFC3261, the Ca= ll-Info header field provides additional information about the caller or ca= llee.

 

According to draft-ietf-ecri= t-ecall-11, the Call-Info header field is used to form a "content-tabl= e" of pointers to bodies INVITE request (and of INVITE response, of IN= FO request) in headers of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header fiel= d points to a body which describes the callers or callee, then Call-Info se= mantic fits (even though I would still question usefulness of such Call-Inf= o inclusion).

 

If the Call-Info header fiel= d points to a body which request an action in remote UE and which reports t= o remote UE an outcome of an action done by the local UE, then Call-Info se= mantic does not fit.

 

Particularly:

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

   A PSAP or IVS t= ransmits a metadata/control object (see Section 9) by

   encoding it per= the description in this document and attaching it to

   a SIP message a= s a MIME body part per [RFC7852].  The body part is<= /p>

   identified by i= ts MIME content-type ('application/

   emergencyCallDa= ta.eCall.control+xml') in the Content-Type header

   field of the bo= dy part.  The body part is assigned a unique

   identifier whic= h is listed in a Content-ID header field in the body

   part.  The= SIP message is marked as containing the metadata/control=

   object by addin= g (or appending to) a Call-Info header field at the

   top level of th= e SIP message.  This Call-Info header field contains a

   CID URL referencing the body part's uniqu= e identifier, and a

   'purpose' parameter identifying the data = as an eCall metadata/control

   block per the Emergency Call Additional D= ata Blocks registry entry;

   the 'purpose' parameter's value is 'emerg= encyCallData.eCall.control'.<= /p>

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

and

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

SIP/2.0 200 OK

    &nbs= p; To: <sip:+1314555111= 1@example.com>;tag=3D9fxced76sl

    &nbs= p; From: Exemplar PSAP <urn:service:sos.ecall.automatic>

    &nbs= p; Call-ID: 3848276298220188511@atlanta.example.com

    &nbs= p; Call-Info: cid:2345678901@at= lanta.example.com;

         =         purpose=3DemergencyCallData.eCal= l.control;

    &nbs= p; Accept: application/sdp, application/pidf+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.control+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.MSD+per

    &nbs= p; CSeq: 31862 INVITE

    &nbs= p; Recv-Info: emergencyCallData.eCall.MSD

    &nbs= p; Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,=

    &nbs= p;        SUBSCRIBE, NOTIFY, UPDATE=

    &nbs= p; Content-Type: multipart/mixed; boundary=3DboundaryX

    &nbs= p; Content-Length: ...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/sdp

 

    &nbs= p;      ...Session Description Protocol (SDP) goes= here...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/EmergencyCallData.eCall.control+xml

    &nbs= p; Content-ID: 2345678901@at= lanta.example.com

    &nbs= p; Content-Disposition: by-reference;handling=3Doptional<= /p>

 

    &nbs= p; <?xml version=3D"1.0" encoding=3D"UTF-8"?>

    &nbs= p; <EmergencyCallData.eCall.Control

    &nbs= p;     xmlns=3D"urn:ietf:params:xml:ns:EmergencyCa= llData:eCall:control"

    &nbs= p;     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=

    &nbs= p;     xsi:schemaLocation=3D

    &nbs= p;         "urn:ietf:params:xm= l:ns:EmergencyCallData:eCall:control">

 

    &nbs= p; <ack received=3D"true" ref=3D"1234567890@atlanta.example.com"/>=

 

    &nbs= p; </EmergencyCallData.eCall.Control>

 

    &nbs= p; --boundaryX--

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

 

Kind regards

 

Ivo

 

-----Original Message----- From: Ecrit [mailto:ecrit-bounces= @ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that th= e Call-Info that refers to the body is unnecessary because the recipient wi= ll know what to do with the body even in the absence of the Call-Info. Is t= hat right?

 

This assumption mixes up two= things:

- understanding a body synta= ctically

- understanding *why* the bo= dy is present and how it should be used.

 

Historically, processing of = body parts in sip was very poorly defined.

Initially the only body of i= nterest was SDP, so how one might process other bodies or body parts was no= t well considered. Eventually this started to be a liability, so RFC5621 wa= s published to clarify it.

 

Processing of body parts is = governed by a complex interaction between Content-Type, Content-Disposition= , Content-ID.

 

So the call-info header indi= cates the reason that body is being included. I realize that there is one p= redominant reason for doing so, but that is not the only possible reason. (= E.g., it might be included as context in an intended discussion about problems handling a call in the=

past.)

 

If all the handling of the c= all is coded in a special purpose way, solely for the emergency call path, = then alternatives may be of no concern. But ideally the call will largely b= e handled via standard library code that is also used for other call paths and other message processing. So pr= ocessing body parts in a "standard" way, rather than special casi= ng, is desirable.

 

    &nbs= p;           Thanks,=

    &nbs= p;           Paul

 

On 8/5/16 7:15 AM, Ivo Sedla= cek wrote:

> Hello,

> =

> =

> =

> COMMENT:

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Inclusion of Call-Info = header field with

> purpose=3DemergencyCall= Data.eCall.MSD or

> purpose=3DemergencyCall= Data.eCall.control in requests and responses does

> not seem to bring any v= alue. It seems to only waste radio resources.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.MSD included in the

> initial INVITE request:=

> =

> - if this is meant to b= e used by a proxy for routing of the eCall

> emergency call to a PSA= P supporting eCall emergency call, then this

> seems to be redundant t= o the eCall URN included in the Request-URI and

> the Recv-Info header fi= eld containing eCall specific info package

> (emergencyCallData.eCal= l.MSD).

> =

> - if this is meant to b= e used by UAS (i.e. PSAP), then according to

> RFC3261 subclause 8.2.3= , then the UAS anyway needs to check that all

> the bodies of the INVIT= E request not marked with Content-Disposition:

> ...; handling=3Doptiona= l are understood. So,

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INVITE request processing.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> a response to the initi= al INVITE request

> =

> - no routing decisions = are done by proxies when receiving a response

> to the initial INVITE r= equest so this does not seem to have any value

> for the proxies

> =

> - UAC includes Accept w= ith supported MIME types in INVITE request so

> why would UAS send any = MIME body not wished by the UAC?

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> the INFO request

> =

> - no routing decisions = are done by proxies when receiving an in-dialog

> request so this does no= t seem to have any value for the proxies

> =

> - support of info packa= ge emergencyCallData.eCall.MSD in the call

> implies that either app= lication/EmergencyCallData.eCall.control+xml

> MIME body or applicatio= n/emergencyCallData.eCall.MSD+per MIME body is

> included. Again, accord= ing to RFC3261 subclause 8.2.3, the UAS anyway

> needs to check that all= the bodies of the INFO request not marked with

> Content-Disposition: ..= .; handling=3Doptional are understood. So,

> application/EmergencyCa= llData.eCall.control+xml MIME body or

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INFO request processing.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> PROPOSED SOLUTION to CO= MMENT

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Remove insertion of Cal= l-Info header field.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> =

> =

> Kind regards=

> =

> =

> =

> Ivo Sedlacek=

> =

> =

> =

> _______________________= ________________________

> Ecrit mailing list=

> Ecrit@ietf= .org

> https://www.ietf.org/= mailman/listinfo/ecrit

> =

 

____________________________= ___________________

Ecrit mailing list

Ecrit@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/ecrit

--_000_7594FB04B1934943A5C02806D1A2204B4BBBD15BESESSMB208erics_-- From nobody Mon Aug 8 04:41:37 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 B2FC512D598 for ; Mon, 8 Aug 2016 04:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 Tu_yRt2CtWOq for ; Mon, 8 Aug 2016 04:41:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0AF2A12D7FF for ; Mon, 8 Aug 2016 04:41:00 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-67-57a86fc93299 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id AD.D8.02553.9CF68A75; Mon, 8 Aug 2016 13:40:59 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 13:40:56 +0200 From: Ivo Sedlacek To: "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8VmRA5QXrnFEl02LmniZy10/tqA+7Rcg Date: Mon, 8 Aug 2016 11:40:57 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.149] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101164C0868ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7iu7p/BXhBiemc1k0LnrKarFiwwFW i6Y7XWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6MXVcfsBfsOclU8eDxduYG xjnzmboYOTkkBEwkpkycxdLFyMUhJLCeUWLmxw42CGcxo8SZA3tYQKrYBPQkJm45wgqSEBFo ZZT41tIP5ggLLGSUuDF/JRtEZhGjxPZPB8FaRASMJJ4eugNmswioSFztf8EMYvMK+Eoc/raU EWLHFEaJm4va2EASnAKBEhtfnGAFsRkFZCWu/ullBLGZBcQlbj2BuVZAYsme88wQtqjEy8f/ WCFsJYm1h7ezQNTnS9xYdp8VYpmgxMmZT1gmMArPQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18 zQxjnznwmAlZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwPg6uOW3wQ7Gl88dDzEK cDAq8fAqlC8PF2JNLCuuzD3EKMHBrCTCeydvRbgQb0piZVVqUX58UWlOavEhRmkOFiVxXv+X iuFCAumJJanZqakFqUUwWSYOTqkGxuXCtQy/NZhCpnbu5zdfaDS/4e9Sg53zRc+IRe6LvKUU N8WJXyHo76rI0pzGCXZpatpHS6v4al+YmwYEh1zt3q9ys8em+OmTKwJbX4VPmJOXdrfY/gm7 d1ZkYEPypKvceb+krr8JbQkXYkj74vY+rdTDT21zT9fS6a/dbmjNElfMmrntI9d1JZbijERD Leai4kQA0gYp6qsCAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 11:41:19 -0000 --_000_39B5E4D390E9BD4890E2B31079006101164C0868ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Roland, UAS (i.e. PSAP) needs to check all the bodies of INVITE request (except whe= re there is Content-Disposition with handling=3Doptional), so it should be = irrelevant for the PSAP whether the Call-Info with cid URL pointing to the = body containing MSD is included or not. The actual presence of the body con= taining MSD in the INVITE is important for PSAP to decide whether NG-eCall = emergency call takes place or in-band modem eCall emergency call takes plac= e. Furthermore, given that draft-ietf-ecrit-ecall mandates the UE to indicate = support of the emergencyCallData.eCall.MSD info package in INVITE request, = the routing of NG-eCall emergency call to a PSAP different than the one rec= eiving in-band modem eCall emergency call can be done based on Recv-Info: e= mergencyCallData.eCall.MSD in INVITE request with Request-URI set to an eCa= ll URN. Kind regards Ivo From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Monday, August 08, 2016 11:45 AM To: Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org Subject: AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Ivo, using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly m= eans using the MSD within the Body. It could be also an interworked call wh= ere all ecall information is included inband using the In-band modem soluti= on. We have to think also on backwards compatibility issues. Thus when moving = PSAP's to SIP imply also that there must exist an interworking between the = old mobile world towards the new mobile world using SIP. Using the Call-Info header would help the PAST to distinguish the in-band a= nd outband solution. Perhaps it would be worth to define an additional valu= e for inband data, to identify ecalls coming from other networks not suppor= ting the MSD Body. Best Regards Roland. Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Montag, 8. August 2016 09:59 An: Paul Kyzivat; ecrit@ietf.org Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wit= h RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no val= ue) Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional "/> --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_39B5E4D390E9BD4890E2B31079006101164C0868ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Roland,

 

UAS (i.e. PSAP) needs = to check all the bodies of INVITE request (except where there is Content-Di= sposition with handling=3Doptional), so it should be irrelevant for the PSA= P whether the Call-Info with cid URL pointing to the body containing MSD is included or not. The actual presence of the = body containing MSD in the INVITE is important for PSAP to decide whether N= G-eCall emergency call takes place or in-band modem eCall emergency call ta= kes place.

 

Furthermore, given tha= t draft-ietf-ecrit-ecall mandates the UE to indicate support of the emergen= cyCallData.eCall.MSD info package in INVITE request, the routing of NG-eCal= l emergency call to a PSAP different than the one receiving in-band modem eCall emergency call can be done base= d on Recv-Info: emergencyCallData.eCall.MSD in INVITE request with Request-= URI set to an eCall URN.

 

Kind regards

 

Ivo<= /p>

 

From: R.Jesske= @telekom.de [mailto:R.Jesske@telekom.de]
Sent: Monday, August 08, 2016 11:45 AM
To: Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org
Subject: AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage br= ings no value)

 

Hi Ivo,

using the ecall urn (urn:service:sos.ecall.automatic) does n=
ot implicitly means using the MSD within the Body. It could be also an inte=
rworked call where all ecall information is included inband using the In-ba=
nd modem solution.
 
We have to think also on backwards compatibility issues. &nb=
sp;Thus when moving PSAP’s to SIP imply also that there must exist an=
 interworking between the old mobile world towards the new mobile world usi=
ng SIP.
 
Using the Call-Info header would help the PAST to distinguis=
h the in-band and outband solution. Perhaps it would be worth to define an =
additional value for inband data, to identify ecalls coming from other netw=
orks not supporting the MSD Body.
 
Best Regards

Roland.

 = ;

 = ;

Von: Ecrit [mailto:ecri= t-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; ecrit@ietf= .org
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not alig= ned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings= no value)

 

Hello,

 

According to RFC3261, the Call-Info header field = provides additional information about the caller or callee.

 

According to draft-ietf-ecrit-ecall-11, the Call-= Info header field is used to form a "content-table" of pointers t= o bodies INVITE request (and of INVITE response, of INFO request) in header= s of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header field points to a body wh= ich describes the callers or callee, then Call-Info semantic fits (even tho= ugh I would still question usefulness of such Call-Info inclusion).

 

If the Call-Info header field points to a body wh= ich request an action in remote UE and which reports to remote UE an outcom= e of an action done by the local UE, then Call-Info semantic does not fit.<= o:p>

 

Particularly:

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

   A PSAP or IVS transmits a metadata/c= ontrol object (see Section 9) by

   encoding it per the description in t= his document and attaching it to

   a SIP message as a MIME body part pe= r [RFC7852].  The body part is

   identified by its MIME content-type = ('application/

   emergencyCallData.eCall.control+= xml') in the Content-Type header

   field of the body part.  The bo= dy part is assigned a unique

   identifier which is listed in a Cont= ent-ID header field in the body

   part.  The SIP message is marke= d as containing the metadata/control

   object by adding (or appending to) a= Call-Info header field at the

   top level of the SIP message.  = This Call-Info header field contains a

   CID URL referencing the body part's unique identifier, a= nd a

   'purpose' parameter identifying the data as an eCall met= adata/control

   block per the Emergency Call Additional Data Blocks regi= stry entry;

   the 'purpose' parameter's value is 'emergencyCallData.eC= all.control'.

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

and

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

SIP/2.0 200 OK

      To: <sip:+13145551111@example.com>= ;tag=3D9fxced76sl

      From: Exemplar PSA= P <urn:service:sos.ecall.automatic>

      Call-ID: 3848276298220188511@atlanta.example.com

      Call-Info: cid:2345678901@at= lanta.example.com;

           &nb= sp;     purpose=3DemergencyCallData.eCall.control;

      Accept: applicatio= n/sdp, application/pidf+xml,

        &= nbsp;     application/emergencyCallData.eCall.control&#= 43;xml,

        &= nbsp;     application/emergencyCallData.eCall.MSD+p= er

      CSeq: 31862 INVITE=

      Recv-Info: emergen= cyCallData.eCall.MSD

      Allow: INVITE, ACK= , PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,

        &= nbsp;    SUBSCRIBE, NOTIFY, UPDATE

      Content-Type: mult= ipart/mixed; boundary=3DboundaryX

      Content-Length: ..= .

 

      --boundaryX

      Content-Type: appl= ication/sdp

 

        &= nbsp;  ...Session Description Protocol (SDP) goes here...

 

      --boundaryX

      Content-Type: appl= ication/EmergencyCallData.eCall.control+xml

      Content-ID: 2345678901@at= lanta.example.com

      Content-Dispositio= n: by-reference;handling=3Doptional

 

      <?xml version= =3D"1.0" encoding=3D"UTF-8"?>

      <EmergencyCallD= ata.eCall.Control

        &= nbsp; xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control&= quot;

        &= nbsp; xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

        &= nbsp; xsi:schemaLocation=3D

        &= nbsp;     "urn:ietf:params:xml:ns:EmergencyCallDat= a:eCall:control">

 

      <ack received=3D"true" ref=3D"1234567890@atlanta.example.com"/>=

 

      </EmergencyCall= Data.eCall.Control>

 

      --boundaryX--=

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

 

Kind regards

 

Ivo

 

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces= @ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that the Call-Info that refe= rs to the body is unnecessary because the recipient will know what to do wi= th the body even in the absence of the Call-Info. Is that right?=

 

This assumption mixes up two things:

- understanding a body syntactically

- understanding *why* the body is present and how= it should be used.

 

Historically, processing of body parts in sip was= very poorly defined.

Initially the only body of interest was SDP, so h= ow one might process other bodies or body parts was not well considered. Ev= entually this started to be a liability, so RFC5621 was published to clarif= y it.

 

Processing of body parts is governed by a complex= interaction between Content-Type, Content-Disposition, Content-ID.

 

So the call-info header indicates the reason that= body is being included. I realize that there is one predominant reason for= doing so, but that is not the only possible reason. (E.g., it might be inc= luded as context in an intended discussion about problems handling a call in the

past.)

 

If all the handling of the call is coded in a spe= cial purpose way, solely for the emergency call path, then alternatives may= be of no concern. But ideally the call will largely be handled via standar= d library code that is also used for other call paths and other message processing. So processing body parts in= a "standard" way, rather than special casing, is desirable.=

 

        &= nbsp;       Thanks,

        &= nbsp;       Paul

 

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:=

> Hello,

> 

> 

> 

> COMMENT:

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Inclusion of Call-Info header field with

> purpose=3DemergencyCallData.eCall.MSD or

> purpose=3DemergencyCallData.eCall.control in= requests and responses does

> not seem to bring any value. It seems to onl= y waste radio resources.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.MSD included in the

> initial INVITE request:

> 

> - if this is meant to be used by a proxy for= routing of the eCall

> emergency call to a PSAP supporting eCall em= ergency call, then this

> seems to be redundant to the eCall URN inclu= ded in the Request-URI and

> the Recv-Info header field containing eCall = specific info package

> (emergencyCallData.eCall.MSD).

> 

> - if this is meant to be used by UAS (i.e. P= SAP), then according to

> RFC3261 subclause 8.2.3, then the UAS anyway= needs to check that all

> the bodies of the INVITE request not marked = with Content-Disposition:

> ...; handling=3Doptional are understood. So,=

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INVITE request proce= ssing.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> a response to the initial INVITE request

> 

> - no routing decisions are done by proxies w= hen receiving a response

> to the initial INVITE request so this does n= ot seem to have any value

> for the proxies

> 

> - UAC includes Accept with supported MIME ty= pes in INVITE request so

> why would UAS send any MIME body not wished = by the UAC?

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> the INFO request

> 

> - no routing decisions are done by proxies w= hen receiving an in-dialog

> request so this does not seem to have any va= lue for the proxies

> 

> - support of info package emergencyCallData.= eCall.MSD in the call

> implies that either application/EmergencyCal= lData.eCall.control+xml

> MIME body or application/emergencyCallData.e= Call.MSD+per MIME body is

> included. Again, according to RFC3261 subcla= use 8.2.3, the UAS anyway

> needs to check that all the bodies of the IN= FO request not marked with

> Content-Disposition: ...; handling=3Doptiona= l are understood. So,

> application/EmergencyCallData.eCall.control&= #43;xml MIME body or

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INFO request process= ing.

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> PROPOSED SOLUTION to COMMENT

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Remove insertion of Call-Info header field.<= o:p>

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> 

> 

> Kind regards

> 

> 

> 

> Ivo Sedlacek

> 

> 

> 

> ____________________________________________= ___

> Ecrit mailing list

> Ecrit@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/ecrit

> 

 

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ecrit

--_000_39B5E4D390E9BD4890E2B31079006101164C0868ESESSMB301erics_-- From nobody Mon Aug 8 05:56: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 3D6BA12B00C for ; Mon, 8 Aug 2016 05:56:26 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ZSAtnEkGOPkt for ; Mon, 8 Aug 2016 05:56:24 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 B38D012B00B for ; Mon, 8 Aug 2016 05:56:24 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-12v.sys.comcast.net with SMTP id Wk6GbXTlylHMYWk6SbmDzJ; Mon, 08 Aug 2016 12:56:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id Wk6Rb0Fd7J1sWWk6Rb577u; Mon, 08 Aug 2016 12:56:24 +0000 To: Ivo Sedlacek , Christer Holmberg , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <66f70516-ed5f-1e9d-ee7b-0b8bb16a6bc7@alum.mit.edu> Date: Mon, 8 Aug 2016 08:56:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKfIuxYTjkMLV+R86I7U/LYKWEXmG982IAS9YH+YFJkql244nZ78gAROQ/jozgaquaUM6m/1pHRwWpm5uqWhDcio/M+6pdtHsJDpUZgdEYTVQZPY/ONE hjG3e41KpDLAK2j9V/T6a+XsqFm+YC9xYehPI7zDSyFoty9GRbZOVvdtRq1qjaimusqVnU//U5m8DycJ4Q8U+HCGvjKlQ4ojSU0vajJYEa8ybXaBiS6Q6bew X0qPAWLoB8DpzHFxWtV0i3Yk5orMkAHUwdByOaFxzgc= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 08 Aug 2016 12:56:27 -0000 On 8/8/16 3:43 AM, Ivo Sedlacek wrote: > Hello Paul, > > > > the comment explicitly referred to INVITE and to INFO. OK. My position is that call-info is proper to use in INVITE. It should not be necessary in INFO. Whether it is incorrect to use it in INFO is arguable either way. Thanks, Paul > Excerpts from the attached: > > --------------- > > For Call-Info with purpose=emergencyCallData.eCall.MSD included in the > initial INVITE request: > > ... > > For Call-Info with purpose=emergencyCallData.eCall.control included in a > response to the initial INVITE request > > ... > > For Call-Info with purpose=emergencyCallData.eCall.control included in > the INFO request > > ... > > --------------- > > > > Kind regards > > > > Ivo > > > > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, August 05, 2016 6:50 PM > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > > > On 8/5/16 11:14 AM, Christer Holmberg wrote: > >> Hi Paul, > >> > >> In INFOs, the info package specification shall indicate WHY a message > >> body is included. That was one of the main reason for doing the info > >> package mechanism. > >> > >> And, as Ivo also indicated, INFOs will be routed according to the > >> established route set. > > > > I didn't think this was about INFO. I agree that in INFO, as long as the > body is properly marked as the package body for the INFO that a > call-info pointing to it isn't needed, and not appropriate. > > > > Thanks, > > Paul > > > >> Regards, > >> > >> Christer > >> > >> Sent from my Windows Phone > >> ---------------------------------------------------------------------- > >> -- > >> From: Paul Kyzivat > >> Sent: ‎05/‎08/‎2016 17:43 > >> To: ecrit@ietf.org > >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > >> no value > >> > >> Ivo, > >> > >> IIUC, you are saying that the Call-Info that refers to the body is > >> unnecessary because the recipient will know what to do with the body > >> even in the absence of the Call-Info. Is that right? > >> > >> This assumption mixes up two things: > >> - understanding a body syntactically > >> - understanding *why* the body is present and how it should be used. > >> > >> Historically, processing of body parts in sip was very poorly defined. > >> Initially the only body of interest was SDP, so how one might process > >> other bodies or body parts was not well considered. Eventually this > >> started to be a liability, so RFC5621 was published to clarify it. > >> > >> Processing of body parts is governed by a complex interaction between > >> Content-Type, Content-Disposition, Content-ID. > >> > >> So the call-info header indicates the reason that body is being > >> included. I realize that there is one predominant reason for doing so, > >> but that is not the only possible reason. (E.g., it might be included > >> as context in an intended discussion about problems handling a call in > >> the > >> past.) > >> > >> If all the handling of the call is coded in a special purpose way, > >> solely for the emergency call path, then alternatives may be of no > >> concern. But ideally the call will largely be handled via standard > >> library code that is also used for other call paths and other message > >> processing. So processing body parts in a "standard" way, rather than > >> special casing, is desirable. > >> > >> Thanks, > >> Paul > >> > >> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > >>> Hello, > >>> > >>> > >>> > >>> COMMENT: > >>> > >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >>> \\\\\\\\\ > >>> > >>> Inclusion of Call-Info header field with > >>> purpose=emergencyCallData.eCall.MSD or > >>> purpose=emergencyCallData.eCall.control in requests and responses > >>> does not seem to bring any value. It seems to only waste radio resources. > >>> > >>> > >>> > >>> For Call-Info with purpose=emergencyCallData.eCall.MSD included in > >>> the initial INVITE request: > >>> > >>> - if this is meant to be used by a proxy for routing of the eCall > >>> emergency call to a PSAP supporting eCall emergency call, then this > >>> seems to be redundant to the eCall URN included in the Request-URI > >>> and the Recv-Info header field containing eCall specific info package > >>> (emergencyCallData.eCall.MSD). > >>> > >>> - if this is meant to be used by UAS (i.e. PSAP), then according to > >>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > >>> the bodies of the INVITE request not marked with Content-Disposition: > >>> ...; handling=optional are understood. So, > >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >>> found by UAS during the INVITE request processing. > >>> > >>> > >>> > >>> For Call-Info with purpose=emergencyCallData.eCall.control included > >>> in a response to the initial INVITE request > >>> > >>> - no routing decisions are done by proxies when receiving a response > >>> to the initial INVITE request so this does not seem to have any value > >>> for the proxies > >>> > >>> - UAC includes Accept with supported MIME types in INVITE request so > >>> why would UAS send any MIME body not wished by the UAC? > >>> > >>> > >>> > >>> For Call-Info with purpose=emergencyCallData.eCall.control included > >>> in the INFO request > >>> > >>> - no routing decisions are done by proxies when receiving an > >>> in-dialog request so this does not seem to have any value for the > >>> proxies > >>> > >>> - support of info package emergencyCallData.eCall.MSD in the call > >>> implies that either application/EmergencyCallData.eCall.control+xml > >>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > >>> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > >>> needs to check that all the bodies of the INFO request not marked > >>> with > >>> Content-Disposition: ...; handling=optional are understood. So, > >>> application/EmergencyCallData.eCall.control+xml MIME body or > >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >>> found by UAS during the INFO request processing. > >>> > >>> ///////////////////////////////////////////////////////////////////// > >>> ///////// > >>> > >>> PROPOSED SOLUTION to COMMENT > >>> > >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >>> \\\\\\\\\ > >>> > >>> Remove insertion of Call-Info header field. > >>> > >>> ///////////////////////////////////////////////////////////////////// > >>> ///////// > >>> > >>> > >>> > >>> Kind regards > >>> > >>> > >>> > >>> Ivo Sedlacek > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Mon Aug 8 06:13: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 021AE12D81C for ; Mon, 8 Aug 2016 06:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 p1ZatQ9UAbgU for ; Mon, 8 Aug 2016 06:13:20 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id BFBB112D81B for ; Mon, 8 Aug 2016 06:13:19 -0700 (PDT) X-AuditID: 1207440e-dafff70000000931-d2-57a8856d62c1 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id A7.69.02353.D6588A75; Mon, 8 Aug 2016 09:13:18 -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 u78DDDhG021474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Aug 2016 09:13:16 -0400 To: Ivo Sedlacek , "R.Jesske@telekom.de" , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 8 Aug 2016 09:13:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixO6iqJvXuiLcoHsZt0XjoqesFr0r57Fa NN3pYnNg9vj19Sqbx5IlP5k82l4qBDBHcdmkpOZklqUW6dslcGWc3n+SpeBzSsXspjdMDYwb /bsYOTkkBEwkbv/tY+xi5OIQEtjKKPFp/jMmCOcJk0RvfzcjSJWwwEJGiQsPREASIgITGCX2 3+iGqrrBKHHx+GMWkCo2AS2JOYf+g9m8AvYSD6/NZwKxWQRUJP5+nMwKYosKpElMP9zPCFEj KHFy5hOwek4BP4m/G7+B2cwCthJ35u5mhrDlJZq3zmaewMg3C0nLLCRls5CULWBkXsUol5hT mqubm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokREpB8Oxjb18scYhTgYFTi4a2oXB4uxJpY VlyZe4hRkoNJSZRXSmlFuBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3pQGoBxvSmJlVWpRPkxK moNFSZxXbYm6n5BAemJJanZqakFqEUxWhoNDSYL3cAtQo2BRanpqRVpmTglCmomDE2Q4D9Dw YyA1vMUFibnFmekQ+VOMuhx9ux+sZRJiycvPS5US533VDFQkAFKUUZoHNweWSF4xigO9Jcyr ATKKB5iE4Ca9AlrCBLQkSRVsSUkiQkqqgdHuc4KjwmWv90Zb4312u+0s9v+a9WBa8ZXjaU7Z qobqwWUcJ948Prl8quSBNwbZnA2ZjxyF7l/fyhCtL6vqL5Si0GXa/6LvpwzbO4P9M5duiwi9 d3Ix294AyaUxS5KEL1tffqipffPW5fdSl236Siy+3VHy/zjVb1X6ou1HrNmSvZ0nyLhxOSmx FGckGmoxFxUnAgB4EslW/wIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 13:13:31 -0000 On 8/8/16 7:40 AM, Ivo Sedlacek wrote: > Hello Roland, > > > > UAS (i.e. PSAP) needs to check all the bodies of INVITE request (except > where there is Content-Disposition with handling=optional), so it should > be irrelevant for the PSAP whether the Call-Info with cid URL pointing > to the body containing MSD is included or not. The actual presence of > the body containing MSD in the INVITE is important for PSAP to decide > whether NG-eCall emergency call takes place or in-band modem eCall > emergency call takes place. By that logic there should *never* (for any SIP message) be a reason to refer to a body part from a header - the body should always be processed by virtue of its presence. In this case, IIUC, there *could* be a call-info header pointing to the ecall info in an external server. The data being in a body part is simply a special case of that. So it makes sense to me that the starting point for discovering ecall data be with the call-info header. (Again, I'm not talking about INFO here. The situation is different for it.) > Furthermore, given that draft-ietf-ecrit-ecall mandates the UE to > indicate support of the emergencyCallData.eCall.MSD info package in > INVITE request, the routing of NG-eCall emergency call to a PSAP > different than the one receiving in-band modem eCall emergency call can > be done based on Recv-Info: emergencyCallData.eCall.MSD in INVITE > request with Request-URI set to an eCall URN. The indication of support for info packages in the INVITE is intended to facilitate negotiation of the use of INFO. IMO using that to affect how bodies in the INVITE itself is wrong. Thanks, Paul > Kind regards > > > > Ivo > > > > *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > *Sent:* Monday, August 08, 2016 11:45 AM > *To:* Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org > *Subject:* AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage > brings no value) > > > > Hi Ivo, > > using the ecall urn (urn:service:sos.ecall.automatic) does not > implicitly means using the MSD within the Body. It could be also an > interworked call where all ecall information is included inband using > the In-band modem solution. > > > > We have to think also on backwards compatibility issues. Thus when > moving PSAP’s to SIP imply also that there must exist an interworking > between the old mobile world towards the new mobile world using SIP. > > > > Using the Call-Info header would help the PAST to distinguish the > in-band and outband solution. Perhaps it would be worth to define an > additional value for inband data, to identify ecalls coming from other > networks not supporting the MSD Body. > > > > Best Regards > > > Roland. > > > > > > *Von:*Ecrit [mailto:ecrit-bounces@ietf.org] *Im Auftrag von *Ivo Sedlacek > *Gesendet:* Montag, 8. August 2016 09:59 > *An:* Paul Kyzivat; ecrit@ietf.org > *Betreff:* [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage > brings no value) > > > > Hello, > > > > According to RFC3261, the Call-Info header field provides additional > information about the caller or callee. > > > > According to draft-ietf-ecrit-ecall-11, the Call-Info header field is > used to form a "content-table" of pointers to bodies INVITE request (and > of INVITE response, of INFO request) in headers of INVITE request (and > of INVITE response, of INFO request). > > > > If the Call-Info header field points to a body which describes the > callers or callee, then Call-Info semantic fits (even though I would > still question usefulness of such Call-Info inclusion). > > > > If the Call-Info header field points to a body which request an action > in remote UE and which reports to remote UE an outcome of an action done > by the local UE, then Call-Info semantic does not fit. > > > > Particularly: > > ------------------------------------------------------------------------------ > > A PSAP or IVS transmits a metadata/control object (see Section 9) by > > encoding it per the description in this document and attaching it to > > a SIP message as a MIME body part per [RFC7852]. The body part is > > identified by its MIME content-type ('application/ > > emergencyCallData.eCall.control+xml') in the Content-Type header > > field of the body part. The body part is assigned a unique > > identifier which is listed in a Content-ID header field in the body > > part. The SIP message is marked as containing the metadata/control > > object by adding (or appending to) a Call-Info header field at the > > top level of the SIP message. This Call-Info header field contains a > > CID URL referencing the body part's unique identifier, and a > > 'purpose' parameter identifying the data as an eCall metadata/control > > block per the Emergency Call Additional Data Blocks registry entry; > > the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. > > ------------------------------------------------------------------------------ > > and > > ------------------------------------------------------------------------------ > > SIP/2.0 200 OK > > To: ;tag=9fxced76sl > > From: Exemplar PSAP > > Call-ID: 3848276298220188511@atlanta.example.com > > > Call-Info: cid:2345678901@atlanta.example.com; > > purpose=emergencyCallData.eCall.control; > > Accept: application/sdp, application/pidf+xml, > > application/emergencyCallData.eCall.control+xml, > > application/emergencyCallData.eCall.MSD+per > > CSeq: 31862 INVITE > > Recv-Info: emergencyCallData.eCall.MSD > > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > > SUBSCRIBE, NOTIFY, UPDATE > > Content-Type: multipart/mixed; boundary=boundaryX > > Content-Length: ... > > > > --boundaryX > > Content-Type: application/sdp > > > > ...Session Description Protocol (SDP) goes here... > > > > --boundaryX > > Content-Type: application/EmergencyCallData.eCall.control+xml > > Content-ID: 2345678901@atlanta.example.com > > > Content-Disposition: by-reference;handling=optional > > > > > > > xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation= > > "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> > > > > > > > > > > > > --boundaryX-- > > ------------------------------------------------------------------------------ > > > > Kind regards > > > > Ivo > > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, August 05, 2016 4:43 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > > > Ivo, > > > > IIUC, you are saying that the Call-Info that refers to the body is > unnecessary because the recipient will know what to do with the body > even in the absence of the Call-Info. Is that right? > > > > This assumption mixes up two things: > > - understanding a body syntactically > > - understanding *why* the body is present and how it should be used. > > > > Historically, processing of body parts in sip was very poorly defined. > > Initially the only body of interest was SDP, so how one might process > other bodies or body parts was not well considered. Eventually this > started to be a liability, so RFC5621 was published to clarify it. > > > > Processing of body parts is governed by a complex interaction between > Content-Type, Content-Disposition, Content-ID. > > > > So the call-info header indicates the reason that body is being > included. I realize that there is one predominant reason for doing so, > but that is not the only possible reason. (E.g., it might be included as > context in an intended discussion about problems handling a call in the > > past.) > > > > If all the handling of the call is coded in a special purpose way, > solely for the emergency call path, then alternatives may be of no > concern. But ideally the call will largely be handled via standard > library code that is also used for other call paths and other message > processing. So processing body parts in a "standard" way, rather than > special casing, is desirable. > > > > Thanks, > > Paul > > > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > >> Hello, > >> > >> > >> > >> COMMENT: > >> > >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >> \\\\\\\\ > >> > >> Inclusion of Call-Info header field with > >> purpose=emergencyCallData.eCall.MSD or > >> purpose=emergencyCallData.eCall.control in requests and responses does > >> not seem to bring any value. It seems to only waste radio resources. > >> > >> > >> > >> For Call-Info with purpose=emergencyCallData.eCall.MSD included in the > >> initial INVITE request: > >> > >> - if this is meant to be used by a proxy for routing of the eCall > >> emergency call to a PSAP supporting eCall emergency call, then this > >> seems to be redundant to the eCall URN included in the Request-URI and > >> the Recv-Info header field containing eCall specific info package > >> (emergencyCallData.eCall.MSD). > >> > >> - if this is meant to be used by UAS (i.e. PSAP), then according to > >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > >> the bodies of the INVITE request not marked with Content-Disposition: > >> ...; handling=optional are understood. So, > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >> found by UAS during the INVITE request processing. > >> > >> > >> > >> For Call-Info with purpose=emergencyCallData.eCall.control included in > >> a response to the initial INVITE request > >> > >> - no routing decisions are done by proxies when receiving a response > >> to the initial INVITE request so this does not seem to have any value > >> for the proxies > >> > >> - UAC includes Accept with supported MIME types in INVITE request so > >> why would UAS send any MIME body not wished by the UAC? > >> > >> > >> > >> For Call-Info with purpose=emergencyCallData.eCall.control included in > >> the INFO request > >> > >> - no routing decisions are done by proxies when receiving an in-dialog > >> request so this does not seem to have any value for the proxies > >> > >> - support of info package emergencyCallData.eCall.MSD in the call > >> implies that either application/EmergencyCallData.eCall.control+xml > >> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > >> needs to check that all the bodies of the INFO request not marked with > >> Content-Disposition: ...; handling=optional are understood. So, > >> application/EmergencyCallData.eCall.control+xml MIME body or > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >> found by UAS during the INFO request processing. > >> > >> ////////////////////////////////////////////////////////////////////// > >> //////// > >> > >> PROPOSED SOLUTION to COMMENT > >> > >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >> \\\\\\\\ > >> > >> Remove insertion of Call-Info header field. > >> > >> ////////////////////////////////////////////////////////////////////// > >> //////// > >> > >> > >> > >> Kind regards > >> > >> > >> > >> Ivo Sedlacek > >> > >> > >> > >> _______________________________________________ > >> 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 Mon Aug 8 06:35: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 41A4A12D832 for ; Mon, 8 Aug 2016 06:35:17 -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 jORWg2RxCVSv for ; Mon, 8 Aug 2016 06:35:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 56C1012D80B for ; Mon, 8 Aug 2016 06:34:50 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-83-57a88a7841a7 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id E9.A2.04209.87A88A75; Mon, 8 Aug 2016 15:34:48 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 15:34:04 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR8XRG8cqfwC1TM0Oikpf6Wf0+iqA/ECeP Date: Mon, 8 Aug 2016 13:34:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBBF8D8@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se>, <66f70516-ed5f-1e9d-ee7b-0b8bb16a6bc7@alum.mit.edu> In-Reply-To: <66f70516-ed5f-1e9d-ee7b-0b8bb16a6bc7@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BBBF8D8ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7vW5F14pwg2nbdCwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxbNVJloJVmxgr/i7/zdbA+GUKYxcjJ4eE gInE+/ZGti5GLg4hgfWMEsfv32WFcBYzSvQtXwGU4eBgE7CQ6P6nDdIgIlAusWbGTHYQW1gg UGLduTWMEPEgiZ8P10PZRhJf2nqZQWwWARWJqdNmgtm8Ar4Sje1voeZ/ZZI4suMWC0iCU8BB orXrDhOIzSggJvH91Bowm1lAXKLpy0pWiEsFJJbsOc8MYYtKvHz8jxWiJl/i/6wZ7BALBCVO znzCMoFRaBaS9llIymYhKYOIG0h8eX8bytaWWLbwNTOErS/R/f40E7L4Akb2VYyixanFSbnp RsZ6qUWZycXF+Xl6eaklmxiB0XJwy2/VHYyX3zgeYhTgYFTi4VUoXx4uxJpYVlyZe4hRgoNZ SYQ3snVFuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQZG t9w7IjXW5iqPLndWqtRN2a9xMM/Hc9KOjX4rr128NPurlNefpXeZFKSvv3g6z+c7i6BA467m N38vMkXtPsJnc7TgjaWlwgrejijOTZr78h3c3RV/qthGMewsDA73yu0veDJjlerN1ZGhl81M 7BfzHpr3sfyN/HlLoXpN+4WNZvIS3s+9vAKUWIozEg21mIuKEwEYggCPkgIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 08 Aug 2016 13:35:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBBF8D8ESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, It is allowed to include Call-Info in INFO - that's not the issue. The ques= tion is WHY we would mandate it. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD08/=FD08/=FD2016 15:56 To: Ivo Sedlacek; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue On 8/8/16 3:43 AM, Ivo Sedlacek wrote: > Hello Paul, > > > > the comment explicitly referred to INVITE and to INFO. OK. My position is that call-info is proper to use in INVITE. It should not be necessary in INFO. Whether it is incorrect to use it in INFO is arguable either way. Thanks, Paul > Excerpts from the attached: > > --------------- > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > ... > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in = a > response to the initial INVITE request > > ... > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > ... > > --------------- > > > > Kind regards > > > > Ivo > > > > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, August 05, 2016 6:50 PM > To: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > > > On 8/5/16 11:14 AM, Christer Holmberg wrote: > >> Hi Paul, > >> > >> In INFOs, the info package specification shall indicate WHY a message > >> body is included. That was one of the main reason for doing the info > >> package mechanism. > >> > >> And, as Ivo also indicated, INFOs will be routed according to the > >> established route set. > > > > I didn't think this was about INFO. I agree that in INFO, as long as the > body is properly marked as the package body for the INFO that a > call-info pointing to it isn't needed, and not appropriate. > > > > Thanks, > > Paul > > > >> Regards, > >> > >> Christer > >> > >> Sent from my Windows Phone > >> ---------------------------------------------------------------------- > >> -- > >> From: Paul Kyzivat > >> Sent: =FD05/=FD08/=FD2016 17:43 > >> To: ecrit@ietf.org > >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > >> no value > >> > >> Ivo, > >> > >> IIUC, you are saying that the Call-Info that refers to the body is > >> unnecessary because the recipient will know what to do with the body > >> even in the absence of the Call-Info. Is that right? > >> > >> This assumption mixes up two things: > >> - understanding a body syntactically > >> - understanding *why* the body is present and how it should be used. > >> > >> Historically, processing of body parts in sip was very poorly defined. > >> Initially the only body of interest was SDP, so how one might process > >> other bodies or body parts was not well considered. Eventually this > >> started to be a liability, so RFC5621 was published to clarify it. > >> > >> Processing of body parts is governed by a complex interaction between > >> Content-Type, Content-Disposition, Content-ID. > >> > >> So the call-info header indicates the reason that body is being > >> included. I realize that there is one predominant reason for doing so, > >> but that is not the only possible reason. (E.g., it might be included > >> as context in an intended discussion about problems handling a call in > >> the > >> past.) > >> > >> If all the handling of the call is coded in a special purpose way, > >> solely for the emergency call path, then alternatives may be of no > >> concern. But ideally the call will largely be handled via standard > >> library code that is also used for other call paths and other message > >> processing. So processing body parts in a "standard" way, rather than > >> special casing, is desirable. > >> > >> Thanks, > >> Paul > >> > >> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > >>> Hello, > >>> > >>> > >>> > >>> COMMENT: > >>> > >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >>> \\\\\\\\\ > >>> > >>> Inclusion of Call-Info header field with > >>> purpose=3DemergencyCallData.eCall.MSD or > >>> purpose=3DemergencyCallData.eCall.control in requests and responses > >>> does not seem to bring any value. It seems to only waste radio resource= s. > >>> > >>> > >>> > >>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in > >>> the initial INVITE request: > >>> > >>> - if this is meant to be used by a proxy for routing of the eCall > >>> emergency call to a PSAP supporting eCall emergency call, then this > >>> seems to be redundant to the eCall URN included in the Request-URI > >>> and the Recv-Info header field containing eCall specific info package > >>> (emergencyCallData.eCall.MSD). > >>> > >>> - if this is meant to be used by UAS (i.e. PSAP), then according to > >>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > >>> the bodies of the INVITE request not marked with Content-Disposition: > >>> ...; handling=3Doptional are understood. So, > >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >>> found by UAS during the INVITE request processing. > >>> > >>> > >>> > >>> For Call-Info with purpose=3DemergencyCallData.eCall.control included > >>> in a response to the initial INVITE request > >>> > >>> - no routing decisions are done by proxies when receiving a response > >>> to the initial INVITE request so this does not seem to have any value > >>> for the proxies > >>> > >>> - UAC includes Accept with supported MIME types in INVITE request so > >>> why would UAS send any MIME body not wished by the UAC? > >>> > >>> > >>> > >>> For Call-Info with purpose=3DemergencyCallData.eCall.control included > >>> in the INFO request > >>> > >>> - no routing decisions are done by proxies when receiving an > >>> in-dialog request so this does not seem to have any value for the > >>> proxies > >>> > >>> - support of info package emergencyCallData.eCall.MSD in the call > >>> implies that either application/EmergencyCallData.eCall.control+xml > >>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > >>> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > >>> needs to check that all the bodies of the INFO request not marked > >>> with > >>> Content-Disposition: ...; handling=3Doptional are understood. So, > >>> application/EmergencyCallData.eCall.control+xml MIME body or > >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >>> found by UAS during the INFO request processing. > >>> > >>> ///////////////////////////////////////////////////////////////////// > >>> ///////// > >>> > >>> PROPOSED SOLUTION to COMMENT > >>> > >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > >>> \\\\\\\\\ > >>> > >>> Remove insertion of Call-Info header field. > >>> > >>> ///////////////////////////////////////////////////////////////////// > >>> ///////// > >>> > >>> > >>> > >>> Kind regards > >>> > >>> > >>> > >>> Ivo Sedlacek > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > --_000_7594FB04B1934943A5C02806D1A2204B4BBBF8D8ESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

It is allowed to include Call-Info in INFO - that's not the issue. The ques= tion is WHY we would mandate it.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD08= /=FD08/=FD2016 15:56
To: Ivo Sedlacek; Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value
On 8/8/16 3:43 AM, Ivo Sedlacek wrote:
> Hello Paul,
>
>
>
> the comment explicitly referred to INVITE and to INFO.

OK. My position is that call-info is proper to use in INVITE. It should not be necessary in INFO. Whether it is incorrect to use it in INFO is
arguable either way.

        Thanks,
        Paul

> Excerpts from the attached:
>
> ---------------
>
> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in t= he
> initial INVITE request:
>
> ...
>
> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in a
> response to the initial INVITE request
>
> ...
>
> For Call-Info with purpose=3DemergencyCallData.eCall.control included = in
> the INFO request
>
> ...
>
> ---------------
>
>
>
> Kind regards
>
>
>
> Ivo
>
>
>
>
>
> -----Original Message-----
> From: Ecrit [mailto:ecrit-bo= unces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Friday, August 05, 2016 6:50 PM
> To: Christer Holmberg; ecrit@ietf.org
> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings=
> no value
>
>
>
> On 8/5/16 11:14 AM, Christer Holmberg wrote:
>
>> Hi Paul,
>
>>
>
>> In INFOs, the info package specification shall indicate WHY a mess= age
>
>> body is included. That was one of the main reason for doing the in= fo
>
>> package mechanism.
>
>>
>
>> And, as Ivo also indicated, INFOs will be routed according to the<= br> >
>> established route set.
>
>
>
> I didn't think this was about INFO. I agree that in INFO, as long as t= he
> body is properly marked as the package body for the INFO that a
> call-info pointing to it isn't needed, and not appropriate.
>
>
>
>            = ;     Thanks,
>
>            = ;     Paul
>
>
>
>> Regards,
>
>>
>
>> Christer
>
>>
>
>> Sent from my Windows Phone
>
>> ------------------------------------------------------------------= ----
>
>> --
>
>> From: Paul Kyzivat <ma= ilto:pkyzivat@alum.mit.edu>
>
>> Sent: =FD05/=FD08/=FD2016 17:43
>
>> To: ecrit@ietf.org <mailto:ec= rit@ietf.org> <mailto:ecrit@iet= f.org>
>
>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage br= ings
>
>> no value
>
>>
>
>> Ivo,
>
>>
>
>> IIUC, you are saying that the Call-Info that refers to the body is=
>
>> unnecessary because the recipient will know what to do with the bo= dy
>
>> even in the absence of the Call-Info. Is that right?
>
>>
>
>> This assumption mixes up two things:
>
>> - understanding a body syntactically
>
>> - understanding *why* the body is present and how it should be use= d.
>
>>
>
>> Historically, processing of body parts in sip was very poorly defi= ned.
>
>> Initially the only body of interest was SDP, so how one might proc= ess
>
>> other bodies or body parts was not well considered. Eventually thi= s
>
>> started to be a liability, so RFC5621 was published to clarify it.=
>
>>
>
>> Processing of body parts is governed by a complex interaction betw= een
>
>> Content-Type, Content-Disposition, Content-ID.
>
>>
>
>> So the call-info header indicates the reason that body is being >
>> included. I realize that there is one predominant reason for doing= so,
>
>> but that is not the only possible reason. (E.g., it might be inclu= ded
>
>> as context in an intended discussion about problems handling a cal= l in
>
>> the
>
>> past.)
>
>>
>
>> If all the handling of the call is coded in a special purpose way,=
>
>> solely for the emergency call path, then alternatives may be of no=
>
>> concern. But ideally the call will largely be handled via standard=
>
>> library code that is also used for other call paths and other mess= age
>
>> processing. So processing body parts in a "standard" way= , rather than
>
>> special casing, is desirable.
>
>>
>
>>         Thanks,
>
>>         Paul
>
>>
>
>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote:
>
>>> Hello,
>
>>>
>
>>>
>
>>>
>
>>> COMMENT:
>
>>>
>
>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\
>
>>> \\\\\\\\\
>
>>>
>
>>> Inclusion of Call-Info header field with
>
>>> purpose=3DemergencyCallData.eCall.MSD or
>
>>> purpose=3DemergencyCallData.eCall.control in requests and resp= onses
>
>>> does not seem to bring any value. It seems to only waste radio= resources.
>
>>>
>
>>>
>
>>>
>
>>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD inclu= ded in
>
>>> the initial INVITE request:
>
>>>
>
>>> - if this is meant to be used by a proxy for routing of the eC= all
>
>>> emergency call to a PSAP supporting eCall emergency call, then= this
>
>>> seems to be redundant to the eCall URN included in the Request= -URI
>
>>> and the Recv-Info header field containing eCall specific info = package
>
>>> (emergencyCallData.eCall.MSD).
>
>>>
>
>>> - if this is meant to be used by UAS (i.e. PSAP), then accordi= ng to
>
>>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check th= at all
>
>>> the bodies of the INVITE request not marked with Content-Dispo= sition:
>
>>> ...; handling=3Doptional are understood. So,
>
>>> application/emergencyCallData.eCall.MSD+per MIME body will= anyway be
>
>>> found by UAS during the INVITE request processing.
>
>>>
>
>>>
>
>>>
>
>>> For Call-Info with purpose=3DemergencyCallData.eCall.control i= ncluded
>
>>> in a response to the initial INVITE request
>
>>>
>
>>> - no routing decisions are done by proxies when receiving a re= sponse
>
>>> to the initial INVITE request so this does not seem to have an= y value
>
>>> for the proxies
>
>>>
>
>>> - UAC includes Accept with supported MIME types in INVITE requ= est so
>
>>> why would UAS send any MIME body not wished by the UAC?
>
>>>
>
>>>
>
>>>
>
>>> For Call-Info with purpose=3DemergencyCallData.eCall.control i= ncluded
>
>>> in the INFO request
>
>>>
>
>>> - no routing decisions are done by proxies when receiving an >
>>> in-dialog request so this does not seem to have any value for = the
>
>>> proxies
>
>>>
>
>>> - support of info package emergencyCallData.eCall.MSD in the c= all
>
>>> implies that either application/EmergencyCallData.eCall.contro= l+xml
>
>>> MIME body or application/emergencyCallData.eCall.MSD+per M= IME body is
>
>>> included. Again, according to RFC3261 subclause 8.2.3, the UAS= anyway
>
>>> needs to check that all the bodies of the INFO request not mar= ked
>
>>> with
>
>>> Content-Disposition: ...; handling=3Doptional are understood. = So,
>
>>> application/EmergencyCallData.eCall.control+xml MIME body = or
>
>>> application/emergencyCallData.eCall.MSD+per MIME body will= anyway be
>
>>> found by UAS during the INFO request processing.
>
>>>
>
>>> //////////////////////////////////////////////////////////////= ///////
>
>>> /////////
>
>>>
>
>>> PROPOSED SOLUTION to COMMENT
>
>>>
>
>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\
>
>>> \\\\\\\\\
>
>>>
>
>>> Remove insertion of Call-Info header field.
>
>>>
>
>>> //////////////////////////////////////////////////////////////= ///////
>
>>> /////////
>
>>>
>
>>>
>
>>>
>
>>> Kind regards
>
>>>
>
>>>
>
>>>
>
>>> Ivo Sedlacek
>
>>>
>
>>>
>
>>>
>
>>> _______________________________________________
>
>>> Ecrit mailing list
>
>>> Ecrit@ietf.org <mailto:Ec= rit@ietf.org>
>
>>> https:= //www.ietf.org/mailman/listinfo/ecrit
>
>>>
>
>>
>
>> _______________________________________________
>
>> Ecrit mailing list
>
>> Ecrit@ietf.org <mailto:Ecrit@= ietf.org>
>
>> https://ww= w.ietf.org/mailman/listinfo/ecrit
>
>
>
> _______________________________________________
>
> Ecrit mailing list
>
> Ecrit@ietf.org <mailto:Ecrit@ietf= .org>
>
> https://www.ie= tf.org/mailman/listinfo/ecrit
>

 --_000_7594FB04B1934943A5C02806D1A2204B4BBBF8D8ESESSMB208erics_-- From nobody Mon Aug 8 07:10: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 29CDE12B02E for ; Mon, 8 Aug 2016 07:10:22 -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 hEyhQuKHpB8Z for ; Mon, 8 Aug 2016 07:10:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C3751126D74 for ; Mon, 8 Aug 2016 07:10:19 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-f5-57a892c88234 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 34.46.02553.8C298A75; Mon, 8 Aug 2016 16:10:17 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 16:10:16 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek , "R.Jesske@telekom.de" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAC6D8A== Date: Mon, 8 Aug 2016 14:10:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBC1A7F@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7n+7JSSvCDbo+2lg0LnrKarFiwwFW i6Y7XWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6Mhj+HmQr2JlSceDeHuYGx waeLkZNDQsBE4vWNPUxdjFwcQgLrGSW2tLQwQjiLGSVWfFnL2sXIwcEmYCHR/U8bJC4isIxR 4vyV+4wg3cICCxklHi6PAbFFBBYxSixeLgdhO0mcPNHCDGKzCKhI7Fr1BayeV8BX4uLT8ywQ C/qYJO6272MFSXAKOEhsfTYFrIhRQEzi+6k1TCA2s4C4xK0n85kgThWQWLLnPDOELSrx8vE/ VghbSWLF9kuMEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZ xShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYJQe3/DbYwfjyueMhRgEORiUeXoXy5eFCrIll xZW5hxglOJiVRHhr+leEC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBa BJNl4uCUamD0XtTyd/XEbVKdS8vv+1nc25g1TXjuvz+SbMeXXsjOu+hVt/z5vMJjBgdOp0+W 3PhOQ//74ZqVGp7bljSe/eaZ53tuz/VDZ00KJBtlbsVcf8iV4OY6r+yFZt+0jtgOO2NRXZuf G0ycNQoE1S+kbxPpz7+spHFvQ2MR98fWs5/6fe0erFa55SOkxFKckWioxVxUnAgAYAGiRI4C AAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 14:10:22 -0000 Hi, > In this case, IIUC, there *could* be a call-info header pointing to the e= call info in an external server. The data being in a body part is simply a = special case of that. > > So it makes sense to me that the starting point for discovering ecall dat= a be with the call-info header.=20 In theory you could put ANY information associated with the call - includin= g SDP - on an external server. Does that mean we should always include call= -info for every call, as a starting point to discover the information??? *IF* someone defines the procedures associated with retrieving data from an= external server, he/she needs to define the procedures associated with tha= t. Currently no such cases exist for ecall. Regards, Christer > *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > *Sent:* Monday, August 08, 2016 11:45 AM > *To:* Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org > *Subject:* AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > > > Hi Ivo, > > using the ecall urn (urn:service:sos.ecall.automatic) does not=20 > implicitly means using the MSD within the Body. It could be also an=20 > interworked call where all ecall information is included inband using=20 > the In-band modem solution. > > > > We have to think also on backwards compatibility issues. Thus when=20 > moving PSAP's to SIP imply also that there must exist an interworking=20 > between the old mobile world towards the new mobile world using SIP. > > > > Using the Call-Info header would help the PAST to distinguish the=20 > in-band and outband solution. Perhaps it would be worth to define an=20 > additional value for inband data, to identify ecalls coming from other=20 > networks not supporting the MSD Body. > > > > Best Regards > > > Roland. > > > > > > *Von:*Ecrit [mailto:ecrit-bounces@ietf.org] *Im Auftrag von *Ivo=20 > Sedlacek > *Gesendet:* Montag, 8. August 2016 09:59 > *An:* Paul Kyzivat; ecrit@ietf.org > *Betreff:* [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > > > Hello, > > > > According to RFC3261, the Call-Info header field provides additional=20 > information about the caller or callee. > > > > According to draft-ietf-ecrit-ecall-11, the Call-Info header field is=20 > used to form a "content-table" of pointers to bodies INVITE request=20 > (and of INVITE response, of INFO request) in headers of INVITE request=20 > (and of INVITE response, of INFO request). > > > > If the Call-Info header field points to a body which describes the=20 > callers or callee, then Call-Info semantic fits (even though I would=20 > still question usefulness of such Call-Info inclusion). > > > > If the Call-Info header field points to a body which request an action=20 > in remote UE and which reports to remote UE an outcome of an action=20 > done by the local UE, then Call-Info semantic does not fit. > > > > Particularly: > > ---------------------------------------------------------------------- > -------- > > A PSAP or IVS transmits a metadata/control object (see Section 9)=20 > by > > encoding it per the description in this document and attaching it=20 > to > > a SIP message as a MIME body part per [RFC7852]. The body part is > > identified by its MIME content-type ('application/ > > emergencyCallData.eCall.control+xml') in the Content-Type header > > field of the body part. The body part is assigned a unique > > identifier which is listed in a Content-ID header field in the body > > part. The SIP message is marked as containing the metadata/control > > object by adding (or appending to) a Call-Info header field at the > > top level of the SIP message. This Call-Info header field contains=20 > a > > CID URL referencing the body part's unique identifier, and a > > 'purpose' parameter identifying the data as an eCall=20 > metadata/control > > block per the Emergency Call Additional Data Blocks registry entry; > > the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. > > ---------------------------------------------------------------------- > -------- > > and > > ---------------------------------------------------------------------- > -------- > > SIP/2.0 200 OK > > To: ;tag=3D9fxced76sl > > From: Exemplar PSAP > > Call-ID: 3848276298220188511@atlanta.example.com > > > Call-Info: cid:2345678901@atlanta.example.com; > > purpose=3DemergencyCallData.eCall.control; > > Accept: application/sdp, application/pidf+xml, > > application/emergencyCallData.eCall.control+xml, > > application/emergencyCallData.eCall.MSD+per > > CSeq: 31862 INVITE > > Recv-Info: emergencyCallData.eCall.MSD > > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > > SUBSCRIBE, NOTIFY, UPDATE > > Content-Type: multipart/mixed; boundary=3DboundaryX > > Content-Length: ... > > > > --boundaryX > > Content-Type: application/sdp > > > > ...Session Description Protocol (SDP) goes here... > > > > --boundaryX > > Content-Type: application/EmergencyCallData.eCall.control+xml > > Content-ID: 2345678901@atlanta.example.com=20 > > > Content-Disposition: by-reference;handling=3Doptional > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control= " > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation=3D > > =20 > "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> > > > > "/> > > > > > > > > --boundaryX-- > > ---------------------------------------------------------------------- > -------- > > > > Kind regards > > > > Ivo > > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, August 05, 2016 4:43 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings=20 > no value > > > > Ivo, > > > > IIUC, you are saying that the Call-Info that refers to the body is=20 > unnecessary because the recipient will know what to do with the body=20 > even in the absence of the Call-Info. Is that right? > > > > This assumption mixes up two things: > > - understanding a body syntactically > > - understanding *why* the body is present and how it should be used. > > > > Historically, processing of body parts in sip was very poorly defined. > > Initially the only body of interest was SDP, so how one might process=20 > other bodies or body parts was not well considered. Eventually this=20 > started to be a liability, so RFC5621 was published to clarify it. > > > > Processing of body parts is governed by a complex interaction between=20 > Content-Type, Content-Disposition, Content-ID. > > > > So the call-info header indicates the reason that body is being=20 > included. I realize that there is one predominant reason for doing so,=20 > but that is not the only possible reason. (E.g., it might be included=20 > as context in an intended discussion about problems handling a call in=20 > the > > past.) > > > > If all the handling of the call is coded in a special purpose way,=20 > solely for the emergency call path, then alternatives may be of no=20 > concern. But ideally the call will largely be handled via standard=20 > library code that is also used for other call paths and other message=20 > processing. So processing body parts in a "standard" way, rather than=20 > special casing, is desirable. > > > > Thanks, > > Paul > > > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > >> Hello, > >> > >> > >> > >> COMMENT: > >> > >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> \ > >> \\\\\\\\ > >> > >> Inclusion of Call-Info header field with > >> purpose=3DemergencyCallData.eCall.MSD or > >> purpose=3DemergencyCallData.eCall.control in requests and responses=20 >> does > >> not seem to bring any value. It seems to only waste radio resources. > >> > >> > >> > >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in=20 >> the > >> initial INVITE request: > >> > >> - if this is meant to be used by a proxy for routing of the eCall > >> emergency call to a PSAP supporting eCall emergency call, then this > >> seems to be redundant to the eCall URN included in the Request-URI=20 >> and > >> the Recv-Info header field containing eCall specific info package > >> (emergencyCallData.eCall.MSD). > >> > >> - if this is meant to be used by UAS (i.e. PSAP), then according to > >> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > >> the bodies of the INVITE request not marked with Content-Disposition: > >> ...; handling=3Doptional are understood. So, > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >> found by UAS during the INVITE request processing. > >> > >> > >> > >> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >> in > >> a response to the initial INVITE request > >> > >> - no routing decisions are done by proxies when receiving a response > >> to the initial INVITE request so this does not seem to have any value > >> for the proxies > >> > >> - UAC includes Accept with supported MIME types in INVITE request so > >> why would UAS send any MIME body not wished by the UAC? > >> > >> > >> > >> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >> in > >> the INFO request > >> > >> - no routing decisions are done by proxies when receiving an=20 >> in-dialog > >> request so this does not seem to have any value for the proxies > >> > >> - support of info package emergencyCallData.eCall.MSD in the call > >> implies that either application/EmergencyCallData.eCall.control+xml > >> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > >> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > >> needs to check that all the bodies of the INFO request not marked=20 >> with > >> Content-Disposition: ...; handling=3Doptional are understood. So, > >> application/EmergencyCallData.eCall.control+xml MIME body or > >> application/emergencyCallData.eCall.MSD+per MIME body will anyway be > >> found by UAS during the INFO request processing. > >> > >> ///////////////////////////////////////////////////////////////////// >> / > >> //////// > >> > >> PROPOSED SOLUTION to COMMENT > >> > >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> \ > >> \\\\\\\\ > >> > >> Remove insertion of Call-Info header field. > >> > >> ///////////////////////////////////////////////////////////////////// >> / > >> //////// > >> > >> > >> > >> Kind regards > >> > >> > >> > >> Ivo Sedlacek > >> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 8 07:16:26 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 0B90412D0CB for ; Mon, 8 Aug 2016 07:16:25 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 d5pTRoUufBsM for ; Mon, 8 Aug 2016 07:16:22 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 BC9CB128E18 for ; Mon, 8 Aug 2016 07:16:22 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-04v.sys.comcast.net with SMTP id WlHhbmvVv8PeaWlLpbQKsY; Mon, 08 Aug 2016 14:16:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id WlLpbqvoWHaWLWlLpbb2nw; Mon, 08 Aug 2016 14:16:21 +0000 To: Christer Holmberg , Ivo Sedlacek , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se> <66f70516-ed5f-1e9d-ee7b-0b8bb16a6bc7@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBBF8D8@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 8 Aug 2016 10:16:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBBF8D8@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEq9eg2PP5HOKXVQTgrQt5p740myCjq1xdnjumTsYhgIq0EuKnUPDh+XzEouaB4CdkmefPrwOlKkSzOBattgTgwGCJ8vyg+ebyCgdsaVbnB+RHmnEjC4 uQdDRws4PiotHOhkpDM7Scou43RHVJUc8F0TWlybdVH7WuXoCr0M25NF+0dxbz0JA8ENZmQc2uBFX35TiBG0tObprJ7rWCfuGV7b4wwfnkMLz5sld4NETa90 w9vH8zQL3oL6sObSX2+T41eBc4PSRY/e/rQ57/2NE8s= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 08 Aug 2016 14:16:25 -0000 On 8/8/16 9:34 AM, Christer Holmberg wrote: > Hi, > > It is allowed to include Call-Info in INFO - that's not the issue. The > question is WHY we would mandate it. I wasn't concerned with the general issue of call-info in INFO. (I can see how that might be meaningful in some cases, entirely unconnected to what is contained in the info body.) What I'm questioning is including a call-info that references the package body in the INFO. In the current case that is at least redundant, since the definition of the INFO package should cover the semantics of how to process it. Whether it is *wrong* to use such redundancy may be arguable. I'm inclined to recommend against it, but I have no strong arguments to make in that regard. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý08/ý08/ý2016 15:56 > To: Ivo Sedlacek ; Christer Holmberg > ; ecrit@ietf.org > > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings > no value > > On 8/8/16 3:43 AM, Ivo Sedlacek wrote: >> Hello Paul, >> >> >> >> the comment explicitly referred to INVITE and to INFO. > > OK. My position is that call-info is proper to use in INVITE. It should > not be necessary in INFO. Whether it is incorrect to use it in INFO is > arguable either way. > > Thanks, > Paul > >> Excerpts from the attached: >> >> --------------- >> >> For Call-Info with purpose=emergencyCallData.eCall.MSD included in the >> initial INVITE request: >> >> ... >> >> For Call-Info with purpose=emergencyCallData.eCall.control included in a >> response to the initial INVITE request >> >> ... >> >> For Call-Info with purpose=emergencyCallData.eCall.control included in >> the INFO request >> >> ... >> >> --------------- >> >> >> >> Kind regards >> >> >> >> Ivo >> >> >> >> >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, August 05, 2016 6:50 PM >> To: Christer Holmberg; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings >> no value >> >> >> >> On 8/5/16 11:14 AM, Christer Holmberg wrote: >> >>> Hi Paul, >> >>> >> >>> In INFOs, the info package specification shall indicate WHY a message >> >>> body is included. That was one of the main reason for doing the info >> >>> package mechanism. >> >>> >> >>> And, as Ivo also indicated, INFOs will be routed according to the >> >>> established route set. >> >> >> >> I didn't think this was about INFO. I agree that in INFO, as long as the >> body is properly marked as the package body for the INFO that a >> call-info pointing to it isn't needed, and not appropriate. >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Regards, >> >>> >> >>> Christer >> >>> >> >>> Sent from my Windows Phone >> >>> ---------------------------------------------------------------------- >> >>> -- >> >>> From: Paul Kyzivat >> >>> Sent: ý05/ý08/ý2016 17:43 >> >>> To: ecrit@ietf.org >> >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings >> >>> no value >> >>> >> >>> Ivo, >> >>> >> >>> IIUC, you are saying that the Call-Info that refers to the body is >> >>> unnecessary because the recipient will know what to do with the body >> >>> even in the absence of the Call-Info. Is that right? >> >>> >> >>> This assumption mixes up two things: >> >>> - understanding a body syntactically >> >>> - understanding *why* the body is present and how it should be used. >> >>> >> >>> Historically, processing of body parts in sip was very poorly defined. >> >>> Initially the only body of interest was SDP, so how one might process >> >>> other bodies or body parts was not well considered. Eventually this >> >>> started to be a liability, so RFC5621 was published to clarify it. >> >>> >> >>> Processing of body parts is governed by a complex interaction between >> >>> Content-Type, Content-Disposition, Content-ID. >> >>> >> >>> So the call-info header indicates the reason that body is being >> >>> included. I realize that there is one predominant reason for doing so, >> >>> but that is not the only possible reason. (E.g., it might be included >> >>> as context in an intended discussion about problems handling a call in >> >>> the >> >>> past.) >> >>> >> >>> If all the handling of the call is coded in a special purpose way, >> >>> solely for the emergency call path, then alternatives may be of no >> >>> concern. But ideally the call will largely be handled via standard >> >>> library code that is also used for other call paths and other message >> >>> processing. So processing body parts in a "standard" way, rather than >> >>> special casing, is desirable. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> >>>> Hello, >> >>>> >> >>>> >> >>>> >> >>>> COMMENT: >> >>>> >> >>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> >>>> \\\\\\\\\ >> >>>> >> >>>> Inclusion of Call-Info header field with >> >>>> purpose=emergencyCallData.eCall.MSD or >> >>>> purpose=emergencyCallData.eCall.control in requests and responses >> >>>> does not seem to bring any value. It seems to only waste radio resources. >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=emergencyCallData.eCall.MSD included in >> >>>> the initial INVITE request: >> >>>> >> >>>> - if this is meant to be used by a proxy for routing of the eCall >> >>>> emergency call to a PSAP supporting eCall emergency call, then this >> >>>> seems to be redundant to the eCall URN included in the Request-URI >> >>>> and the Recv-Info header field containing eCall specific info package >> >>>> (emergencyCallData.eCall.MSD). >> >>>> >> >>>> - if this is meant to be used by UAS (i.e. PSAP), then according to >> >>>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >> >>>> the bodies of the INVITE request not marked with Content-Disposition: >> >>>> ...; handling=optional are understood. So, >> >>>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>>> found by UAS during the INVITE request processing. >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=emergencyCallData.eCall.control included >> >>>> in a response to the initial INVITE request >> >>>> >> >>>> - no routing decisions are done by proxies when receiving a response >> >>>> to the initial INVITE request so this does not seem to have any value >> >>>> for the proxies >> >>>> >> >>>> - UAC includes Accept with supported MIME types in INVITE request so >> >>>> why would UAS send any MIME body not wished by the UAC? >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=emergencyCallData.eCall.control included >> >>>> in the INFO request >> >>>> >> >>>> - no routing decisions are done by proxies when receiving an >> >>>> in-dialog request so this does not seem to have any value for the >> >>>> proxies >> >>>> >> >>>> - support of info package emergencyCallData.eCall.MSD in the call >> >>>> implies that either application/EmergencyCallData.eCall.control+xml >> >>>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is >> >>>> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> >>>> needs to check that all the bodies of the INFO request not marked >> >>>> with >> >>>> Content-Disposition: ...; handling=optional are understood. So, >> >>>> application/EmergencyCallData.eCall.control+xml MIME body or >> >>>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>>> found by UAS during the INFO request processing. >> >>>> >> >>>> ///////////////////////////////////////////////////////////////////// >> >>>> ///////// >> >>>> >> >>>> PROPOSED SOLUTION to COMMENT >> >>>> >> >>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> >>>> \\\\\\\\\ >> >>>> >> >>>> Remove insertion of Call-Info header field. >> >>>> >> >>>> ///////////////////////////////////////////////////////////////////// >> >>>> ///////// >> >>>> >> >>>> >> >>>> >> >>>> Kind regards >> >>>> >> >>>> >> >>>> >> >>>> Ivo Sedlacek >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ecrit mailing list >> >>>> Ecrit@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > From nobody Mon Aug 8 07:25: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 420C412B038 for ; Mon, 8 Aug 2016 07:25:46 -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 W7WcFfpBxYOA for ; Mon, 8 Aug 2016 07:25:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B340E128E18 for ; Mon, 8 Aug 2016 07:25:43 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-d0-57a89665260e Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id D1.9E.02493.56698A75; Mon, 8 Aug 2016 16:25:42 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 16:25:38 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value Thread-Index: AQHR8XRG8cqfwC1TM0Oikpf6Wf0+iqA/ECeP///qRwCAACK0IA== Date: Mon, 8 Aug 2016 14:25:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBC1BB8@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BDF85@ESESSMB301.ericsson.se> <9b83df29-73c8-fc5c-9882-8c409ddec77c@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBA6C3D@ESESSMB208.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164BF63F@ESESSMB301.ericsson.se> <66f70516-ed5f-1e9d-ee7b-0b8bb16a6bc7@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BBBF8D8@ESESSMB208.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.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7k27atBXhBjs2M1s0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj17ElbAU7gipa9s9kbGC86djFyMkhIWAi 0bCskQnEFhJYzyjx5khdFyMXkL2YUaJn8RrmLkYODjYBC4nuf9ogNSIC5RJrZsxkB7GFBQIl 1p1bwwgRD5L4+XA9lO0kce9DDxuIzSKgItF45RwziM0r4CuxcMsSRoj5H5klOnd/BpvPKeAg sfp6JkgNo4CYxPdTa8DuYRYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0ms2H6JEaLeQOLc 9o3sELa2xLKFr6H2CkqcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPRSizKT i4vz8/TyUks2MQKj4eCW31Y7GA8+dzzEKMDBqMTDq1C+PFyINbGsuDL3EKMEB7OSCG9N/4pw Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYxVvhHdhcvW pR0T4TvS8Xjhl03zE5L3GS+dUTVLOUsi7JoJhxTb/iPPt3y56Zb89p03r9yDbdeWPd97NeaV emnc/oQT7WZq68Iveul/P6Fob/uZOyKkuzztqbrEbN/AD+46SncvufGetZgyW3KiRcXiyfP+ /wrZVHC7rWSH+IM9259PqS+6m35diaU4I9FQi7moOBEACDnV94ICAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value 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, 08 Aug 2016 14:25:46 -0000 Hi, If you are doing the same thing, using two different mechanisms, at the sam= e time, you may end up in situations where the information is not matching,= i.e. the call-info information is not aligned with the Info Package. Which= takes precedence? Or, what if the Call-Info headers, or parts of the mandated information, is= missing? Should the receiver reject the INFO, or the content within, even = if it doesn't have to? Etc etc etc. The less doors we open for ambiguity, misalignments and errors, the better.= ..=20 Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 08 August 2016 17:16 To: Christer Holmberg ; Ivo Sedlacek ; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue On 8/8/16 9:34 AM, Christer Holmberg wrote: > Hi, > > It is allowed to include Call-Info in INFO - that's not the issue. The=20 > question is WHY we would mandate it. I wasn't concerned with the general issue of call-info in INFO. (I can see = how that might be meaningful in some cases, entirely unconnected to what is= contained in the info body.) What I'm questioning is including a call-info that references the package b= ody in the INFO. In the current case that is at least redundant, since the = definition of the INFO package should cover the semantics of how to process= it. Whether it is *wrong* to use such redundancy may be arguable. I'm incl= ined to recommend against it, but I have no strong arguments to make in tha= t regard. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ---------------------------------------------------------------------- > -- > From: Paul Kyzivat > Sent: =FD08/=FD08/=FD2016 15:56 > To: Ivo Sedlacek ; Christer Holmberg=20 > ; ecrit@ietf.org=20 > > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings=20 > no value > > On 8/8/16 3:43 AM, Ivo Sedlacek wrote: >> Hello Paul, >> >> >> >> the comment explicitly referred to INVITE and to INFO. > > OK. My position is that call-info is proper to use in INVITE. It=20 > should not be necessary in INFO. Whether it is incorrect to use it in=20 > INFO is arguable either way. > > Thanks, > Paul > >> Excerpts from the attached: >> >> --------------- >> >> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in=20 >> the initial INVITE request: >> >> ... >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >> in a response to the initial INVITE request >> >> ... >> >> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >> in the INFO request >> >> ... >> >> --------------- >> >> >> >> Kind regards >> >> >> >> Ivo >> >> >> >> >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, August 05, 2016 6:50 PM >> To: Christer Holmberg; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >> brings no value >> >> >> >> On 8/5/16 11:14 AM, Christer Holmberg wrote: >> >>> Hi Paul, >> >>> >> >>> In INFOs, the info package specification shall indicate WHY a=20 >>> message >> >>> body is included. That was one of the main reason for doing the info >> >>> package mechanism. >> >>> >> >>> And, as Ivo also indicated, INFOs will be routed according to the >> >>> established route set. >> >> >> >> I didn't think this was about INFO. I agree that in INFO, as long as=20 >> the body is properly marked as the package body for the INFO that a=20 >> call-info pointing to it isn't needed, and not appropriate. >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Regards, >> >>> >> >>> Christer >> >>> >> >>> Sent from my Windows Phone >> >>> -------------------------------------------------------------------- >>> -- >> >>> -- >> >>> From: Paul Kyzivat >> >>> Sent: =FD05/=FD08/=FD2016 17:43 >> >>> To: ecrit@ietf.org >> >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>> brings >> >>> no value >> >>> >> >>> Ivo, >> >>> >> >>> IIUC, you are saying that the Call-Info that refers to the body is >> >>> unnecessary because the recipient will know what to do with the body >> >>> even in the absence of the Call-Info. Is that right? >> >>> >> >>> This assumption mixes up two things: >> >>> - understanding a body syntactically >> >>> - understanding *why* the body is present and how it should be used. >> >>> >> >>> Historically, processing of body parts in sip was very poorly defined. >> >>> Initially the only body of interest was SDP, so how one might=20 >>> process >> >>> other bodies or body parts was not well considered. Eventually this >> >>> started to be a liability, so RFC5621 was published to clarify it. >> >>> >> >>> Processing of body parts is governed by a complex interaction=20 >>> between >> >>> Content-Type, Content-Disposition, Content-ID. >> >>> >> >>> So the call-info header indicates the reason that body is being >> >>> included. I realize that there is one predominant reason for doing=20 >>> so, >> >>> but that is not the only possible reason. (E.g., it might be=20 >>> included >> >>> as context in an intended discussion about problems handling a call=20 >>> in >> >>> the >> >>> past.) >> >>> >> >>> If all the handling of the call is coded in a special purpose way, >> >>> solely for the emergency call path, then alternatives may be of no >> >>> concern. But ideally the call will largely be handled via standard >> >>> library code that is also used for other call paths and other=20 >>> message >> >>> processing. So processing body parts in a "standard" way, rather=20 >>> than >> >>> special casing, is desirable. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> >>>> Hello, >> >>>> >> >>>> >> >>>> >> >>>> COMMENT: >> >>>> >> >>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> \\ >> >>>> \\\\\\\\\ >> >>>> >> >>>> Inclusion of Call-Info header field with >> >>>> purpose=3DemergencyCallData.eCall.MSD or >> >>>> purpose=3DemergencyCallData.eCall.control in requests and responses >> >>>> does not seem to bring any value. It seems to only waste radio resourc= es. >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in >> >>>> the initial INVITE request: >> >>>> >> >>>> - if this is meant to be used by a proxy for routing of the eCall >> >>>> emergency call to a PSAP supporting eCall emergency call, then this >> >>>> seems to be redundant to the eCall URN included in the Request-URI >> >>>> and the Recv-Info header field containing eCall specific info=20 >>>> package >> >>>> (emergencyCallData.eCall.MSD). >> >>>> >> >>>> - if this is meant to be used by UAS (i.e. PSAP), then according to >> >>>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that=20 >>>> all >> >>>> the bodies of the INVITE request not marked with Content-Disposition: >> >>>> ...; handling=3Doptional are understood. So, >> >>>> application/emergencyCallData.eCall.MSD+per MIME body will anyway=20 >>>> be >> >>>> found by UAS during the INVITE request processing. >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=3DemergencyCallData.eCall.control included >> >>>> in a response to the initial INVITE request >> >>>> >> >>>> - no routing decisions are done by proxies when receiving a=20 >>>> response >> >>>> to the initial INVITE request so this does not seem to have any=20 >>>> value >> >>>> for the proxies >> >>>> >> >>>> - UAC includes Accept with supported MIME types in INVITE request=20 >>>> so >> >>>> why would UAS send any MIME body not wished by the UAC? >> >>>> >> >>>> >> >>>> >> >>>> For Call-Info with purpose=3DemergencyCallData.eCall.control included >> >>>> in the INFO request >> >>>> >> >>>> - no routing decisions are done by proxies when receiving an >> >>>> in-dialog request so this does not seem to have any value for the >> >>>> proxies >> >>>> >> >>>> - support of info package emergencyCallData.eCall.MSD in the call >> >>>> implies that either application/EmergencyCallData.eCall.control+xml >> >>>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body=20 >>>> is >> >>>> included. Again, according to RFC3261 subclause 8.2.3, the UAS=20 >>>> anyway >> >>>> needs to check that all the bodies of the INFO request not marked >> >>>> with >> >>>> Content-Disposition: ...; handling=3Doptional are understood. So, >> >>>> application/EmergencyCallData.eCall.control+xml MIME body or >> >>>> application/emergencyCallData.eCall.MSD+per MIME body will anyway=20 >>>> be >> >>>> found by UAS during the INFO request processing. >> >>>> >> >>>> /////////////////////////////////////////////////////////////////// >>>> // >> >>>> ///////// >> >>>> >> >>>> PROPOSED SOLUTION to COMMENT >> >>>> >> >>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> \\ >> >>>> \\\\\\\\\ >> >>>> >> >>>> Remove insertion of Call-Info header field. >> >>>> >> >>>> /////////////////////////////////////////////////////////////////// >>>> // >> >>>> ///////// >> >>>> >> >>>> >> >>>> >> >>>> Kind regards >> >>>> >> >>>> >> >>>> >> >>>> Ivo Sedlacek >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ecrit mailing list >> >>>> Ecrit@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > From nobody Mon Aug 8 07:39: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 A455F12D835 for ; Mon, 8 Aug 2016 07:39:33 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 PEqqM81b_YO6 for ; Mon, 8 Aug 2016 07:39:31 -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 A397F12D605 for ; Mon, 8 Aug 2016 07:39:31 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-10v.sys.comcast.net with SMTP id Wlg1bN2BNRingWliEbYmav; Mon, 08 Aug 2016 14:39:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id WliEbzjUDOEhWWliEb8rGo; Mon, 08 Aug 2016 14:39:30 +0000 To: Christer Holmberg , Ivo Sedlacek , "R.Jesske@telekom.de" , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BBC1A7F@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: <013a7445-0cb7-5ba3-5cfc-ad29db62d034@alum.mit.edu> Date: Mon, 8 Aug 2016 10:39:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBC1A7F@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMI+fFC8pK+QfrOfxfGPMLNm7KHS5bNLtbjU1GLQemU7yDO8/+qhesvGkLV5+r6xgawajp7etMuNNHEeuogh+4d/JhK4c4r3xnZGa5VJ2NuQc9w5DZsm 2UWi9qILgZTcbpi+32npdv81QScbDpEShOP0ztEbvLfaZ7rg9nTgNq11lPHhCd3AC1J0SB15ixv8kEiGyRtkmoA2ipbz4bZNMfwkGG+/rHgaOuiA1anAJNPm 9vyXK4tT4YllfpfMS67gnZJrtqNmCCDKOJv3CFxRjITjYG1i74lfFF5n1hw/PGGaNGPJ043WvVmjoBzkelbjNQ== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 14:39:33 -0000 On 8/8/16 10:10 AM, Christer Holmberg wrote: > Hi, > >> In this case, IIUC, there *could* be a call-info header pointing to the ecall info in an external server. The data being in a body part is simply a special case of that. >> >> So it makes sense to me that the starting point for discovering ecall data be with the call-info header. > > In theory you could put ANY information associated with the call - including SDP - on an external server. Does that mean we should always include call-info for every call, as a starting point to discover the information??? You go too far mentioning SDP. The mechanism for O/A is explicitly limited to use of a body - there is no provision for dereferencing a URL to obtain the SDP. But I will take your point. I haven't been paying close enough attention to the details of the draft. I see that it is effectively specifying that when the call-info has purpose="emergencyCallData.eCall.MSD" then it MUST have a CID URL. But still, how is the processing of the body specified. I see the following used: Content-Disposition: by-reference;handling=optional This specifically says that the disposition of the body is determined by a *reference* to the body. If the call-info isn't used there won't be any reference. If you want to remove the call-info, then you need to define a new c-d type that specifies how the body part is to be processed. The content-type isn't sufficient by itself, since there could be a variety of ways it can be disposed of. E.g., it could be rendered, or logged. "Render" is the default, but "render" has no clear meaning in SIP - it was really intended for email. Thanks, Paul > *IF* someone defines the procedures associated with retrieving data from an external server, he/she needs to define the procedures associated with that. Currently no such cases exist for ecall. > > Regards, > > Christer > > > >> *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] >> *Sent:* Monday, August 08, 2016 11:45 AM >> *To:* Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org >> *Subject:* AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> >> >> Hi Ivo, >> >> using the ecall urn (urn:service:sos.ecall.automatic) does not >> implicitly means using the MSD within the Body. It could be also an >> interworked call where all ecall information is included inband using >> the In-band modem solution. >> >> >> >> We have to think also on backwards compatibility issues. Thus when >> moving PSAP's to SIP imply also that there must exist an interworking >> between the old mobile world towards the new mobile world using SIP. >> >> >> >> Using the Call-Info header would help the PAST to distinguish the >> in-band and outband solution. Perhaps it would be worth to define an >> additional value for inband data, to identify ecalls coming from other >> networks not supporting the MSD Body. >> >> >> >> Best Regards >> >> >> Roland. >> >> >> >> >> >> *Von:*Ecrit [mailto:ecrit-bounces@ietf.org] *Im Auftrag von *Ivo >> Sedlacek >> *Gesendet:* Montag, 8. August 2016 09:59 >> *An:* Paul Kyzivat; ecrit@ietf.org >> *Betreff:* [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> >> >> Hello, >> >> >> >> According to RFC3261, the Call-Info header field provides additional >> information about the caller or callee. >> >> >> >> According to draft-ietf-ecrit-ecall-11, the Call-Info header field is >> used to form a "content-table" of pointers to bodies INVITE request >> (and of INVITE response, of INFO request) in headers of INVITE request >> (and of INVITE response, of INFO request). >> >> >> >> If the Call-Info header field points to a body which describes the >> callers or callee, then Call-Info semantic fits (even though I would >> still question usefulness of such Call-Info inclusion). >> >> >> >> If the Call-Info header field points to a body which request an action >> in remote UE and which reports to remote UE an outcome of an action >> done by the local UE, then Call-Info semantic does not fit. >> >> >> >> Particularly: >> >> ---------------------------------------------------------------------- >> -------- >> >> A PSAP or IVS transmits a metadata/control object (see Section 9) >> by >> >> encoding it per the description in this document and attaching it >> to >> >> a SIP message as a MIME body part per [RFC7852]. The body part is >> >> identified by its MIME content-type ('application/ >> >> emergencyCallData.eCall.control+xml') in the Content-Type header >> >> field of the body part. The body part is assigned a unique >> >> identifier which is listed in a Content-ID header field in the body >> >> part. The SIP message is marked as containing the metadata/control >> >> object by adding (or appending to) a Call-Info header field at the >> >> top level of the SIP message. This Call-Info header field contains >> a >> >> CID URL referencing the body part's unique identifier, and a >> >> 'purpose' parameter identifying the data as an eCall >> metadata/control >> >> block per the Emergency Call Additional Data Blocks registry entry; >> >> the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. >> >> ---------------------------------------------------------------------- >> -------- >> >> and >> >> ---------------------------------------------------------------------- >> -------- >> >> SIP/2.0 200 OK >> >> To: ;tag=9fxced76sl >> >> From: Exemplar PSAP >> >> Call-ID: 3848276298220188511@atlanta.example.com >> >> >> Call-Info: cid:2345678901@atlanta.example.com; >> >> purpose=emergencyCallData.eCall.control; >> >> Accept: application/sdp, application/pidf+xml, >> >> application/emergencyCallData.eCall.control+xml, >> >> application/emergencyCallData.eCall.MSD+per >> >> CSeq: 31862 INVITE >> >> Recv-Info: emergencyCallData.eCall.MSD >> >> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >> >> SUBSCRIBE, NOTIFY, UPDATE >> >> Content-Type: multipart/mixed; boundary=boundaryX >> >> Content-Length: ... >> >> >> >> --boundaryX >> >> Content-Type: application/sdp >> >> >> >> ...Session Description Protocol (SDP) goes here... >> >> >> >> --boundaryX >> >> Content-Type: application/EmergencyCallData.eCall.control+xml >> >> Content-ID: 2345678901@atlanta.example.com >> >> >> Content-Disposition: by-reference;handling=optional >> >> >> >> >> >> > >> xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> >> xsi:schemaLocation= >> >> >> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >> >> >> >> >> >> >> >> >> >> >> >> --boundaryX-- >> >> ---------------------------------------------------------------------- >> -------- >> >> >> >> Kind regards >> >> >> >> Ivo >> >> >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, August 05, 2016 4:43 PM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings >> no value >> >> >> >> Ivo, >> >> >> >> IIUC, you are saying that the Call-Info that refers to the body is >> unnecessary because the recipient will know what to do with the body >> even in the absence of the Call-Info. Is that right? >> >> >> >> This assumption mixes up two things: >> >> - understanding a body syntactically >> >> - understanding *why* the body is present and how it should be used. >> >> >> >> Historically, processing of body parts in sip was very poorly defined. >> >> Initially the only body of interest was SDP, so how one might process >> other bodies or body parts was not well considered. Eventually this >> started to be a liability, so RFC5621 was published to clarify it. >> >> >> >> Processing of body parts is governed by a complex interaction between >> Content-Type, Content-Disposition, Content-ID. >> >> >> >> So the call-info header indicates the reason that body is being >> included. I realize that there is one predominant reason for doing so, >> but that is not the only possible reason. (E.g., it might be included >> as context in an intended discussion about problems handling a call in >> the >> >> past.) >> >> >> >> If all the handling of the call is coded in a special purpose way, >> solely for the emergency call path, then alternatives may be of no >> concern. But ideally the call will largely be handled via standard >> library code that is also used for other call paths and other message >> processing. So processing body parts in a "standard" way, rather than >> special casing, is desirable. >> >> >> >> Thanks, >> >> Paul >> >> >> >> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> >>> Hello, >> >>> >> >>> >> >>> >> >>> COMMENT: >> >>> >> >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> \ >> >>> \\\\\\\\ >> >>> >> >>> Inclusion of Call-Info header field with >> >>> purpose=emergencyCallData.eCall.MSD or >> >>> purpose=emergencyCallData.eCall.control in requests and responses >>> does >> >>> not seem to bring any value. It seems to only waste radio resources. >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=emergencyCallData.eCall.MSD included in >>> the >> >>> initial INVITE request: >> >>> >> >>> - if this is meant to be used by a proxy for routing of the eCall >> >>> emergency call to a PSAP supporting eCall emergency call, then this >> >>> seems to be redundant to the eCall URN included in the Request-URI >>> and >> >>> the Recv-Info header field containing eCall specific info package >> >>> (emergencyCallData.eCall.MSD). >> >>> >> >>> - if this is meant to be used by UAS (i.e. PSAP), then according to >> >>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >> >>> the bodies of the INVITE request not marked with Content-Disposition: >> >>> ...; handling=optional are understood. So, >> >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>> found by UAS during the INVITE request processing. >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=emergencyCallData.eCall.control included >>> in >> >>> a response to the initial INVITE request >> >>> >> >>> - no routing decisions are done by proxies when receiving a response >> >>> to the initial INVITE request so this does not seem to have any value >> >>> for the proxies >> >>> >> >>> - UAC includes Accept with supported MIME types in INVITE request so >> >>> why would UAS send any MIME body not wished by the UAC? >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=emergencyCallData.eCall.control included >>> in >> >>> the INFO request >> >>> >> >>> - no routing decisions are done by proxies when receiving an >>> in-dialog >> >>> request so this does not seem to have any value for the proxies >> >>> >> >>> - support of info package emergencyCallData.eCall.MSD in the call >> >>> implies that either application/EmergencyCallData.eCall.control+xml >> >>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is >> >>> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway >> >>> needs to check that all the bodies of the INFO request not marked >>> with >> >>> Content-Disposition: ...; handling=optional are understood. So, >> >>> application/EmergencyCallData.eCall.control+xml MIME body or >> >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>> found by UAS during the INFO request processing. >> >>> >> >>> ///////////////////////////////////////////////////////////////////// >>> / >> >>> //////// >> >>> >> >>> PROPOSED SOLUTION to COMMENT >> >>> >> >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> \ >> >>> \\\\\\\\ >> >>> >> >>> Remove insertion of Call-Info header field. >> >>> >> >>> ///////////////////////////////////////////////////////////////////// >>> / >> >>> //////// >> >>> >> >>> >> >>> >> >>> Kind regards >> >>> >> >>> >> >>> >> >>> Ivo Sedlacek >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >>> >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Mon Aug 8 08:04:47 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 500AB12D850 for ; Mon, 8 Aug 2016 08:04:46 -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 yIDcL3gLqN3o for ; Mon, 8 Aug 2016 08:04:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 273AD12D0B1 for ; Mon, 8 Aug 2016 08:04:42 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-a1-57a89f896c42 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 27.05.02493.98F98A75; Mon, 8 Aug 2016 17:04:41 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 17:03:51 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek , "R.Jesske@telekom.de" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAC6D8P//6ZcAgAAj46A= Date: Mon, 8 Aug 2016 15:03:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBC1D55@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BBC1A7F@ESESSMB208.ericsson.se> <013a7445-0cb7-5ba3-5cfc-ad29db62d034@alum.mit.edu> In-Reply-To: <013a7445-0cb7-5ba3-5cfc-ad29db62d034@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7k27n/BXhBvd/Klg0LnrKarFiwwFW i6Y7XWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6Mef8nsBb8zqjo7M5sYFwT 3MXIySEhYCLxcftDdhBbSGA9o8Slo/VdjFxA9mJGiYadjWxdjBwcbAIWEt3/tEHiIgLLGCXO X7nPCNIgLLCQUeLh8hgQW0RgEaPE4uVyELafxP2/l5hBelkEVCQ+dGqCmLwCvhJ3TrhDjO9g lng37zszSDmngIPEwee9bCA2o4CYxPdTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wQ tpLEiu2XGCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExhFZiEZOwtJyywkLbOQtCxgZFnF KFqcWlycm25kpJdalJlcXJyfp5eXWrKJERgdB7f8ttrBePC54yFGAQ5GJR5ehfLl4UKsiWXF lbmHGCU4mJVEeG/OXREuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoR TJaJg1OqgXETB9Ov8JKWlaFHeXYslVZjqJdJqP1mt3XyumlZZ5+4vnm7vcHOKMDyKNcJd7MS xc4PQc0/CouvufR02eqFxd3c3/2lyOD6Yp458r99Log4y9m9jZE/w2/bdu3iL4leGbOFaxcd F3a2Z79jrvr3p+vUaTfL/Q3/upxIWOH/pzS48KjDtua+pUosxRmJhlrMRcWJAJn9pUKKAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 15:04:46 -0000 Hi, ... > But I will take your point. I haven't been paying close enough attention = to the details of the draft. I see that=20 > it is effectively specifying that when the call-info has purpose=3D"emerg= encyCallData.eCall.MSD" then it MUST have a CID URL. > > But still, how is the processing of the body specified. I see the followi= ng used: > > Content-Disposition: by-reference;handling=3Doptional > > This specifically says that the disposition of the body is determined by = a *reference* to the body. If the call-info isn't used there won't be any r= eference. > > If you want to remove the call-info, then you need to define a new c-d ty= pe that specifies how the body part is to be=20 > processed. The content-type isn't sufficient by itself, since there could= be a variety of ways it can be disposed of. E.g., it=20 > could be rendered, or logged.=20 > "Render" is the default, but "render" has no clear meaning in SIP - it wa= s really intended for email. At this point I am not saying we should remove it from INVITE - I am saying= we don't need it for INFO (and, when used within INFO, the C-D value shall= be "Info-Package"). Regarding INVITE, I am trying to understand for what it is needed. Regards, Christer >> *From:*R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] >> *Sent:* Monday, August 08, 2016 11:45 AM >> *To:* Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org >> *Subject:* AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 >> usage brings no value) >> >> >> >> Hi Ivo, >> >> using the ecall urn (urn:service:sos.ecall.automatic) does not=20 >> implicitly means using the MSD within the Body. It could be also an=20 >> interworked call where all ecall information is included inband using=20 >> the In-band modem solution. >> >> >> >> We have to think also on backwards compatibility issues. Thus when=20 >> moving PSAP's to SIP imply also that there must exist an interworking=20 >> between the old mobile world towards the new mobile world using SIP. >> >> >> >> Using the Call-Info header would help the PAST to distinguish the=20 >> in-band and outband solution. Perhaps it would be worth to define an=20 >> additional value for inband data, to identify ecalls coming from=20 >> other networks not supporting the MSD Body. >> >> >> >> Best Regards >> >> >> Roland. >> >> >> >> >> >> *Von:*Ecrit [mailto:ecrit-bounces@ietf.org] *Im Auftrag von *Ivo=20 >> Sedlacek >> *Gesendet:* Montag, 8. August 2016 09:59 >> *An:* Paul Kyzivat; ecrit@ietf.org >> *Betreff:* [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 >> usage brings no value) >> >> >> >> Hello, >> >> >> >> According to RFC3261, the Call-Info header field provides additional=20 >> information about the caller or callee. >> >> >> >> According to draft-ietf-ecrit-ecall-11, the Call-Info header field is=20 >> used to form a "content-table" of pointers to bodies INVITE request=20 >> (and of INVITE response, of INFO request) in headers of INVITE=20 >> request (and of INVITE response, of INFO request). >> >> >> >> If the Call-Info header field points to a body which describes the=20 >> callers or callee, then Call-Info semantic fits (even though I would=20 >> still question usefulness of such Call-Info inclusion). >> >> >> >> If the Call-Info header field points to a body which request an=20 >> action in remote UE and which reports to remote UE an outcome of an=20 >> action done by the local UE, then Call-Info semantic does not fit. >> >> >> >> Particularly: >> >> --------------------------------------------------------------------- >> - >> -------- >> >> A PSAP or IVS transmits a metadata/control object (see Section 9)=20 >> by >> >> encoding it per the description in this document and attaching it=20 >> to >> >> a SIP message as a MIME body part per [RFC7852]. The body part is >> >> identified by its MIME content-type ('application/ >> >> emergencyCallData.eCall.control+xml') in the Content-Type header >> >> field of the body part. The body part is assigned a unique >> >> identifier which is listed in a Content-ID header field in the=20 >> body >> >> part. The SIP message is marked as containing the=20 >> metadata/control >> >> object by adding (or appending to) a Call-Info header field at the >> >> top level of the SIP message. This Call-Info header field=20 >> contains a >> >> CID URL referencing the body part's unique identifier, and a >> >> 'purpose' parameter identifying the data as an eCall=20 >> metadata/control >> >> block per the Emergency Call Additional Data Blocks registry=20 >> entry; >> >> the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. >> >> --------------------------------------------------------------------- >> - >> -------- >> >> and >> >> --------------------------------------------------------------------- >> - >> -------- >> >> SIP/2.0 200 OK >> >> To: ;tag=3D9fxced76sl >> >> From: Exemplar PSAP >> >> Call-ID: 3848276298220188511@atlanta.example.com >> >> >> Call-Info: cid:2345678901@atlanta.example.com; >> >> purpose=3DemergencyCallData.eCall.control; >> >> Accept: application/sdp, application/pidf+xml, >> >> application/emergencyCallData.eCall.control+xml, >> >> application/emergencyCallData.eCall.MSD+per >> >> CSeq: 31862 INVITE >> >> Recv-Info: emergencyCallData.eCall.MSD >> >> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >> >> SUBSCRIBE, NOTIFY, UPDATE >> >> Content-Type: multipart/mixed; boundary=3DboundaryX >> >> Content-Length: ... >> >> >> >> --boundaryX >> >> Content-Type: application/sdp >> >> >> >> ...Session Description Protocol (SDP) goes here... >> >> >> >> --boundaryX >> >> Content-Type: application/EmergencyCallData.eCall.control+xml >> >> Content-ID: 2345678901@atlanta.example.com=20 >> >> >> Content-Disposition: by-reference;handling=3Doptional >> >> >> >> >> >> > >> xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:contro= l" >> >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" >> >> xsi:schemaLocation=3D >> >> >> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >> >> >> >> > "/> >> >> >> >> >> >> >> >> --boundaryX-- >> >> --------------------------------------------------------------------- >> - >> -------- >> >> >> >> Kind regards >> >> >> >> Ivo >> >> >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, August 05, 2016 4:43 PM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >> brings no value >> >> >> >> Ivo, >> >> >> >> IIUC, you are saying that the Call-Info that refers to the body is=20 >> unnecessary because the recipient will know what to do with the body=20 >> even in the absence of the Call-Info. Is that right? >> >> >> >> This assumption mixes up two things: >> >> - understanding a body syntactically >> >> - understanding *why* the body is present and how it should be used. >> >> >> >> Historically, processing of body parts in sip was very poorly defined. >> >> Initially the only body of interest was SDP, so how one might process=20 >> other bodies or body parts was not well considered. Eventually this=20 >> started to be a liability, so RFC5621 was published to clarify it. >> >> >> >> Processing of body parts is governed by a complex interaction between=20 >> Content-Type, Content-Disposition, Content-ID. >> >> >> >> So the call-info header indicates the reason that body is being=20 >> included. I realize that there is one predominant reason for doing=20 >> so, but that is not the only possible reason. (E.g., it might be=20 >> included as context in an intended discussion about problems handling=20 >> a call in the >> >> past.) >> >> >> >> If all the handling of the call is coded in a special purpose way,=20 >> solely for the emergency call path, then alternatives may be of no=20 >> concern. But ideally the call will largely be handled via standard=20 >> library code that is also used for other call paths and other message=20 >> processing. So processing body parts in a "standard" way, rather than=20 >> special casing, is desirable. >> >> >> >> Thanks, >> >> Paul >> >> >> >> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> >>> Hello, >> >>> >> >>> >> >>> >> >>> COMMENT: >> >>> >> >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> \ >>> \ >> >>> \\\\\\\\ >> >>> >> >>> Inclusion of Call-Info header field with >> >>> purpose=3DemergencyCallData.eCall.MSD or >> >>> purpose=3DemergencyCallData.eCall.control in requests and responses=20 >>> does >> >>> not seem to bring any value. It seems to only waste radio resources. >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in=20 >>> the >> >>> initial INVITE request: >> >>> >> >>> - if this is meant to be used by a proxy for routing of the eCall >> >>> emergency call to a PSAP supporting eCall emergency call, then this >> >>> seems to be redundant to the eCall URN included in the Request-URI=20 >>> and >> >>> the Recv-Info header field containing eCall specific info package >> >>> (emergencyCallData.eCall.MSD). >> >>> >> >>> - if this is meant to be used by UAS (i.e. PSAP), then according to >> >>> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >> >>> the bodies of the INVITE request not marked with Content-Disposition: >> >>> ...; handling=3Doptional are understood. So, >> >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>> found by UAS during the INVITE request processing. >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >>> in >> >>> a response to the initial INVITE request >> >>> >> >>> - no routing decisions are done by proxies when receiving a response >> >>> to the initial INVITE request so this does not seem to have any=20 >>> value >> >>> for the proxies >> >>> >> >>> - UAC includes Accept with supported MIME types in INVITE request so >> >>> why would UAS send any MIME body not wished by the UAC? >> >>> >> >>> >> >>> >> >>> For Call-Info with purpose=3DemergencyCallData.eCall.control included=20 >>> in >> >>> the INFO request >> >>> >> >>> - no routing decisions are done by proxies when receiving an=20 >>> in-dialog >> >>> request so this does not seem to have any value for the proxies >> >>> >> >>> - support of info package emergencyCallData.eCall.MSD in the call >> >>> implies that either application/EmergencyCallData.eCall.control+xml >> >>> MIME body or application/emergencyCallData.eCall.MSD+per MIME body=20 >>> is >> >>> included. Again, according to RFC3261 subclause 8.2.3, the UAS=20 >>> anyway >> >>> needs to check that all the bodies of the INFO request not marked=20 >>> with >> >>> Content-Disposition: ...; handling=3Doptional are understood. So, >> >>> application/EmergencyCallData.eCall.control+xml MIME body or >> >>> application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> >>> found by UAS during the INFO request processing. >> >>> >> >>> //////////////////////////////////////////////////////////////////// >>> / >>> / >> >>> //////// >> >>> >> >>> PROPOSED SOLUTION to COMMENT >> >>> >> >>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> \ >>> \ >> >>> \\\\\\\\ >> >>> >> >>> Remove insertion of Call-Info header field. >> >>> >> >>> //////////////////////////////////////////////////////////////////// >>> / >>> / >> >>> //////// >> >>> >> >>> >> >>> >> >>> Kind regards >> >>> >> >>> >> >>> >> >>> Ivo Sedlacek >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ecrit >> >>> >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Mon Aug 8 08:22:34 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 E949512D86A for ; Mon, 8 Aug 2016 08:22:31 -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 34kFBXgjTJiK for ; Mon, 8 Aug 2016 08:22:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B528D12D863 for ; Mon, 8 Aug 2016 08:22:25 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-3d-57a8a3adc138 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 4A.02.06563.DA3A8A75; Mon, 8 Aug 2016 17:22:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 17:22:21 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "R.Jesske@telekom.de" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8XaiLChU0Dj6Gk2iMZrvgMo6yaA/LPHA Date: Mon, 8 Aug 2016 15:22:20 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C0A72@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7uu6GxSvCDXrusls0LnrKarFiwwFW i6Y7XWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6M8+cnsBR0s1es2veStYHx LGsXIyeHhICJxM+zR5i7GLk4hATWM0q0z3zKCuEsZpS49m4mE0gVm4CexMQtR8A6RASqJO48 n8wGYgsLLGSUeLg8BiK+iFFi8XI5CNtI4sitO2A1LAIqEn2ty4BsDg5eAV+JtxPYIeb3MUnc bd8HNpNTwEFi67MpjCA2o4CsxNU/vWA2s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/qA+UJNYe 3s4CUa8jsWD3JzYIW1ti2cLXYPW8AoISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTi 4tx0I2O91KLM5OLi/Dy9vNSSTYzAGDm45bfuDsbVrx0PMQpwMCrx8CqULw8XYk0sK67MPcQo wcGsJMI7f+GKcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTByc Ug2MAu13Tz0Tjfh+ba2d6RydOKnf/SufHw776uNaoNHwqFcn10jAbs7aVSecV70waApY3e00 Z9Xmd9GeM18n9lWsu2nqdPKPmmTGgdCON5JNW2blXXm998tsw5Ptvj3XbzZLeyWtTb9xdsnX LyEvtI3+fNOsmKOtuTn6lNWKF5dP5PQf6vm3uj2QXYmlOCPRUIu5qDgRAH6fTgqNAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 15:22:33 -0000 > In this case, IIUC, there *could* be a call-info header pointing to the e= call info in an external server. The data being in a body part is simply a = special case of that.=20 > So it makes sense to me that the starting point for discovering ecall dat= a be with the call-info header. (Again, I'm not talking about INFO here. Th= e situation is different for it.) In case of draft-ietf-ecrit-ecall-11, the Call-Info in an INVITE *always* p= oints to the body of the same INVITE. And, again, semantically the Call-Info is supposed to carry info about call= ee or caller according to RFC3261.=20 If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. A new header field would n= eed to be defined for that purpose. Kind regards Ivo From nobody Mon Aug 8 09:54: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 0FEDB12D864 for ; Mon, 8 Aug 2016 09:54:17 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 rKclikUawt-F for ; Mon, 8 Aug 2016 09:54:15 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 9A5B112D85A for ; Mon, 8 Aug 2016 09:54:14 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-10v.sys.comcast.net with SMTP id WnoTbV4vxHqolWnobbv8CL; Mon, 08 Aug 2016 16:54:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id WnoabeMYQVhkuWnoab8O7M; Mon, 08 Aug 2016 16:54:13 +0000 To: Ivo Sedlacek , "R.Jesske@telekom.de" , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0A72@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 8 Aug 2016 12:54:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C0A72@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDGeiSQRIr+ymNSUJLqJ+dumynHm4zPcp8AbherRqtMEXeSvZb3RkHKk0oJ9HsqatWDuKVeCwHoTliTb4Knaz7wtrAW3FM7Ofn3+MMj9STkKu92e4eg7 18Z8VpgrooNZr/tJZNaJe848iclhs0RjVtQm7wU1rNM8YrL+FO5IZZSTGWw3JyA3E2ae5/LBRB8Qu6Sw/Z8vYftuXHnNuIGEDSYaFj1fILfD5ogddXaJtN5Y RjHmQh0tiPe5pkYDlVwYbw== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 08 Aug 2016 16:54:17 -0000 On 8/8/16 11:22 AM, Ivo Sedlacek wrote: >> In this case, IIUC, there *could* be a call-info header pointing to the ecall info in an external server. The data being in a body part is simply a special case of that. >> So it makes sense to me that the starting point for discovering ecall data be with the call-info header. (Again, I'm not talking about INFO here. The situation is different for it.) > > In case of draft-ietf-ecrit-ecall-11, the Call-Info in an INVITE *always* points to the body of the same INVITE. > > And, again, semantically the Call-Info is supposed to carry info about callee or caller according to RFC3261. > > If the Call-Info header field points to a body which request an action in remote UE and which reports to remote UE an outcome of an action done by the local UE, then Call-Info semantic does not fit. A new header field would need to be defined for that purpose. If you don't want to use call-info, then define a new content-disposition value that signifies what to do with the content. (Content-type only says what it *is*, not what to do with it.) The c-d of "by-reference" doesn't make sense in this case. Thanks, Paul From nobody Tue Aug 9 07:23: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 4482212D5CB for ; Tue, 9 Aug 2016 07:23:11 -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 opy--xwT4EkE for ; Tue, 9 Aug 2016 07:23:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 DEB1612D882 for ; Tue, 9 Aug 2016 07:23:09 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-eb-57a9e74c4d2e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 2A.E5.02553.C47E9A75; Tue, 9 Aug 2016 16:23:08 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0301.000; Tue, 9 Aug 2016 16:23:07 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8XaiLChU0Dj6Gk2iMZrvgMo6yaBAqmcw Date: Tue, 9 Aug 2016 14:23:07 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM2K7uq7P85XhBrObBS0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrKdt5gKljJX/DnylrGB8TxTFyMnh4SAicSkb7OZuxi5OIQE 1jNKNH39wgLhLGaUmPPvNiNIFZuAnsTELUdYQWwRAVWJDWdWgsWFBRYySjxcHgMRX8QosXi5 HIRtJHHj8zJ2EJtFQEViypfFzCA2r4CvxPKFnawQC/qYJO627wMbyingILH12RSwoYwCshJX //SC2cwC4hK3nsyHOlVAYsme88wQtqjEy8f/WCFsRYn2pw1Q9ToSC3Z/YoOwtSWWLXwNtVhQ 4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGP4H t/w22MH48rnjIUYBDkYlHt4FJ1aEC7EmlhVX5h5ilOBgVhLhbXiyMlyINyWxsiq1KD++qDQn tfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDY1nr/vDnhSpLn886vJTX9+DKNbdr vh08ucPmjXceO+/5X3NXXTv9cZqJfeiHDobOPdtkWcs3Mz5MmOC4PkajV9b/yvXF+x5WuE3z FLmhG67wMGvXtPKvC3XWH3m2/p2PtS6LJc+ib5lCIho3rzyTvtugIH9f6JAoz37B9MhXyzMz PnC++pkUtleJpTgj0VCLuag4EQBy6yOcewIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 09 Aug 2016 14:23:12 -0000 Hello, given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise:=20 Call-Info included in an INVITE request and pointing to the application/em= ergencyCallData.eCall.MSD+per body of the INVITE request is kept, while Cal= l-Info in a response to the INVITE request and in an INFO request is remove= d. Does this work for everyone? Kind regards Ivo Sedlacek From nobody Tue Aug 9 09:01: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 8FCA312D5D5 for ; Tue, 9 Aug 2016 09:01:44 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 A8YNYux8gMs7 for ; Tue, 9 Aug 2016 09:01:43 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 99E6912D15A for ; Tue, 9 Aug 2016 09:01:42 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-05v.sys.comcast.net with SMTP id X9PIbTals2FGMX9TKb5SfF; Tue, 09 Aug 2016 16:01:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id X9TJbbHYukIEeX9TKbTf2K; Tue, 09 Aug 2016 16:01:42 +0000 To: ecrit@ietf.org References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> Date: Tue, 9 Aug 2016 12:01:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCbrv4TQzyMfsUwFUISpgNbrBmT27G8SPBPZuvALvBxCcntL5SvAdLW0HWFTXSUT+7/Z+BmmT5xPcaSIwRUulvSRcTOq2v02g5CQwXfV4FqH+58K9qGK 1bl8uBLvVbE64qGTqF7rByr5UwHB5mG0trY6MXZ3W/jhplgvvH0ULWw7U5FynnvLD+BpNiuHof/bxg== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 09 Aug 2016 16:01:44 -0000 On 8/9/16 10:23 AM, Ivo Sedlacek wrote: > Hello, > > given the use case raised by Roland and clarified by Paul, let me suggest the following compromise: > > Call-Info included in an INVITE request and pointing to the application/emergencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call-Info in a response to the INVITE request and in an INFO request is removed. > > Does this work for everyone? I agree wrt INFO, but not for INVITE response. The invite response still has a body with content-disposition by-reference. If you remove the reference then its processing is undefined. Thanks, Paul From nobody Wed Aug 10 00:41:14 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 3EE0912D15F for ; Wed, 10 Aug 2016 00:41:13 -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 o4YI7x10W-L9 for ; Wed, 10 Aug 2016 00:41:12 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6D37112D0EE for ; Wed, 10 Aug 2016 00:41:11 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-5d-57aada9499e5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 93.05.06563.49ADAA75; Wed, 10 Aug 2016 09:41:09 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 09:41:08 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8XaiLChU0Dj6Gk2iMZrvgMo6yaBAqmcw////x4CAASWXgA== Date: Wed, 10 Aug 2016 07:41:08 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> In-Reply-To: <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> Accept-Language: en-US, cs-CZ 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+NgFvrALMWRmVeSWpSXmKPExsUyM2K7nO7UW6vCDc72KVo0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjasMploLTHBWdhysaGPvZuxg5OSQETCS2 T3jD2MXIxSEksJ5RYuaVbVDOEkaJs0d62ECq2AT0JCZuOcIKYosIeEv8+f0NLC4ssJBR4uHy GIj4IkaJxcvluhg5gGwniRlnk0HCLAKqEp+WXGECsXkFfCVW/L3PBDG/g1ni5/89YDM5BRwk zu54wQxiMwrISlz908sIYjMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUkVmy/BFWvI7Fg 9yc2CFtbYtnC18wQiwUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnpRsZ6qUWZ ycXF+Xl6eaklmxiB8XBwy2/dHYyrXzseYhTgYFTi4VWQWhUuxJpYVlyZe4hRgoNZSYTX/yZQ iDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA2P2lwXdB82Y P17lfqa2q/HSpYrOVVs09AXn70s3WrvmitXU7qvyvyu9BOfusfRzPpsxsYTv6Cn9LA3xAraP +98I9/3hu3iGWfqk6e95SYnsTLcfP72TEHyvJN1+jVGryH6BN4eneP7zqTsW0uYouaamri/1 xLFXrGeXFD9u74vd61L9bKvYrDAlluKMREMt5qLiRAApuOsbgwIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 07:41:13 -0000 Hello, > The invite response still has a body with content-disposition by-referenc= e. If you remove the reference then its processing is undefined. If the Call-Info is omitted in INVITE response, then: Alt1: a new value could be defined and used in the Content-Disposition head= er field of the application/emergencyCallData.eCall.control+xml body; or Alt2: an existing value could be used in the Content-Disposition header fie= ld of the application/emergencyCallData.eCall.control+xml body; or Alt3: the Content-Disposition header field can be omitted and thus "render"= would apply for the application/emergencyCallData.eCall.control+xml body a= ccording to RFC3261 section 13.2.1. We cannot use the Call-Info in INVITE response as described in draft-ietf-= ecrit-ecall-11 - in the response to the INVITE request, the Call-Info point= s to the application/emergencyCallData.eCall.control+xml body. This body co= ntains a delivery report for the MSD sent in INVITE request. This is NOT in= formation about callee as described in RFC3261.=20 Kind regards Ivo From nobody Wed Aug 10 05:54: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 6F9D012D7BE for ; Wed, 10 Aug 2016 05:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 M2baXPLNOkAp for ; Wed, 10 Aug 2016 05:54:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 7A83812D596 for ; Wed, 10 Aug 2016 05:54:22 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u7ACsESN011506 for ; Wed, 10 Aug 2016 08:54:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : content-type : mime-version; s=neustar.biz; bh=38rV6OMtA5ucTmR3tuxyTcP3Lew8bv3g6eL62ayzvEs=; b=zc1f/3FfgzNrBn4fwVnOWf/uEHakivlaJhGDssevWDDOkWNyIx+OtbcJsHg6CKLS+ahr vR/g5cY98FczZFvjzqRkQuPnBR/6ObOearkom3z9UxEHZ+K3IHqVUiqfpaDbHe/7ociS 1SAU/Hjd+dEk7GcRF13saP1Usu0BZb6p3rsOmZbCZqEVJs4BmXQxJQqPxm2ll4viQQSb Mst7wGczOil2eulzxZXvJbtXgizCApyhCC+jBDUfWZAJPnuz95lZ7QhJgXtGvRWOQnAg vteI1iThHXSGDNIkOhmqXqHW50cFk3OzwhTteMa/W56sFbUzgWXI/KEXo2+5Jmd63k9d lA== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 24qm95pd4u-4 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 10 Aug 2016 08:54:21 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Wed, 10 Aug 2016 08:54:07 -0400 From: "Rosen, Brian" To: Emergency Context Resolution with Internet Technologies Discussion List Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8wZH9cp2nZ4HkkC6msHXdRFV4A== Date: Wed, 10 Aug 2016 12:54:07 +0000 Message-ID: <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.77] Content-Type: multipart/alternative; boundary="_000_9A5A1E0F87254EF99A2D5264932AA1F3neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-10_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 12:54:24 -0000 --_000_9A5A1E0F87254EF99A2D5264932AA1F3neustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaWQgbm90IHByb3Blcmx5IGFkZHJlc3MgYSByZXNwb25zZSB0byBJdm8gYW5kIFJhbmR5IHRv IGluY2x1ZGUgdGhlIHdvcmtpbmcgZ3JvdXAsIHNvIEnigJltIGZvcndhcmRpbmcgdGhpcyBwYXJ0 IG9mIHRoZSBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIGdyb3VwLg0KDQpJIHRoaW5rLCBJdm8sIHRo YXQgeW91IGFyZSBiZWluZyB3YXkgdG9vIHBpY2t5IGFib3V0IHdoZXRoZXIgdGhlIHJlcG9ydCBp cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2FsbGVlIG9yIHRoZSBjb250cm9sIGJvZHkgaXMgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGNhbGxlci4gIEkgdGhpbmsgaXTigJlzIGNsb3NlIGVub3VnaCB0 aGF0IHdlIHNob3VsZCBub3QgdXNlIHRoYXQgYXMgdGhlIHJlYXNvbiB3ZSBkb27igJl0IG1ha2Ug YWxsIG9mIHRoZXNlIGluc3RhbmNlcyBvZiBhZGRpdGlvbmFsIGRhdGEgdW5pZm9ybWx5Lg0KDQpJ IGFja25vd2xlZGdlIHRoYXQgaXTigJlzIG5vdCBuZWVkZWQgd2l0aCB0aGUgSU5GTyBwYWNrYWdl LCBidXQgSSB0aGluayBpdCBkb2VzIG5vIGhhcm0sIGFuZCBtYWtlcyB0aGUgZW50aXJlIG1lY2hh bmlzbSBjb25zaXN0ZW50IHdpdGggYWxsIHRoZSBvdGhlciBwYXJ0cyBvZiBhZGRpdGlvbmFsIGRh dGEsIHdoaWNoIHlvdSBhY2tub3dsZWRnZSB0aGF0IHRoZSBhY3R1YWwgZUNhbGwgZGF0YSBjbGVh cmx5IGlzLg0KDQpCcmlhbg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogSXZv IFNlZGxhY2VrIDxpdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPG1haWx0bzppdm8uc2VkbGFjZWtA ZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJFOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNh bGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTog ZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1 ZSkNCkRhdGU6IEF1Z3VzdCAxMCwgMjAxNiBhdCAzOjMyOjAwIEFNIEVEVA0KVG86ICJSb3Nlbiwg QnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rh ci5iaXo+PiwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0 bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4NCg0KSGVsbG8sDQoNCkluIHRoZSByZXNwb25z ZSB0byB0aGUgSU5WSVRFIHJlcXVlc3QsIHRoZSBDYWxsLUluZm8gcG9pbnRzIHRvIHRoZSBhcHBs aWNhdGlvbi9lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5jb250cm9sK3htbCBib2R5LiBUaGlzIGJv ZHkgY29udGFpbnMgYSBkZWxpdmVyeSByZXBvcnQgZm9yIHRoZSBNU0Qgc2VudCBpbiBJTlZJVEUg cmVxdWVzdC4gVGhpcyBpcyBOT1QgaW5mb3JtYXRpb24gYWJvdXQgY2FsbGVlLiBUaHVzLCBSRkMz MjYxIHNlbWFudGljIGlzIG5vdCBmdWxmaWxsZWQuDQoNCkluIHRoZSBJTkZPIHJlcXVlc3QsIHRo ZSBDYWxsLUluZm8gcG9pbnRzIHRvIHRoZSBhcHBsaWNhdGlvbi9lbWVyZ2VuY3lDYWxsRGF0YS5l Q2FsbC5jb250cm9sK3htbCBib2R5LiBUaGlzIGJvZHkgZGVzY3JpYmVzIGFuIGFjdGlvbiB0byBi ZSBwZXJmb3JtZWQgYXQgdGhlIHJlbW90ZSBVRS4gVGhpcyBpcyBOT1QgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHNlbmRlciBvZiB0aGUgSU5GTyByZXF1ZXN0LiBUaHVzLCBSRkMzMjYxIHNlbWFudGlj IGlzIG5vdCBmdWxmaWxsZWQuIEFsc28sIGFzIG90aGVyIHBlb3BsZSBpbmRpY2F0ZWQsIHRoaXMg aXMgbm90IG5lZWRlZCB3aXRoIGluZm8gcGFja2FnZSBtZWNoYW5pc20uDQoNCktpbmQgcmVnYXJk cw0KDQpJdm8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvc2VuLCBCcmlh biBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KU2VudDogVHVlc2RheSwgQXVndXN0 IDA5LCAyMDE2IDExOjIyIFBNDQpUbzogUmFuZGFsbCBHZWxsZW5zDQpDYzogSXZvIFNlZGxhY2Vr DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxsLUlu Zm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6IGRyYWZ0LWlldGYtZWNy aXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8gdmFsdWUpDQoNCkkgc3Ryb25n bHkgYWdyZWUuDQoNCkl04oCZcyBzbWFsbCBjb3N0IGFuZCBJIHRoaW5rIGEgc3Vic3RhbnRpYWwg YmVuZWZpdCB0byB0cmVhdCBhbGwgdGhlIGJsb2NrcyBhcyBhZGRpdGlvbmFsIGRhdGEgYmxvY2tz LCBwdXQgdGhlbSBpbiB0aGUgcmVnaXN0cnksIGV0Yy4gIElORk8gaXMgYSBzb2x1dGlvbiB0byBh IG1pZC1jYWxsIG5lZWQgdG8gc2VuZCBhZGRpdGlvbmFsIGRhdGEsIGFuZCB3ZSBzaG91bGQgdHJl YXQgaXQgdGhhdCB3YXkgaW4gbXkgb3Bpbmlvbi4NCg0KV2UgY2FuIHN0YXRlIHRoYXQgdGhlIGJs b2NrIHJlZmVyZW5jZSBpbiB0aGUgSU5GTyBwYWNrYWdlIG11c3QgbWF0Y2ggdGhhdCBpbiB0aGUg Q2FsbC1JbmZvLg0KDQpCcmlhbg0KDQpPbiBBdWcgOSwgMjAxNiwgYXQgMToyMiBQTSwgUmFuZGFs bCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoNCkkgcHJlZmVyIHRvIGtlZXAgdGhlIHVzZSBvZiBDYWxs LUluZm8gZm9yIGFsbCB0aHJlZSBjYXNlcyAoSU5WSVRFLCByZXNwb25zZSwgSU5GTykgdG8gbWFp bnRhaW4gY29tcGF0aWJpbGl0eSB3aXRoIFJGQyA3ODUyIChBZGRpdGlvbmFsIERhdGEpIGFuZCBj YXItY3Jhc2ggKE5vcnRoIEFtZXJpY2FuIE5HLUFBQ04pLiAgSSBzZWUgYmVuZWZpdCB3aXRob3V0 IGFueSByZWFsLXdvcmxkIGhhcm0gaW4gdXNpbmcgQ2FsbC1JbmZvIGV2ZW4gaWYgbm90IHN0cmlj dGx5IG5lY2Vzc2FyeSAoZS5nLiwgSU5GTykuDQoNCi0tUmFuZHkNCg0KQXQgMjoyMyBQTSArMDAw MCA4LzkvMTYsIEl2byBTZWRsYWNlayB3cm90ZToNCg0KSGVsbG8sDQoNCmdpdmVuIHRoZSB1c2Ug Y2FzZSByYWlzZWQgYnkgUm9sYW5kIGFuZCBjbGFyaWZpZWQgYnkgUGF1bCwgbGV0IG1lIHN1Z2dl c3QgdGhlIGZvbGxvd2luZyBjb21wcm9taXNlOg0KDQpDYWxsLUluZm8gaW5jbHVkZWQgaW4gYW4g SU5WSVRFIHJlcXVlc3QgYW5kIHBvaW50aW5nIHRvIHRoZSBhcHBsaWNhdGlvbi9lbWVyZ2VuY3lD YWxsRGF0YS5lQ2FsbC5NU0QrcGVyIGJvZHkgb2YgdGhlIElOVklURSByZXF1ZXN0IGlzIGtlcHQs IHdoaWxlIENhbGwtSW5mbyBpbiBhIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCBhbmQg aW4gYW4gSU5GTyByZXF1ZXN0IGlzIHJlbW92ZWQuDQoNCkRvZXMgdGhpcyB3b3JrIGZvciBldmVy eW9uZT8NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3Jp dEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg0KLS0NClJhbmRhbGwgR2VsbGVucw0KT3BpbmlvbnMg YXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3IgbXlzZWxm IG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0t LS0tIEkgaG9sZCB0aGF0IHRoZQ0KdmVyeSBwdXJwb3NlIG9mIGV4aXN0ZW5jZSBpcyB0byByZWNv bmNpbGUgdGhlIGdsb3dpbmcgb3BpbmlvbiB3ZSBoYXZlDQpvZiBvdXJzZWx2ZXMgd2l0aCB0aGUg dGVycmlibGUgdGhpbmdzDQp0aGF0IG90aGVyIHBlb3BsZSBzYXkgYWJvdXQgdXMuICAgICAgICAg ICAgICAgLS1RdWVudGluIENyaXNwDQoNCg0K --_000_9A5A1E0F87254EF99A2D5264932AA1F3neustarbiz_ Content-Type: text/html; charset="utf-8" Content-ID: <06DBD7171F3E7A49B3B54E5F813C689B@neustar.biz> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBkaWQgbm90IHByb3Blcmx5IGFk ZHJlc3MgYSByZXNwb25zZSB0byBJdm8gYW5kIFJhbmR5IHRvIGluY2x1ZGUgdGhlIHdvcmtpbmcg Z3JvdXAsIHNvIEnigJltIGZvcndhcmRpbmcgdGhpcyBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIGJh Y2sgdG8gdGhlIGdyb3VwLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SSB0aGluaywgSXZvLCB0aGF0IHlvdSBhcmUgYmVpbmcgd2F5IHRvbyBwaWNr eSBhYm91dCB3aGV0aGVyIHRoZSByZXBvcnQgaXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNhbGxl ZSBvciB0aGUgY29udHJvbCBib2R5IGlzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjYWxsZXIuICZu YnNwO0kgdGhpbmsgaXTigJlzIGNsb3NlIGVub3VnaCB0aGF0IHdlIHNob3VsZCBub3QgdXNlIHRo YXQgYXMgdGhlIHJlYXNvbiB3ZSBkb27igJl0IG1ha2UgYWxsDQogb2YgdGhlc2UgaW5zdGFuY2Vz IG9mIGFkZGl0aW9uYWwgZGF0YSB1bmlmb3JtbHkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFja25vd2xlZGdlIHRoYXQgaXTigJlz IG5vdCBuZWVkZWQgd2l0aCB0aGUgSU5GTyBwYWNrYWdlLCBidXQgSSB0aGluayBpdCBkb2VzIG5v IGhhcm0sIGFuZCBtYWtlcyB0aGUgZW50aXJlIG1lY2hhbmlzbSBjb25zaXN0ZW50IHdpdGggYWxs IHRoZSBvdGhlciBwYXJ0cyBvZiBhZGRpdGlvbmFsIGRhdGEsIHdoaWNoIHlvdSBhY2tub3dsZWRn ZSB0aGF0IHRoZSBhY3R1YWwgZUNhbGwgZGF0YSBjbGVhcmx5IGlzLiAmbmJzcDs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJyaWFuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBzdHls ZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206 DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9u dCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkl2byBT ZWRsYWNlayAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIGNs YXNzPSIiPml2by5zZWRsYWNla0Blcmljc3Nvbi5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1 ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFz cz0iIj48YiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5SRTogW0Vjcml0XSBkcmFmdC1pZXRmLWVj cml0LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3 YXMgUkU6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3MN CiBubyB2YWx1ZSk8L2I+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkRhdGU6DQo8 L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwg SGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkF1Z3VzdCAx MCwgMjAxNiBhdCAzOjMyOjAwIEFNIEVEVDxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0 b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0i Ij5UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3Rl bS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ JnF1b3Q7Um9zZW4sIEJyaWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9zZW5A bmV1c3Rhci5iaXoiIGNsYXNzPSIiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPiZndDssIFJh bmRhbGwgR2VsbGVucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNp dmUub3JnIiBjbGFzcz0iIj5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvYT4mZ3Q7PGJy IGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+SGVsbG8sPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gdGhl IHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCwgdGhlIENhbGwtSW5mbyBwb2ludHMgdG8g dGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbCBi b2R5LiBUaGlzIGJvZHkgY29udGFpbnMgYSBkZWxpdmVyeSByZXBvcnQgZm9yIHRoZSBNU0Qgc2Vu dCBpbiBJTlZJVEUgcmVxdWVzdC4gVGhpcyBpcyBOT1QgaW5mb3JtYXRpb24gYWJvdXQgY2FsbGVl LiBUaHVzLCBSRkMzMjYxIHNlbWFudGljIGlzDQogbm90IGZ1bGZpbGxlZC4gPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KSW4gdGhlIElORk8gcmVxdWVzdCwgdGhlIENhbGwtSW5mbyBwb2lu dHMgdG8gdGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wmIzQz O3htbCBib2R5LiBUaGlzIGJvZHkgZGVzY3JpYmVzIGFuIGFjdGlvbiB0byBiZSBwZXJmb3JtZWQg YXQgdGhlIHJlbW90ZSBVRS4gVGhpcyBpcyBOT1QgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlbmRl ciBvZiB0aGUgSU5GTyByZXF1ZXN0LiBUaHVzLCBSRkMzMjYxIHNlbWFudGljIGlzIG5vdA0KIGZ1 bGZpbGxlZC4gQWxzbywgYXMgb3RoZXIgcGVvcGxlIGluZGljYXRlZCwgdGhpcyBpcyBub3QgbmVl ZGVkIHdpdGggaW5mbyBwYWNrYWdlIG1lY2hhbmlzbS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpLaW5kIHJlZ2FyZHM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdm88YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFz cz0iIj4NCkZyb206IFJvc2VuLCBCcmlhbiBbPGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5l dXN0YXIuYml6IiBjbGFzcz0iIj5tYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+XQ0K PGJyIGNsYXNzPSIiPg0KU2VudDogVHVlc2RheSwgQXVndXN0IDA5LCAyMDE2IDExOjIyIFBNPGJy IGNsYXNzPSIiPg0KVG86IFJhbmRhbGwgR2VsbGVuczxiciBjbGFzcz0iIj4NCkNjOiBJdm8gU2Vk bGFjZWs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0 LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMg UkU6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8g dmFsdWUpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBzdHJvbmdseSBhZ3JlZS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdOKAmXMgc21hbGwgY29zdCBhbmQgSSB0aGluayBh IHN1YnN0YW50aWFsIGJlbmVmaXQgdG8gdHJlYXQgYWxsIHRoZSBibG9ja3MgYXMgYWRkaXRpb25h bCBkYXRhIGJsb2NrcywgcHV0IHRoZW0gaW4gdGhlIHJlZ2lzdHJ5LCBldGMuICZuYnNwO0lORk8g aXMgYSBzb2x1dGlvbiB0byBhIG1pZC1jYWxsIG5lZWQgdG8gc2VuZCBhZGRpdGlvbmFsIGRhdGEs IGFuZCB3ZSBzaG91bGQgdHJlYXQgaXQgdGhhdCB3YXkgaW4gbXkgb3Bpbmlvbi48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpXZSBjYW4gc3RhdGUgdGhhdCB0aGUgYmxvY2sgcmVmZXJlbmNl IGluIHRoZSBJTkZPIHBhY2thZ2UgbXVzdCBtYXRjaCB0aGF0IGluIHRoZSBDYWxsLUluZm8uPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnJpYW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBBdWcgOSwgMjAxNiwgYXQg MToyMiBQTSwgUmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZA cmFuZHkucGVuc2l2ZS5vcmciIGNsYXNzPSIiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3Jn PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBwcmVmZXIgdG8g a2VlcCB0aGUgdXNlIG9mIENhbGwtSW5mbyBmb3IgYWxsIHRocmVlIGNhc2VzIChJTlZJVEUsIHJl c3BvbnNlLCBJTkZPKSB0byBtYWludGFpbiBjb21wYXRpYmlsaXR5IHdpdGggUkZDIDc4NTIgKEFk ZGl0aW9uYWwgRGF0YSkgYW5kIGNhci1jcmFzaCAoTm9ydGggQW1lcmljYW4gTkctQUFDTikuICZu YnNwO0kgc2VlIGJlbmVmaXQgd2l0aG91dCBhbnkgcmVhbC13b3JsZCBoYXJtIGluIHVzaW5nIENh bGwtSW5mbyBldmVuIGlmIG5vdCBzdHJpY3RseQ0KIG5lY2Vzc2FyeSAoZS5nLiwgSU5GTykuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS1SYW5keTxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkF0IDI6MjMgUE0gJiM0MzswMDAwIDgvOS8xNiwgSXZvIFNlZGxhY2VrIHdyb3RlOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPkhlbGxvLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmdpdmVuIHRoZSB1c2UgY2Fz ZSByYWlzZWQgYnkgUm9sYW5kIGFuZCBjbGFyaWZpZWQgYnkgUGF1bCwgbGV0IG1lIHN1Z2dlc3Qg dGhlIGZvbGxvd2luZyBjb21wcm9taXNlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PkNhbGwtSW5mbyBpbmNsdWRlZCBpbiBhbiBJTlZJVEUgcmVxdWVzdCBhbmQgcG9pbnRpbmcgdG8g dGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCYjNDM7cGVyIGJvZHkg b2YgdGhlIElOVklURSByZXF1ZXN0IGlzIGtlcHQsIHdoaWxlIENhbGwtSW5mbyBpbiBhIHJlc3Bv bnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCBhbmQgaW4NCiBhbiBJTkZPIHJlcXVlc3QgaXMgcmVt b3ZlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEb2VzIHRoaXMgd29yayBmb3IgZXZl cnlvbmU/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KS2luZCByZWdhcmRzPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSXZvIFNlZGxhY2VrPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIg Y2xhc3M9IiI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86RWNyaXRAaWV0Zi5vcmciIGNsYXNzPSIiPkVjcml0QGlldGYub3JnPC9hPjxiciBjbGFzcz0i Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBj bGFzcz0iIj4NClJhbmRhbGwgR2VsbGVuczxiciBjbGFzcz0iIj4NCk9waW5pb25zIGFyZSBwZXJz b25hbDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZmFjdHMgYXJlIHN1c3BlY3Q7ICZuYnNwOyZuYnNwOyZu YnNwO0kgc3BlYWsgZm9yIG15c2VsZiBvbmx5PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0g UmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0gSSBob2xkIHRoYXQgdGhlIDxi ciBjbGFzcz0iIj4NCnZlcnkgcHVycG9zZSBvZiBleGlzdGVuY2UgaXMgdG8gcmVjb25jaWxlIHRo ZSBnbG93aW5nIG9waW5pb24gd2UgaGF2ZSA8YnIgY2xhc3M9IiI+DQpvZiBvdXJzZWx2ZXMgd2l0 aCB0aGUgdGVycmlibGUgdGhpbmdzPGJyIGNsYXNzPSIiPg0KdGhhdCBvdGhlciBwZW9wbGUgc2F5 IGFib3V0IHVzLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLVF1ZW50aW4gQ3Jpc3A8YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_9A5A1E0F87254EF99A2D5264932AA1F3neustarbiz_-- From nobody Wed Aug 10 06:09:26 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 DDBB712D559 for ; Wed, 10 Aug 2016 06:09:24 -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 AnWxbhjsV7R8 for ; Wed, 10 Aug 2016 06:09:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6BA2512B05F for ; Wed, 10 Aug 2016 06:09:22 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-a7-57ab2780043e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 8B.93.02493.0872BA75; Wed, 10 Aug 2016 15:09:20 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 15:09:19 +0200 From: Christer Holmberg To: "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8wZVBk2Myc9CREydiCCv8UY8aaBCPIuA Date: Wed, 10 Aug 2016 13:09:19 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> In-Reply-To: <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D3D10138C554christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2J7iG6D+upwg6XX9S2mnbzMbNG46Cmr A5PHkiU/mTx2NDxnDmCK4rJJSc3JLEst0rdL4Mq4uWAiY8HJpIofxztYGhhbQ7oYOTkkBEwk 2lYeYu9i5OIQEljPKPHg6hlmCGcJo8TViy+AHA4ONgELie5/2iBxEYEuRonFjycwgTjCAssY Jda2tzBBZJYzSpzs3cgG0iEiYCTx9YEPyAoWAVWJ5dvnMIPYvAJWEsumfWKD2NDEKLHjYQML SIJTwF7i5svTjCA2o4CYxPdTa5hAbGYBcYlbT+YzQdwqILFkz3lmCFtU4uXjf6wgtqiAnsT3 r7Oh4ooSH1/tY4TojZe4vHg2O8RiQYmTM5+wTGAUmYVk7CwkZbOQlEHEDSTen5vPDGFrSyxb +BrK1pfY+OUsI4RtLTH5+k8UNQsYOVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbdwS2/ rXYwHnzueIhRgINRiYdXQWpVuBBrYllxZe4hRgkOZiUR3n0qq8OFeFMSK6tSi/Lji0pzUosP MUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MLZwqz49/dD5xdOAv48ssgWr5Wzfqvxt 0QxMyZ3iynup4vVz7jALWWvzixXCU83vJ2rlXN1WIXRHZVb/zor1R7qmPXps+T3nLrs6x7Es UY7pJ/VK5y1pffimt8rgiOl6M+ltKi+2mDyI4irav0TkzNkjfbmfXhQyzeg7XhKdkGpw/8tM i1j/eiWW4oxEQy3mouJEAMXG/VW2AgAA Archived-At: Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 13:09:25 -0000 --_000_D3D10138C554christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 >I acknowledge that it=92s not needed with the INFO package, but I think it= does no harm, and makes the entire mechanism consistent with all the other= parts of additional data No, it doesn=92t. We don=92t use the =93by-reference=94 disposition type in= INFO, so there would not be a reference between the Call-Info value and th= e message body. Message bodies associated with info packages have the =93in= fo-package=94 disposition type, and the semantics are covered by the info p= ackage specification. So, the information is useless. Regards, Christer Begin forwarded message: From: Ivo Sedlacek > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Date: August 10, 2016 at 3:32:00 AM EDT To: "Rosen, Brian" = >, Randall Gellens > Hello, In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a delivery= report for the MSD sent in INVITE request. This is NOT information about c= allee. Thus, RFC3261 semantic is not fulfilled. In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be performed a= t the remote UE. This is NOT information about the sender of the INFO reque= st. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicate= d, this is not needed with info package mechanism. Kind regards Ivo -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, August 09, 2016 11:22 PM To: Randall Gellens Cc: Ivo Sedlacek Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) I strongly agree. It=92s small cost and I think a substantial benefit to treat all the blocks= as additional data blocks, put them in the registry, etc. INFO is a solut= ion to a mid-call need to send additional data, and we should treat it that= way in my opinion. We can state that the block reference in the INFO package must match that i= n the Call-Info. Brian On Aug 9, 2016, at 1:22 PM, Randall Gellens > wrote: I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN). I see benefit without any real-world harm i= n using Call-Info even if not strictly necessary (e.g., INFO). --Randy At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: Hello, given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise: Call-Info included in an INVITE request and pointing to the application/eme= rgencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call= -Info in a response to the INVITE request and in an INFO request is removed= . Does this work for everyone? 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: --------------- I hold that the very purpose of existence is to reconcile the glowing opinion we have of ourselves with the terrible things that other people say about us. --Quentin Crisp --_000_D3D10138C554christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7226477116151D4FA6BC9C0412DA7E48@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

=85

>I acknowledge that it=92s not needed with the INFO pack= age, but I think it does no harm, and makes the entire mechanism consistent= with all the other parts of additional data

No, it doesn=92t. We don=92t use the =93by-reference=94 disposition ty= pe in INFO, so there would not be a reference between the Call-Info value a= nd the message body. Message bodies associated with info packages have the = =93info-package=94 disposition type, and the semantics are covered by the info package specification.

So, the information is useless.

Regards,

Christer


Begin forwarded message:

From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Subject: RE: [Ecrit] draft-ietf-ec= rit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-= ecrit-ecall-11- Call-Info usage brings no value)
Date: August 10, 2016 at 3:32:00 AM EDT
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>= , Randall Gellens <rg+ietf@randy.pensive.org>

Hello,

In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a deli= very report for the MSD sent in INVITE request. This is NOT information abo= ut callee. Thus, RFC3261 semantic is not fulfilled.

In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be perform= ed at the remote UE. This is NOT information about the sender of the INFO r= equest. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicated, this is not needed with info p= ackage mechanism.

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [m= ailto:Brian.Rosen@neustar.biz]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value)

I strongly agree.

It=92s small cost and I think a substantial benefit to treat all the blocks= as additional data blocks, put them in the registry, etc.  INFO is a = solution to a mid-call need to send additional data, and we should treat it= that way in my opinion.

We can state that the block reference in the INFO package must match that i= n the Call-Info.

Brian

On Aug 9, 2016, at 1:22 PM, Randall Ge= llens <rg= 3;ietf@randy.pensive.org> wrote:

I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN).  I see benefit without any real-world h= arm in using Call-Info even if not strictly necessary (e.g., INFO).

--Randy

At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote:

Hello,

given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise:

Call-Info i= ncluded in an INVITE request and pointing to the application/emergencyCallD= ata.eCall.MSD+per body of the INVITE request is kept, while Call-Info i= n a response to the INVITE request and in an INFO request is removed.

Does this work for everyone?

Kind regards

Ivo Sedlacek

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal;    facts are suspect;   &nb= sp;I speak for myself only
-------------- Randomly selected tag: --------------- I hold that the
very purpose of existence is to reconcile the glowing opinion we have
of ourselves with the terrible things
that other people say about us.        &= nbsp;      --Quentin Crisp


 --_000_D3D10138C554christerholmbergericssoncom_-- From nobody Wed Aug 10 06:27:32 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 9934B12D16F for ; Wed, 10 Aug 2016 06:27:31 -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 EkvVnpzhReTe for ; Wed, 10 Aug 2016 06:27:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8441F12D0C7 for ; Wed, 10 Aug 2016 06:27:29 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-fa-57ab2bbf618c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 87.4F.04209.FBB2BA75; Wed, 10 Aug 2016 15:27:27 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 15:27:26 +0200 From: Ivo Sedlacek To: "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8wZVUc+d2/8lGEKaLN+jsHn4nqBCLcfg Date: Wed, 10 Aug 2016 13:27:26 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C3E6F@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> In-Reply-To: <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> 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_39B5E4D390E9BD4890E2B31079006101164C3E6FESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdWne/9upwgxPLLSymnbzMbNG46Cmr A5PHkiU/mTx2NDxnDmCK4rJJSc3JLEst0rdL4Mq4Mm85U8GutYwVR9/MZG1gfLOCsYuRk0NC wETiy8lL7CC2kMB6Romnm+q6GLmA7CWMEn9XXQYrYhPQk5i45QgrSEJEoItRYvHjCUwgjrDA MkaJjrcfWCAyyxklTvZuZANpEREwkpi5aDZQCwcHi4CqxI52AZAwr4CvxI4r7WwQK5oYJXY8 bGABSXAK2EvcfHkabB2jgKzE1T+9YDazgLjErSfzmSBuFZBYsuc8M4QtKvHy8T9WCFtJonHJ E1aI+nyJeS+fMUEsE5Q4OfMJywRG4VlIRs1CUjYLSdksoFOZBTQl1u/ShyhRlJjS/ZAdwtaQ aJ0zlx1ZfAEj+ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwDg6uOW36g7Gy28cDzEKcDAq 8fAqSK0KF2JNLCuuzD3EKMHBrCTCW6y5OlyINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAh gfTEktTs1NSC1CKYLBMHp1QDoznLPebnFy4tlAid+tAzIv/HGf4Ql89RJtYTzITv+C7TTbP3 fep6slFw30Gbmpk/H+XuuNy//MMNpUalo2+eCB1m1fz135l32sIY4/yts6r81sYecVd+nSm1 /7XfjNLmTe8rV1w4dc53c4Pfm9gFE+b5XAjI2Fu7pPcD7wextlMrdhe+ydz58pcSS3FGoqEW c1FxIgAVG00EnwIAAA== Archived-At: Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 13:27:31 -0000 --_000_39B5E4D390E9BD4890E2B31079006101164C3E6FESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgYW0gbm90IHBpY2t5IC0gSSBzb2xlbHkgcG9pbnQgb3V0IGEgZGlzY3JlcGFu Y3kgYmV0d2VlbiBSRkMzMjYxIGRlZmluaXRpb24gb2Ygc2VtYW50aWMgb2YgQ2FsbC1JbmZvIGFu ZCBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExIHVzYWdlIG9mIENhbGwtSW5mby4NCg0KSXQgd291 bGQgYmUgYSBkYW5nZXJvdXMgcHJlY2VkZW50IGlmIGEgd29ya2luZyBncm91cCBzdGFydHMgbW9k aWZ5aW5nIHNlbWFudGljIG9mIGhlYWRlciBmaWVsZHMgZGVmaW5lZCBpbiBSRkMzMjYxLg0KDQpJ IHN1Z2dlc3Qgd2UgYnJpbmcgdGhpcyBpc3N1ZSB0byBTSVBDT1JFIHRvIHNldHRsZSB3aGV0aGVy IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEgdXNhZ2Ugb2YgQ2FsbC1JbmZvIGlzIGFsaWduZWQg d2l0aCBSRkMzMjYxIG9yIG5vdC4NCg0KS2luZCByZWdhcmRzDQoNCkl2bw0KDQpGcm9tOiBFY3Jp dCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NlbiwgQnJp YW4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEwLCAyMDE2IDI6NTQgUE0NClRvOiBFbWVyZ2Vu Y3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Np b24gTGlzdA0KU3ViamVjdDogW0Vjcml0XSBGd2Q6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEt IENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSkNCg0K SSBkaWQgbm90IHByb3Blcmx5IGFkZHJlc3MgYSByZXNwb25zZSB0byBJdm8gYW5kIFJhbmR5IHRv IGluY2x1ZGUgdGhlIHdvcmtpbmcgZ3JvdXAsIHNvIEnigJltIGZvcndhcmRpbmcgdGhpcyBwYXJ0 IG9mIHRoZSBkaXNjdXNzaW9uIGJhY2sgdG8gdGhlIGdyb3VwLg0KDQpJIHRoaW5rLCBJdm8sIHRo YXQgeW91IGFyZSBiZWluZyB3YXkgdG9vIHBpY2t5IGFib3V0IHdoZXRoZXIgdGhlIHJlcG9ydCBp cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2FsbGVlIG9yIHRoZSBjb250cm9sIGJvZHkgaXMgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGNhbGxlci4gIEkgdGhpbmsgaXTigJlzIGNsb3NlIGVub3VnaCB0 aGF0IHdlIHNob3VsZCBub3QgdXNlIHRoYXQgYXMgdGhlIHJlYXNvbiB3ZSBkb27igJl0IG1ha2Ug YWxsIG9mIHRoZXNlIGluc3RhbmNlcyBvZiBhZGRpdGlvbmFsIGRhdGEgdW5pZm9ybWx5Lg0KDQpJ IGFja25vd2xlZGdlIHRoYXQgaXTigJlzIG5vdCBuZWVkZWQgd2l0aCB0aGUgSU5GTyBwYWNrYWdl LCBidXQgSSB0aGluayBpdCBkb2VzIG5vIGhhcm0sIGFuZCBtYWtlcyB0aGUgZW50aXJlIG1lY2hh bmlzbSBjb25zaXN0ZW50IHdpdGggYWxsIHRoZSBvdGhlciBwYXJ0cyBvZiBhZGRpdGlvbmFsIGRh dGEsIHdoaWNoIHlvdSBhY2tub3dsZWRnZSB0aGF0IHRoZSBhY3R1YWwgZUNhbGwgZGF0YSBjbGVh cmx5IGlzLg0KDQpCcmlhbg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBJ dm8gU2VkbGFjZWsgPGl2by5zZWRsYWNla0Blcmljc3Nvbi5jb208bWFpbHRvOml2by5zZWRsYWNl a0Blcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogUkU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1l Y2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIG5vdCBhbGlnbmVkIHdpdGggUkZDMzI2MSAod2FzIFJF OiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2UgYnJpbmdzIG5vIHZh bHVlKQ0KRGF0ZTogQXVndXN0IDEwLCAyMDE2IGF0IDM6MzI6MDAgQU0gRURUDQpUbzogIlJvc2Vu LCBCcmlhbiIgPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVz dGFyLmJpej4+LCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8bWFp bHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+Pg0KDQpIZWxsbywNCg0KSW4gdGhlIHJlc3Bv bnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCwgdGhlIENhbGwtSW5mbyBwb2ludHMgdG8gdGhlIGFw cGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wreG1sIGJvZHkuIFRoaXMg Ym9keSBjb250YWlucyBhIGRlbGl2ZXJ5IHJlcG9ydCBmb3IgdGhlIE1TRCBzZW50IGluIElOVklU RSByZXF1ZXN0LiBUaGlzIGlzIE5PVCBpbmZvcm1hdGlvbiBhYm91dCBjYWxsZWUuIFRodXMsIFJG QzMyNjEgc2VtYW50aWMgaXMgbm90IGZ1bGZpbGxlZC4NCg0KSW4gdGhlIElORk8gcmVxdWVzdCwg dGhlIENhbGwtSW5mbyBwb2ludHMgdG8gdGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRh LmVDYWxsLmNvbnRyb2wreG1sIGJvZHkuIFRoaXMgYm9keSBkZXNjcmliZXMgYW4gYWN0aW9uIHRv IGJlIHBlcmZvcm1lZCBhdCB0aGUgcmVtb3RlIFVFLiBUaGlzIGlzIE5PVCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgc2VuZGVyIG9mIHRoZSBJTkZPIHJlcXVlc3QuIFRodXMsIFJGQzMyNjEgc2VtYW50 aWMgaXMgbm90IGZ1bGZpbGxlZC4gQWxzbywgYXMgb3RoZXIgcGVvcGxlIGluZGljYXRlZCwgdGhp cyBpcyBub3QgbmVlZGVkIHdpdGggaW5mbyBwYWNrYWdlIG1lY2hhbmlzbS4NCg0KS2luZCByZWdh cmRzDQoNCkl2bw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9zZW4sIEJy aWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdDQpTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMDksIDIwMTYgMTE6MjIgUE0NClRvOiBSYW5kYWxsIEdlbGxlbnMNCkNjOiBJdm8gU2VkbGFj ZWsNClN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwt SW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1l Y3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSkNCg0KSSBzdHJv bmdseSBhZ3JlZS4NCg0KSXTigJlzIHNtYWxsIGNvc3QgYW5kIEkgdGhpbmsgYSBzdWJzdGFudGlh bCBiZW5lZml0IHRvIHRyZWF0IGFsbCB0aGUgYmxvY2tzIGFzIGFkZGl0aW9uYWwgZGF0YSBibG9j a3MsIHB1dCB0aGVtIGluIHRoZSByZWdpc3RyeSwgZXRjLiAgSU5GTyBpcyBhIHNvbHV0aW9uIHRv IGEgbWlkLWNhbGwgbmVlZCB0byBzZW5kIGFkZGl0aW9uYWwgZGF0YSwgYW5kIHdlIHNob3VsZCB0 cmVhdCBpdCB0aGF0IHdheSBpbiBteSBvcGluaW9uLg0KDQpXZSBjYW4gc3RhdGUgdGhhdCB0aGUg YmxvY2sgcmVmZXJlbmNlIGluIHRoZSBJTkZPIHBhY2thZ2UgbXVzdCBtYXRjaCB0aGF0IGluIHRo ZSBDYWxsLUluZm8uDQoNCkJyaWFuDQoNCg0KT24gQXVnIDksIDIwMTYsIGF0IDE6MjIgUE0sIFJh bmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkBy YW5keS5wZW5zaXZlLm9yZz4+IHdyb3RlOg0KDQpJIHByZWZlciB0byBrZWVwIHRoZSB1c2Ugb2Yg Q2FsbC1JbmZvIGZvciBhbGwgdGhyZWUgY2FzZXMgKElOVklURSwgcmVzcG9uc2UsIElORk8pIHRv IG1haW50YWluIGNvbXBhdGliaWxpdHkgd2l0aCBSRkMgNzg1MiAoQWRkaXRpb25hbCBEYXRhKSBh bmQgY2FyLWNyYXNoIChOb3J0aCBBbWVyaWNhbiBORy1BQUNOKS4gIEkgc2VlIGJlbmVmaXQgd2l0 aG91dCBhbnkgcmVhbC13b3JsZCBoYXJtIGluIHVzaW5nIENhbGwtSW5mbyBldmVuIGlmIG5vdCBz dHJpY3RseSBuZWNlc3NhcnkgKGUuZy4sIElORk8pLg0KDQotLVJhbmR5DQoNCkF0IDI6MjMgUE0g KzAwMDAgOC85LzE2LCBJdm8gU2VkbGFjZWsgd3JvdGU6DQoNCg0KSGVsbG8sDQoNCmdpdmVuIHRo ZSB1c2UgY2FzZSByYWlzZWQgYnkgUm9sYW5kIGFuZCBjbGFyaWZpZWQgYnkgUGF1bCwgbGV0IG1l IHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjb21wcm9taXNlOg0KDQpDYWxsLUluZm8gaW5jbHVkZWQg aW4gYW4gSU5WSVRFIHJlcXVlc3QgYW5kIHBvaW50aW5nIHRvIHRoZSBhcHBsaWNhdGlvbi9lbWVy Z2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QrcGVyIGJvZHkgb2YgdGhlIElOVklURSByZXF1ZXN0IGlz IGtlcHQsIHdoaWxlIENhbGwtSW5mbyBpbiBhIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVz dCBhbmQgaW4gYW4gSU5GTyByZXF1ZXN0IGlzIHJlbW92ZWQuDQoNCkRvZXMgdGhpcyB3b3JrIGZv ciBldmVyeW9uZT8NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0 DQpFY3JpdEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg0KLS0NClJhbmRhbGwgR2VsbGVucw0KT3Bp bmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3Ig bXlzZWxmIG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0t LS0tLS0tLS0tIEkgaG9sZCB0aGF0IHRoZQ0KdmVyeSBwdXJwb3NlIG9mIGV4aXN0ZW5jZSBpcyB0 byByZWNvbmNpbGUgdGhlIGdsb3dpbmcgb3BpbmlvbiB3ZSBoYXZlDQpvZiBvdXJzZWx2ZXMgd2l0 aCB0aGUgdGVycmlibGUgdGhpbmdzDQp0aGF0IG90aGVyIHBlb3BsZSBzYXkgYWJvdXQgdXMuICAg ICAgICAgICAgICAgLS1RdWVudGluIENyaXNwDQoNCg0K --_000_39B5E4D390E9BD4890E2B31079006101164C3E6FESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6Izk4NDgwNjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5 ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij5JIGFtIG5vdCBwaWNr eSAtIEkgc29sZWx5IHBvaW50IG91dCBhIGRpc2NyZXBhbmN5IGJldHdlZW4gUkZDMzI2MSBkZWZp bml0aW9uIG9mIHNlbWFudGljIG9mIENhbGwtSW5mbyBhbmQgZHJhZnQtaWV0Zi1lY3JpdC1lY2Fs bC0xMSB1c2FnZSBvZiBDYWxsLUluZm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij5JdCB3b3VsZCBiZSBhIGRhbmdlcm91 cyBwcmVjZWRlbnQgaWYgYSB3b3JraW5nIGdyb3VwIHN0YXJ0cyBtb2RpZnlpbmcgc2VtYW50aWMg b2YgaGVhZGVyIGZpZWxkcyBkZWZpbmVkIGluIFJGQzMyNjEuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij5JIHN1Z2dlc3Qg d2UgYnJpbmcgdGhpcyBpc3N1ZSB0byBTSVBDT1JFIHRvIHNldHRsZSB3aGV0aGVyIGRyYWZ0LWll dGYtZWNyaXQtZWNhbGwtMTEgdXNhZ2Ugb2YgQ2FsbC1JbmZvIGlzIGFsaWduZWQgd2l0aCBSRkMz MjYxIG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPktpbmQgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj OTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+SXZvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5Sb3NlbiwgQnJpYW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBB dWd1c3QgMTAsIDIwMTYgMjo1NCBQTTxicj4NCjxiPlRvOjwvYj4gRW1lcmdlbmN5IENvbnRleHQg UmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3Q8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW0Vjcml0XSBGd2Q6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEt IENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBub3QgcHJv cGVybHkgYWRkcmVzcyBhIHJlc3BvbnNlIHRvIEl2byBhbmQgUmFuZHkgdG8gaW5jbHVkZSB0aGUg d29ya2luZyBncm91cCwgc28gSeKAmW0gZm9yd2FyZGluZyB0aGlzIHBhcnQgb2YgdGhlIGRpc2N1 c3Npb24gYmFjayB0byB0aGUgZ3JvdXAuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmssIEl2bywgdGhhdCB5b3UgYXJlIGJlaW5nIHdheSB0b28g cGlja3kgYWJvdXQgd2hldGhlciB0aGUgcmVwb3J0IGlzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBj YWxsZWUgb3IgdGhlIGNvbnRyb2wgYm9keSBpcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2FsbGVy LiAmbmJzcDtJIHRoaW5rIGl04oCZcyBjbG9zZSBlbm91Z2ggdGhhdCB3ZSBzaG91bGQgbm90IHVz ZSB0aGF0IGFzIHRoZSByZWFzb24gd2UgZG9u4oCZdCBtYWtlDQogYWxsIG9mIHRoZXNlIGluc3Rh bmNlcyBvZiBhZGRpdGlvbmFsIGRhdGEgdW5pZm9ybWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFja25vd2xlZGdlIHRoYXQgaXTigJlz IG5vdCBuZWVkZWQgd2l0aCB0aGUgSU5GTyBwYWNrYWdlLCBidXQgSSB0aGluayBpdCBkb2VzIG5v IGhhcm0sIGFuZCBtYWtlcyB0aGUgZW50aXJlIG1lY2hhbmlzbSBjb25zaXN0ZW50IHdpdGggYWxs IHRoZSBvdGhlciBwYXJ0cyBvZiBhZGRpdGlvbmFsIGRhdGEsIHdoaWNoIHlvdSBhY2tub3dsZWRn ZSB0aGF0IHRoZSBhY3R1YWwgZUNhbGwgZGF0YSBjbGVhcmx5IGlzLiAmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdp biBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Jdm8g U2VkbGFjZWsgJmx0OzxhIGhyZWY9Im1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tIj5p dm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1Ympl Y3Q6IFJFOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2Fn ZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2Fs bC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSk8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5EYXRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdWd1c3QgMTAsIDIwMTYgYXQg MzozMjowMCBBTSBFRFQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOiA8L3NwYW4+DQo8L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mcXVvdDtSb3NlbiwgQnJpYW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlh bi5Sb3NlbkBuZXVzdGFyLmJpeiI+QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OywgUmFu ZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2 ZS5vcmciPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9hPiZndDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+ DQpJbiB0aGUgcmVzcG9uc2UgdG8gdGhlIElOVklURSByZXF1ZXN0LCB0aGUgQ2FsbC1JbmZvIHBv aW50cyB0byB0aGUgYXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuY29udHJvbCYj NDM7eG1sIGJvZHkuIFRoaXMgYm9keSBjb250YWlucyBhIGRlbGl2ZXJ5IHJlcG9ydCBmb3IgdGhl IE1TRCBzZW50IGluIElOVklURSByZXF1ZXN0LiBUaGlzIGlzIE5PVCBpbmZvcm1hdGlvbiBhYm91 dCBjYWxsZWUuIFRodXMsIFJGQzMyNjEgc2VtYW50aWMgaXMNCiBub3QgZnVsZmlsbGVkLiA8YnI+ DQo8YnI+DQpJbiB0aGUgSU5GTyByZXF1ZXN0LCB0aGUgQ2FsbC1JbmZvIHBvaW50cyB0byB0aGUg YXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuY29udHJvbCYjNDM7eG1sIGJvZHku IFRoaXMgYm9keSBkZXNjcmliZXMgYW4gYWN0aW9uIHRvIGJlIHBlcmZvcm1lZCBhdCB0aGUgcmVt b3RlIFVFLiBUaGlzIGlzIE5PVCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2VuZGVyIG9mIHRoZSBJ TkZPIHJlcXVlc3QuIFRodXMsIFJGQzMyNjEgc2VtYW50aWMgaXMgbm90DQogZnVsZmlsbGVkLiBB bHNvLCBhcyBvdGhlciBwZW9wbGUgaW5kaWNhdGVkLCB0aGlzIGlzIG5vdCBuZWVkZWQgd2l0aCBp bmZvIHBhY2thZ2UgbWVjaGFuaXNtLjxicj4NCjxicj4NCktpbmQgcmVnYXJkczxicj4NCjxicj4N Ckl2bzxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogUm9z ZW4sIEJyaWFuIFs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiPm1haWx0 bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvYT5dDQo8YnI+DQpTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMDksIDIwMTYgMTE6MjIgUE08YnI+DQpUbzogUmFuZGFsbCBHZWxsZW5zPGJyPg0KQ2M6IEl2 byBTZWRsYWNlazxicj4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNh bGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTog ZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1 ZSk8YnI+DQo8YnI+DQpJIHN0cm9uZ2x5IGFncmVlLjxicj4NCjxicj4NCkl04oCZcyBzbWFsbCBj b3N0IGFuZCBJIHRoaW5rIGEgc3Vic3RhbnRpYWwgYmVuZWZpdCB0byB0cmVhdCBhbGwgdGhlIGJs b2NrcyBhcyBhZGRpdGlvbmFsIGRhdGEgYmxvY2tzLCBwdXQgdGhlbSBpbiB0aGUgcmVnaXN0cnks IGV0Yy4gJm5ic3A7SU5GTyBpcyBhIHNvbHV0aW9uIHRvIGEgbWlkLWNhbGwgbmVlZCB0byBzZW5k IGFkZGl0aW9uYWwgZGF0YSwgYW5kIHdlIHNob3VsZCB0cmVhdCBpdCB0aGF0IHdheSBpbiBteSBv cGluaW9uLjxicj4NCjxicj4NCldlIGNhbiBzdGF0ZSB0aGF0IHRoZSBibG9jayByZWZlcmVuY2Ug aW4gdGhlIElORk8gcGFja2FnZSBtdXN0IG1hdGNoIHRoYXQgaW4gdGhlIENhbGwtSW5mby48YnI+ DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gQXVnIDksIDIwMTYsIGF0IDE6MjIgUE0sIFJhbmRhbGwgR2VsbGVucyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnIj5yZyYjNDM7 aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCkkgcHJlZmVy IHRvIGtlZXAgdGhlIHVzZSBvZiBDYWxsLUluZm8gZm9yIGFsbCB0aHJlZSBjYXNlcyAoSU5WSVRF LCByZXNwb25zZSwgSU5GTykgdG8gbWFpbnRhaW4gY29tcGF0aWJpbGl0eSB3aXRoIFJGQyA3ODUy IChBZGRpdGlvbmFsIERhdGEpIGFuZCBjYXItY3Jhc2ggKE5vcnRoIEFtZXJpY2FuIE5HLUFBQ04p LiAmbmJzcDtJIHNlZSBiZW5lZml0IHdpdGhvdXQgYW55IHJlYWwtd29ybGQgaGFybSBpbiB1c2lu ZyBDYWxsLUluZm8gZXZlbiBpZiBub3Qgc3RyaWN0bHkNCiBuZWNlc3NhcnkgKGUuZy4sIElORk8p Ljxicj4NCjxicj4NCi0tUmFuZHk8YnI+DQo8YnI+DQpBdCAyOjIzIFBNICYjNDM7MDAwMCA4Lzkv MTYsIEl2byBTZWRsYWNlayB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxicj4NCjxicj4NCmdpdmVuIHRoZSB1c2UgY2Fz ZSByYWlzZWQgYnkgUm9sYW5kIGFuZCBjbGFyaWZpZWQgYnkgUGF1bCwgbGV0IG1lIHN1Z2dlc3Qg dGhlIGZvbGxvd2luZyBjb21wcm9taXNlOjxicj4NCjxicj4NCkNhbGwtSW5mbyBpbmNsdWRlZCBp biBhbiBJTlZJVEUgcmVxdWVzdCBhbmQgcG9pbnRpbmcgdG8gdGhlIGFwcGxpY2F0aW9uL2VtZXJn ZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCYjNDM7cGVyIGJvZHkgb2YgdGhlIElOVklURSByZXF1ZXN0 IGlzIGtlcHQsIHdoaWxlIENhbGwtSW5mbyBpbiBhIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVx dWVzdCBhbmQgaW4gYW4gSU5GTyByZXF1ZXN0IGlzIHJlbW92ZWQuPGJyPg0KPGJyPg0KRG9lcyB0 aGlzIHdvcmsgZm9yIGV2ZXJ5b25lPzxicj4NCjxicj4NCktpbmQgcmVnYXJkczxicj4NCjxicj4N Ckl2byBTZWRsYWNlazxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOkVjcml0QGlldGYub3JnIj5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS08YnI+DQpSYW5kYWxsIEdlbGxlbnM8YnI+DQpPcGlu aW9ucyBhcmUgcGVyc29uYWw7ICZuYnNwOyZuYnNwOyZuYnNwO2ZhY3RzIGFyZSBzdXNwZWN0OyAm bmJzcDsmbmJzcDsmbmJzcDtJIHNwZWFrIGZvciBteXNlbGYgb25seTxicj4NCi0tLS0tLS0tLS0t LS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tIEkgaG9sZCB0aGF0IHRo ZSA8YnI+DQp2ZXJ5IHB1cnBvc2Ugb2YgZXhpc3RlbmNlIGlzIHRvIHJlY29uY2lsZSB0aGUgZ2xv d2luZyBvcGluaW9uIHdlIGhhdmUgPGJyPg0Kb2Ygb3Vyc2VsdmVzIHdpdGggdGhlIHRlcnJpYmxl IHRoaW5nczxicj4NCnRoYXQgb3RoZXIgcGVvcGxlIHNheSBhYm91dCB1cy4gJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7LS1RdWVudGluIENyaXNwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39B5E4D390E9BD4890E2B31079006101164C3E6FESESSMB301erics_-- From nobody Wed Aug 10 07:43:23 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 430A212D795 for ; Wed, 10 Aug 2016 07:43:21 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 t2dySzQH42oU for ; Wed, 10 Aug 2016 07:43:20 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 63D5C12D781 for ; Wed, 10 Aug 2016 07:43:20 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with SMTP id XUg1bqEXm8PeaXUj1bXdCj; Wed, 10 Aug 2016 14:43:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XUj0b8fXDwELOXUj1b8qDj; Wed, 10 Aug 2016 14:43:19 +0000 To: Ivo Sedlacek , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> Date: Wed, 10 Aug 2016 10:43:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKHKzP25z8g0GZKIrA8+iibeG3vI327PqQt0y5djao3oZV4bZZ1dOf/f4PjMfRkIgCFmswJ9IAcAfIn/B2RFKrz6RCRlVFa0wRDn9EtDJMMnVc9XQmuz viF9sfVtz4csCNkcHLeYI2Pj7hH8yEompLbVIyUMBc7e4XWRXrUJNt9eQ/ug0wCcewmlUSFOwnaShmWVGfKM80T6Slk/ZW16XdueSI9zn9qbvUUvVcTwwJmH Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 14:43:21 -0000 On 8/10/16 3:41 AM, Ivo Sedlacek wrote: > Hello, > >> The invite response still has a body with content-disposition by-reference. If you remove the reference then its processing is undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body; This would "work", and it doesn't seem to violate anything > Alt2: an existing value could be used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body; This would work if there is an existing one with appropriate semantics. There are only a few for which the *sip* semantics are defined. And I don't think any of those fit. There are others (i.e. "render") that on the surface seem like they *might* fit. But their semantics wrt sip are undefined. This would need to be thrashed out. > Alt3: the Content-Disposition header field can be omitted and thus "render" would apply for the application/emergencyCallData.eCall.control+xml body according to RFC3261 section 13.2.1. Same as Alt2 using "render". > We cannot use the Call-Info in INVITE response as described in draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the Call-Info points to the application/emergencyCallData.eCall.control+xml body. This body contains a delivery report for the MSD sent in INVITE request. This is NOT information about callee as described in RFC3261. Using call-info here seems to be at least a small abuse if the intended semantics of call-info. We can perhaps argue if the usage is wrong or the definition of call-info is wrong. The definition of a new c-d appears to be the "cleanest", but it also is going to be viewed by many as overkill to avoid a trivial bending of the usage of call-info. If a new c-d is defined, then presumably it should also be used in the INVITE. Thanks, Paul From nobody Wed Aug 10 08:12: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 D8BE0127078 for ; Wed, 10 Aug 2016 08:12:31 -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 XQqJpEAU7EQa for ; Wed, 10 Aug 2016 08:12:30 -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 705B012D5CA for ; Wed, 10 Aug 2016 08:12:30 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 40033F1A1057A; Wed, 10 Aug 2016 15:12:26 +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 u7AFCSjX018196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 15:12:28 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 u7AFCRmj002103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 17:12:27 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 17:11:49 +0200 From: "Drage, Keith (Nokia - GB)" To: Ivo Sedlacek , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vmkd9B5EE3ZmEqhxtc0HgTuh6A+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAIbZgA== Date: Wed, 10 Aug 2016 15:11:49 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.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-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 15:12:32 -0000 Unless someone is defining a new usage for Call-Info beyond RFC7852 then I = have to agree with Ivo. That additional usage is not currently defined in d= raft-ietf-ecrit-ecall, and I would need to understand that usage before it = is included. At the moment RFC7852 is only used for the transfer of MSD in INVITE reques= ts and 200 (OK) responses, and therefore that is the only place where it sh= ould appear in association with RFC7852. Negotiation and transfer of MSD in association with INFO requests is an ent= irely separate transfer mechanism, not covered by draft-ietf-ecrit-data-onl= y-ea and therefore it should never appear there as though it had been. Incl= usion will lead to complete confusion as to whether the requirements of the= INFO mechanism or the requirements of draft-ietf-ecrit-data-only-ea apply,= when it should be absolutely clear that only the former apply. Regards Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 10 August 2016 08:41 To: Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hello, > The invite response still has a body with content-disposition by-referenc= e. If you remove the reference then its processing is undefined. If the Call-Info is omitted in INVITE response, then: Alt1: a new value could be defined and used in the Content-Disposition head= er field of the application/emergencyCallData.eCall.control+xml body; or Alt2: an existing value could be used in the Content-Disposition header fie= ld of the application/emergencyCallData.eCall.control+xml body; or Alt3: the Content-Disposition header field can be omitted and thus "render"= would apply for the application/emergencyCallData.eCall.control+xml body a= ccording to RFC3261 section 13.2.1. We cannot use the Call-Info in INVITE response as described in draft-ietf-= ecrit-ecall-11 - in the response to the INVITE request, the Call-Info point= s to the application/emergencyCallData.eCall.control+xml body. This body co= ntains a delivery report for the MSD sent in INVITE request. This is NOT in= formation about callee as described in RFC3261.=20 Kind regards Ivo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 10 08:22:19 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 4948C12D5E3 for ; Wed, 10 Aug 2016 08:22:18 -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 ejI4fSXv20uS for ; Wed, 10 Aug 2016 08:22:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8BB4112D737 for ; Wed, 10 Aug 2016 08:22:15 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-db-57ab46a56871 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id D4.AA.02493.5A64BA75; Wed, 10 Aug 2016 17:22:13 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 17:22:12 +0200 From: Christer Holmberg To: "Drage, Keith (Nokia - GB)" , "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8wZVBk2Myc9CREydiCCv8UY8aaBCPIuA///u7oCAADYzAA== Date: Wed, 10 Aug 2016 15:22:12 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> <949EF20990823C4C85C18D59AA11AD8BADF44F1A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF44F1A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D3D12131C5B6christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7hO5St9XhBi/WWlpMO3mZ2aJx0VNW iw1bjrM4MHssWfKTyWNHw3Nmj7u3LjEFMEdx2aSk5mSWpRbp2yVwZayZ84y5YOIsxoqrhzew NzCea2HsYuTkkBAwkZh+/QVbFyMXh5DAekaJxrcHmCGcJYwSrxtWAGU4ONgELCS6/2mDxEUE DjJK/JnRywTiCAssY5RY297CBJFZzihxsncjG8hcEQEniQlb21hBbBYBVYnW+xeYQWxeASuJ 5xd+sUCsaGOS2P/8FNghnAKxEvM2b2MBsRkFxCS+n1rDBGIzC4hL3HoynwniWAGJJXvOM0PY ohIvH/8DWyAqoCfx/etsqLiiRPvTBkaI3niJO9+OsEMsFpQ4OfMJywRGkVlIxs5CUjYLSRlE 3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hKnbqxEUbOAkWMVo2hxanFxbrqRkV5qUWZycXF+ nl5easkmRmA8Htzy22oH48HnjocYBTgYlXh4FaRWhQuxJpYVV+YeYpTgYFYS4V3tujpciDcl sbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA2Ow3XRLpZOK1zcd Oa0gOdvuduXuxc7Gezy2WXf/c1l1o+4oe/3O1y8/rrSSuOCzxznuh1p0g8sb3jeFTFaNHPwa hkzT3H8F8Z/eWSyuHsoVmH9h9xpTo0iFvBzp6RyKV6wfOh096GxlWnUiN8ZTpu7wrdaJks47 RBYz5M5cVOo2dTq35lHeMCWW4oxEQy3mouJEAIA60trDAgAA Archived-At: Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 15:22:18 -0000 --_000_D3D12131C5B6christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >I don=92t believe it is =93useless=94. > >I believe it is dangerous because it introduces an interaction between two= separate protocol mechanisms. Correct, and I earlier said that we=92d have to define what happens if ther= e e.g. is a missmatch between the mechanisms. What I meant by =93useless=94 is that since the content disposition type of= the INFO message bodies are =93info package=94, there is no reference to t= he Call-Info header fields =96 the semantics must be defined in the info pa= ckage description. Regards, Christer From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 10 August 2016 14:09 To: Rosen, Brian; Emergency Context Resolution with Internet Technologies D= iscussion List Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not al= igned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brin= gs no value) Hi, =85 >I acknowledge that it=92s not needed with the INFO package, but I think it= does no harm, and makes the entire mechanism consistent with all the other= parts of additional data No, it doesn=92t. We don=92t use the =93by-reference=94 disposition type in= INFO, so there would not be a reference between the Call-Info value and th= e message body. Message bodies associated with info packages have the =93in= fo-package=94 disposition type, and the semantics are covered by the info p= ackage specification. So, the information is useless. Regards, Christer Begin forwarded message: From: Ivo Sedlacek > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Date: August 10, 2016 at 3:32:00 AM EDT To: "Rosen, Brian" = >, Randall Gellens > Hello, In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a delivery= report for the MSD sent in INVITE request. This is NOT information about c= allee. Thus, RFC3261 semantic is not fulfilled. In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be performed a= t the remote UE. This is NOT information about the sender of the INFO reque= st. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicate= d, this is not needed with info package mechanism. Kind regards Ivo -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, August 09, 2016 11:22 PM To: Randall Gellens Cc: Ivo Sedlacek Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) I strongly agree. It=92s small cost and I think a substantial benefit to treat all the blocks= as additional data blocks, put them in the registry, etc. INFO is a solut= ion to a mid-call need to send additional data, and we should treat it that= way in my opinion. We can state that the block reference in the INFO package must match that i= n the Call-Info. Brian On Aug 9, 2016, at 1:22 PM, Randall Gellens > wrote: I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN). I see benefit without any real-world harm i= n using Call-Info even if not strictly necessary (e.g., INFO). --Randy At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: Hello, given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise: Call-Info included in an INVITE request and pointing to the application/eme= rgencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call= -Info in a response to the INVITE request and in an INFO request is removed= . Does this work for everyone? 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: --------------- I hold that the very purpose of existence is to reconcile the glowing opinion we have of ourselves with the terrible things that other people say about us. --Quentin Crisp --_000_D3D12131C5B6christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0596DD07A1D00347BEF3F7483D6FB469@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>I don=92t believe it is =93usel= ess=94.

>

>I believe it is dangerous becau= se it introduces an interaction between two separate protocol mechanisms.

Correct, and I earlier said that we=92d have to define what happens if= there e.g. is a missmatch between the mechanisms.

What I meant by =93useless=94 is that since the content disposition ty= pe of the INFO message bodies are =93info package=94, there is no reference= to the Call-Info header fields =96 the semantics must be defined in the in= fo package description.

Regards,

Christer


 

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 August 2016 14:09
To: Rosen, Brian; Emergency Context Resolution with Internet Technol= ogies Discussion List
Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage= not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usa= ge brings no value)

 

Hi,

 

=85

 

>I acknowledge that it=92s not needed wit= h the INFO package, but I think it does no harm, and makes the entire mecha= nism consistent with all the other parts of additional data

 

No, it doesn=92t. We don=92t use the =93by-r= eference=94 disposition type in INFO, so there would not be a reference bet= ween the Call-Info value and the message body. Message bodies associated with info packages have the =93info-package=94 d= isposition type, and the semantics are covered by the info package specific= ation.

 

So, the information is useless.

 

Regards,

 

Christer

 

 

Begin forwarded message:

 

From: Ivo Sedlacek <ivo.sedlacek@ericsson.com><= /p>

Subject: RE: [Ecrit] draft-ietf-ecrit-e= call-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit= -ecall-11- Call-Info usage brings no value)

Date: August 10, 2016 at 3:32:00 AM EDT<= /o:p>

To: "Rosen, Brian" <Brian.Rosen@neustar.biz>, Randall Gellens <rg+ietf@randy.pensive.org<= /a>>

 

Hello,

In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a deli= very report for the MSD sent in INVITE request. This is NOT information abo= ut callee. Thus, RFC3261 semantic is not fulfilled.

In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be perform= ed at the remote UE. This is NOT information about the sender of the INFO r= equest. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicated, this is not needed with info p= ackage mechanism.

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:Brian= .Rosen@neustar.biz]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value)

I strongly agree.

It=92s small cost and I think a substantial benefit to treat all the blocks= as additional data blocks, put them in the registry, etc.  INFO is a = solution to a mid-call need to send additional data, and we should treat it= that way in my opinion.

We can state that the block reference in the INFO package must match that i= n the Call-Info.

Brian


On Aug 9, 2016, at 1:22 PM, Randall Gellens = <rg+ietf@randy.pens= ive.org> wrote:

I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN).  I see benefit without any real-world h= arm in using Call-Info even if not strictly necessary (e.g., INFO).

--Randy

At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote:


Hello,

given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise:

Call-Info included in an INVITE request and pointing to the application/eme= rgencyCallData.eCall.MSD+per body of the INVITE request is kept, while = Call-Info in a response to the INVITE request and in an INFO request is rem= oved.

Does this work for everyone?

Kind regards

Ivo Sedlacek

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit



--
Randall Gellens
Opinions are personal;    facts are suspect;   &nb= sp;I speak for myself only
-------------- Randomly selected tag: --------------- I hold that the
very purpose of existence is to reconcile the glowing opinion we have
of ourselves with the terrible things
that other people say about us.        &= nbsp;      --Quentin Crisp<= /p>

 

 

 --_000_D3D12131C5B6christerholmbergericssoncom_-- From nobody Wed Aug 10 08:23: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 9379112D781 for ; Wed, 10 Aug 2016 08:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.881 X-Spam-Level: X-Spam-Status: No, score=-6.881 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, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 dgv5thfdYDa0 for ; Wed, 10 Aug 2016 08:23:20 -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 955DA12D1B7 for ; Wed, 10 Aug 2016 08:23:19 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3A2D2A8AE2F54; Wed, 10 Aug 2016 15:12:36 +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 u7AFCcta024554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 15:12:38 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 u7AFCaXu015823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 17:12:38 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 17:11:51 +0200 From: "Drage, Keith (Nokia - GB)" To: "R.Jesske@telekom.de" , "ivo.sedlacek@ericsson.com" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vmkd9B5EE3ZmEqhxtc0HgTuh6BCOgLQ Date: Wed, 10 Aug 2016 15:11:51 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF44F13@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF44F13FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 15:23:23 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF44F13FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I fundamentally disagree. We have two different data transfer mechanisms, a= nd the presence of the data should be clearly understood from the appropria= te transfer mechanism protocol. So Call-Info applies when RFC 7852 applies, which is the INVITE and 200 (OK= ) response, and does not when the INFO mechanism is in use. Additionally it only applies when it is pointing to data which is actually = attached to the message. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.d= e Sent: 08 August 2016 10:45 To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Ivo, using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly m= eans using the MSD within the Body. It could be also an interworked call wh= ere all ecall information is included inband using the In-band modem soluti= on. We have to think also on backwards compatibility issues. Thus when moving = PSAP's to SIP imply also that there must exist an interworking between the = old mobile world towards the new mobile world using SIP. Using the Call-Info header would help the PAST to distinguish the in-band a= nd outband solution. Perhaps it would be worth to define an additional valu= e for inband data, to identify ecalls coming from other networks not suppor= ting the MSD Body. Best Regards Roland. Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Montag, 8. August 2016 09:59 An: Paul Kyzivat; ecrit@ietf.org Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wit= h RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no val= ue) Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional "/> --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_949EF20990823C4C85C18D59AA11AD8BADF44F13FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I fundamentally disagr= ee. We have two different data transfer mechanisms, and the presence of the= data should be clearly understood from the appropriate transfer mechanism = protocol.


So Call-Info applies when RFC 7852 applies, which is the INVITE and 200 (OK= ) response, and does not when the INFO mechanism is in use.

 

Additionally it only a= pplies when it is pointing to data which is actually attached to the messag= e.

 

Keith

 

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
Sent: 08 August 2016 10:45
To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org=
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage br= ings no value)

 

Hi Ivo,

using the ecall urn (urn:service:sos.ecall.automatic) does n=
ot implicitly means using the MSD within the Body. It could be also an inte=
rworked call where all ecall information is included inband using the In-ba=
nd modem solution.
 
We have to think also on backwards compatibility issues. &nb=
sp;Thus when moving PSAP’s to SIP imply also that there must exist an=
 interworking between the old mobile world towards the new mobile world usi=
ng SIP.
 
Using the Call-Info header would help the PAST to distinguis=
h the in-band and outband solution. Perhaps it would be worth to define an =
additional value for inband data, to identify ecalls coming from other netw=
orks not supporting the MSD Body.
 
Best Regards

Roland.

 = ;

 = ;

Von: Ecrit [mailto:ecri= t-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; ecrit@ietf= .org
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not alig= ned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings= no value)

 

Hello,

 

According to RFC3261, the Call-Info header field = provides additional information about the caller or callee.

 

According to draft-ietf-ecrit-ecall-11, the Call-= Info header field is used to form a "content-table" of pointers t= o bodies INVITE request (and of INVITE response, of INFO request) in header= s of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header field points to a body wh= ich describes the callers or callee, then Call-Info semantic fits (even tho= ugh I would still question usefulness of such Call-Info inclusion).

 

If the Call-Info header field points to a body wh= ich request an action in remote UE and which reports to remote UE an outcom= e of an action done by the local UE, then Call-Info semantic does not fit.<= o:p>

 

Particularly:

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

   A PSAP or IVS transmits a metadata/c= ontrol object (see Section 9) by

   encoding it per the description in t= his document and attaching it to

   a SIP message as a MIME body part pe= r [RFC7852].  The body part is

   identified by its MIME content-type = ('application/

   emergencyCallData.eCall.control+= xml') in the Content-Type header

   field of the body part.  The bo= dy part is assigned a unique

   identifier which is listed in a Cont= ent-ID header field in the body

   part.  The SIP message is marke= d as containing the metadata/control

   object by adding (or appending to) a= Call-Info header field at the

   top level of the SIP message.  = This Call-Info header field contains a

   CID URL referencing the body part's unique identifier, a= nd a

   'purpose' parameter identifying the data as an eCall met= adata/control

   block per the Emergency Call Additional Data Blocks regi= stry entry;

   the 'purpose' parameter's value is 'emergencyCallData.eC= all.control'.

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

and

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

SIP/2.0 200 OK

      To: <sip:+13145551111@example.com>= ;tag=3D9fxced76sl

      From: Exemplar PSA= P <urn:service:sos.ecall.automatic>

      Call-ID: 3848276298220188511@atlanta.example.com

      Call-Info: cid:2345678901@at= lanta.example.com;

           &nb= sp;     purpose=3DemergencyCallData.eCall.control;

      Accept: applicatio= n/sdp, application/pidf+xml,

        &= nbsp;     application/emergencyCallData.eCall.control&#= 43;xml,

        &= nbsp;     application/emergencyCallData.eCall.MSD+p= er

      CSeq: 31862 INVITE=

      Recv-Info: emergen= cyCallData.eCall.MSD

      Allow: INVITE, ACK= , PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,

        &= nbsp;    SUBSCRIBE, NOTIFY, UPDATE

      Content-Type: mult= ipart/mixed; boundary=3DboundaryX

      Content-Length: ..= .

 

      --boundaryX

      Content-Type: appl= ication/sdp

 

        &= nbsp;  ...Session Description Protocol (SDP) goes here...

 

      --boundaryX

      Content-Type: appl= ication/EmergencyCallData.eCall.control+xml

      Content-ID: 2345678901@at= lanta.example.com

      Content-Dispositio= n: by-reference;handling=3Doptional

 

      <?xml version= =3D"1.0" encoding=3D"UTF-8"?>

      <EmergencyCallD= ata.eCall.Control

        &= nbsp; xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control&= quot;

        &= nbsp; xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

        &= nbsp; xsi:schemaLocation=3D

        &= nbsp;     "urn:ietf:params:xml:ns:EmergencyCallDat= a:eCall:control">

 

      <ack received=3D"true" ref=3D"1234567890@atlanta.example.com"/>=

 

      </EmergencyCall= Data.eCall.Control>

 

      --boundaryX--=

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

 

Kind regards

 

Ivo

 

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces= @ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that the Call-Info that refe= rs to the body is unnecessary because the recipient will know what to do wi= th the body even in the absence of the Call-Info. Is that right?=

 

This assumption mixes up two things:

- understanding a body syntactically

- understanding *why* the body is present and how= it should be used.

 

Historically, processing of body parts in sip was= very poorly defined.

Initially the only body of interest was SDP, so h= ow one might process other bodies or body parts was not well considered. Ev= entually this started to be a liability, so RFC5621 was published to clarif= y it.

 

Processing of body parts is governed by a complex= interaction between Content-Type, Content-Disposition, Content-ID.

 

So the call-info header indicates the reason that= body is being included. I realize that there is one predominant reason for= doing so, but that is not the only possible reason. (E.g., it might be inc= luded as context in an intended discussion about problems handling a call in the

past.)

 

If all the handling of the call is coded in a spe= cial purpose way, solely for the emergency call path, then alternatives may= be of no concern. But ideally the call will largely be handled via standar= d library code that is also used for other call paths and other message processing. So processing body parts in= a "standard" way, rather than special casing, is desirable.=

 

        &= nbsp;       Thanks,

        &= nbsp;       Paul

 

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:=

> Hello,

> 

> 

> 

> COMMENT:

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Inclusion of Call-Info header field with

> purpose=3DemergencyCallData.eCall.MSD or

> purpose=3DemergencyCallData.eCall.control in= requests and responses does

> not seem to bring any value. It seems to onl= y waste radio resources.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.MSD included in the

> initial INVITE request:

> 

> - if this is meant to be used by a proxy for= routing of the eCall

> emergency call to a PSAP supporting eCall em= ergency call, then this

> seems to be redundant to the eCall URN inclu= ded in the Request-URI and

> the Recv-Info header field containing eCall = specific info package

> (emergencyCallData.eCall.MSD).

> 

> - if this is meant to be used by UAS (i.e. P= SAP), then according to

> RFC3261 subclause 8.2.3, then the UAS anyway= needs to check that all

> the bodies of the INVITE request not marked = with Content-Disposition:

> ...; handling=3Doptional are understood. So,=

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INVITE request proce= ssing.

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> a response to the initial INVITE request

> 

> - no routing decisions are done by proxies w= hen receiving a response

> to the initial INVITE request so this does n= ot seem to have any value

> for the proxies

> 

> - UAC includes Accept with supported MIME ty= pes in INVITE request so

> why would UAS send any MIME body not wished = by the UAC?

> 

> 

> 

> For Call-Info with purpose=3DemergencyCallDa= ta.eCall.control included in

> the INFO request

> 

> - no routing decisions are done by proxies w= hen receiving an in-dialog

> request so this does not seem to have any va= lue for the proxies

> 

> - support of info package emergencyCallData.= eCall.MSD in the call

> implies that either application/EmergencyCal= lData.eCall.control+xml

> MIME body or application/emergencyCallData.e= Call.MSD+per MIME body is

> included. Again, according to RFC3261 subcla= use 8.2.3, the UAS anyway

> needs to check that all the bodies of the IN= FO request not marked with

> Content-Disposition: ...; handling=3Doptiona= l are understood. So,

> application/EmergencyCallData.eCall.control&= #43;xml MIME body or

> application/emergencyCallData.eCall.MSD+= per MIME body will anyway be

> found by UAS during the INFO request process= ing.

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> PROPOSED SOLUTION to COMMENT

> 

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> 

> Remove insertion of Call-Info header field.<= o:p>

> 

> ////////////////////////////////////////////= //////////////////////////

> ////////

> 

> 

> 

> Kind regards

> 

> 

> 

> Ivo Sedlacek

> 

> 

> 

> ____________________________________________= ___

> Ecrit mailing list

> Ecrit@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/ecrit

> 

 

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org=

https://www.ie= tf.org/mailman/listinfo/ecrit

--_000_949EF20990823C4C85C18D59AA11AD8BADF44F13FR712WXCHMBA11z_-- From nobody Wed Aug 10 08:24:23 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 51BAF12D795 for ; Wed, 10 Aug 2016 08:24:22 -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 64z5tXn4e0pr for ; Wed, 10 Aug 2016 08:24:20 -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 9F9DF12D0B4 for ; Wed, 10 Aug 2016 08:24:19 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 51816605C1A7F; Wed, 10 Aug 2016 15:12:26 +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 u7AFCShs018198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 15:12:28 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 u7AFCRml002103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 17:12:28 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 17:11:53 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8wZH9cp2nZ4HkkC6msHXdRFV4KBCCTuAgAAwkSA= Date: Wed, 10 Aug 2016 15:11:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF44F1A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF44F1AFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 15:24:22 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF44F1AFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't believe it is "useless". I believe it is dangerous because it introduces an interaction between two = separate protocol mechanisms. (This is not precluding the use for other purposes for Call-Info, but those= purposes need to be made clear, and in accordance with RFCs) Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 10 August 2016 14:09 To: Rosen, Brian; Emergency Context Resolution with Internet Technologies D= iscussion List Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not al= igned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brin= gs no value) Hi, ... >I acknowledge that it's not needed with the INFO package, but I think it d= oes no harm, and makes the entire mechanism consistent with all the other p= arts of additional data No, it doesn't. We don't use the "by-reference" disposition type in INFO, s= o there would not be a reference between the Call-Info value and the messag= e body. Message bodies associated with info packages have the "info-package= " disposition type, and the semantics are covered by the info package speci= fication. So, the information is useless. Regards, Christer Begin forwarded message: From: Ivo Sedlacek > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Date: August 10, 2016 at 3:32:00 AM EDT To: "Rosen, Brian" = >, Randall Gellens > Hello, In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a delivery= report for the MSD sent in INVITE request. This is NOT information about c= allee. Thus, RFC3261 semantic is not fulfilled. In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be performed a= t the remote UE. This is NOT information about the sender of the INFO reque= st. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicate= d, this is not needed with info package mechanism. Kind regards Ivo -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, August 09, 2016 11:22 PM To: Randall Gellens Cc: Ivo Sedlacek Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) I strongly agree. It's small cost and I think a substantial benefit to treat all the blocks a= s additional data blocks, put them in the registry, etc. INFO is a solutio= n to a mid-call need to send additional data, and we should treat it that w= ay in my opinion. We can state that the block reference in the INFO package must match that i= n the Call-Info. Brian On Aug 9, 2016, at 1:22 PM, Randall Gellens > wrote: I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN). I see benefit without any real-world harm i= n using Call-Info even if not strictly necessary (e.g., INFO). --Randy At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: Hello, given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise: Call-Info included in an INVITE request and pointing to the application/eme= rgencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call= -Info in a response to the INVITE request and in an INFO request is removed= . Does this work for everyone? 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: --------------- I hold that the very purpose of existence is to reconcile the glowing opinion we have of ourselves with the terrible things that other people say about us. --Quentin Crisp --_000_949EF20990823C4C85C18D59AA11AD8BADF44F1AFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t believe it = is “useless”.

 <= /p>

I believe it is dangerous= because it introduces an interaction between two separate protocol mechani= sms.

 <= /p>

(This is not precluding t= he use for other purposes for Call-Info, but those purposes need to be made= clear, and in accordance with RFCs)

 <= /p>

Keith

 <= /p>

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 August 2016 14:09
To: Rosen, Brian; Emergency Context Resolution with Internet Technol= ogies Discussion List
Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage= not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usa= ge brings no value)

 

Hi,

 

…

 

>I acknowledge that it&#= 8217;s not needed with the INFO package, but I think it does no harm, and m= akes the entire mechanism consistent with all the other parts of additional data

 

No, it doesn’t. We do= n’t use the “by-reference” disposition type in INFO, so t= here would not be a reference between the Call-Info value and the message b= ody. Message bodies associated with info packages have the “info-package&= #8221; disposition type, and the semantics are covered by the info package = specification.

 

So, the information is usel= ess.

 

Regards,<= /p>

 

Christer<= /p>

 

 

Begin forwarded message:

 

From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>

Subject: RE: [Ecrit] d= raft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE:= draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Date: August 10, 2016 at 3:32:00 AM EDT

To: "Rosen, Brian" <Brian.Rosen@neustar.biz>, Randal= l Gellens <rg+ietf@= randy.pensive.org>=

 

Hello,

In the response to the INVITE request, the Call-Info points to the applicat= ion/emergencyCallData.eCall.control+xml body. This body contains a deli= very report for the MSD sent in INVITE request. This is NOT information abo= ut callee. Thus, RFC3261 semantic is not fulfilled.

In the INFO request, the Call-Info points to the application/emergencyCallD= ata.eCall.control+xml body. This body describes an action to be perform= ed at the remote UE. This is NOT information about the sender of the INFO r= equest. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicated, this is not needed with info p= ackage mechanism.

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:Brian= .Rosen@neustar.biz]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value)

I strongly agree.

It’s small cost and I think a substantial benefit to treat all the bl= ocks as additional data blocks, put them in the registry, etc.  INFO i= s a solution to a mid-call need to send additional data, and we should trea= t it that way in my opinion.

We can state that the block reference in the INFO package must match that i= n the Call-Info.

Brian


On Aug 9, 2016, at 1:22 PM,= Randall Gellens <rg= 3;ietf@randy.pensive.org> wrote:

I prefer to keep the use of Call-Info for all three cases (INVITE, response= , INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-c= rash (North American NG-AACN).  I see benefit without any real-world h= arm in using Call-Info even if not strictly necessary (e.g., INFO).

--Randy

At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote:


Hello,

given the use case raised by Roland and clarified by Paul, let me suggest t= he following compromise:

Call-Info included in an INVITE request and pointing to the application/eme= rgencyCallData.eCall.MSD+per body of the INVITE request is kept, while = Call-Info in a response to the INVITE request and in an INFO request is rem= oved.

Does this work for everyone?

Kind regards

Ivo Sedlacek

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit



--
Randall Gellens
Opinions are personal;    facts are suspect;   &nb= sp;I speak for myself only
-------------- Randomly selected tag: --------------- I hold that the
very purpose of existence is to reconcile the glowing opinion we have
of ourselves with the terrible things
that other people say about us.        &= nbsp;      --Quentin Crisp<= /p>

 

 

--_000_949EF20990823C4C85C18D59AA11AD8BADF44F1AFR712WXCHMBA11z_-- From nobody Wed Aug 10 10:13: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 1B7FB12D12B for ; Wed, 10 Aug 2016 10:12:58 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 UjtgacdEvj7I for ; Wed, 10 Aug 2016 10:12:57 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0833E12D0DB for ; Wed, 10 Aug 2016 10:12:56 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 10:12:55 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 10:12:52 -0700 To: Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:12:59 -0000 At 7:41 AM +0000 8/10/16, Ivo Sedlacek wrote: > Hello, > >> The invite response still has a body with content-disposition >> by-reference. If you remove the reference then its processing is >> undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the > Content-Disposition header field of the > application/emergencyCallData.eCall.control+xml body; > or > Alt2: an existing value could be used in the Content-Disposition > header field of the application/emergencyCallData.eCall.control+xml > body; > or > Alt3: the Content-Disposition header field can be omitted and thus > "render" would apply for the > application/emergencyCallData.eCall.control+xml body according to > RFC3261 section 13.2.1. > > We cannot use the Call-Info in INVITE response as described in > draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, > the Call-Info points to the > application/emergencyCallData.eCall.control+xml body. This body > contains a delivery report for the MSD sent in INVITE request. This > is NOT information about callee as described in RFC3261. Hi Ivo, Call-Info is used in accordance with RFC 7852. --Randy > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- History has the relation to truth that theology has to religion -- i.e., none to speak of. --Lazarus Long From nobody Wed Aug 10 10:17:23 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 E198412D610 for ; Wed, 10 Aug 2016 10:17:21 -0700 (PDT) X-Quarantine-ID: <5c_l_AvM5xeI> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 5c_l_AvM5xeI for ; Wed, 10 Aug 2016 10:17:20 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0312B032 for ; Wed, 10 Aug 2016 10:17:20 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 10:17:20 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 10:17:16 -0700 To: Paul Kyzivat , 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] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:17:22 -0000 At 10:43 AM -0400 8/10/16, Paul Kyzivat wrote: > On 8/10/16 3:41 AM, Ivo Sedlacek wrote: >> Hello, >> >>> The invite response still has a body with content-disposition >>> by-reference. If you remove the reference then its processing is >>> undefined. >> >> If the Call-Info is omitted in INVITE response, then: >> Alt1: a new value could be defined and used in the >> Content-Disposition header field of the >> application/emergencyCallData.eCall.control+xml body; > > This would "work", and it doesn't seem to violate anything > >> Alt2: an existing value could be used in the Content-Disposition >> header field of the >> application/emergencyCallData.eCall.control+xml body; > > This would work if there is an existing one with appropriate semantics. > There are only a few for which the *sip* semantics are defined. And > I don't think any of those fit. > > There are others (i.e. "render") that on the surface seem like they > *might* fit. But their semantics wrt sip are undefined. This would > need to be thrashed out. > >> Alt3: the Content-Disposition header field can be omitted and thus >> "render" would apply for the >> application/emergencyCallData.eCall.control+xml body according to >> RFC3261 section 13.2.1. > > Same as Alt2 using "render". > >> We cannot use the Call-Info in INVITE response as described in >> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, >> the Call-Info points to the >> application/emergencyCallData.eCall.control+xml body. This body >> contains a delivery report for the MSD sent in INVITE request. >> This is NOT information about callee as described in RFC3261. > > Using call-info here seems to be at least a small abuse if the > intended semantics of call-info. We can perhaps argue if the usage > is wrong or the definition of call-info is wrong. Use of Call-Info to identify emergency data blocks is defined in RFC 7852. > > The definition of a new c-d appears to be the "cleanest", but it > also is going to be viewed by many as overkill to avoid a trivial > bending of the usage of call-info. > > If a new c-d is defined, then presumably it should also be used in > the INVITE. > > Thanks, > Paul > > _______________________________________________ > 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: --------------- Computer Science: solving today's problems tomorrow. From nobody Wed Aug 10 10:19:36 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 8DBBD12D624 for ; Wed, 10 Aug 2016 10:19: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 w04MJvAzJy0s for ; Wed, 10 Aug 2016 10:19: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 9AC6312D58A for ; Wed, 10 Aug 2016 10:19:32 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id E21BF52F2CFDD; Wed, 10 Aug 2016 17:19:27 +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 u7AHJUWV017886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 17:19:30 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 u7AHJT4k031482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 19:19:29 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 19:19:29 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Ivo Sedlacek , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8yptd9B5EE3ZmEqhxtc0HgTuh6BCbyQw Date: Wed, 10 Aug 2016 17:19:28 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF45100@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:19:34 -0000 Is this response only in respect of the INVITE / 200 (OK) inclusion? Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 10 August 2016 18:13 To: Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) At 7:41 AM +0000 8/10/16, Ivo Sedlacek wrote: > Hello, > >> The invite response still has a body with content-disposition=20 >> by-reference. If you remove the reference then its processing is=20 >> undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the=20 > Content-Disposition header field of the=20 > application/emergencyCallData.eCall.control+xml body; > or > Alt2: an existing value could be used in the Content-Disposition=20 > header field of the application/emergencyCallData.eCall.control+xml > body; > or > Alt3: the Content-Disposition header field can be omitted and thus=20 > "render" would apply for the=20 > application/emergencyCallData.eCall.control+xml body according to > RFC3261 section 13.2.1. > > We cannot use the Call-Info in INVITE response as described in > draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the=20 > Call-Info points to the=20 > application/emergencyCallData.eCall.control+xml body. This body=20 > contains a delivery report for the MSD sent in INVITE request. This is=20 > NOT information about callee as described in RFC3261. Hi Ivo, Call-Info is used in accordance with RFC 7852. --Randy > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- History has the relat= ion to truth that theology has to religion -- i.e., none to speak of. --Lazarus Long _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 10 10:20:02 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 5E40512D7CA for ; Wed, 10 Aug 2016 10:20: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Vsf4PF45o9S4 for ; Wed, 10 Aug 2016 10:19:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B6FFD12D63B for ; Wed, 10 Aug 2016 10:19:59 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 10:19:59 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 10:19:55 -0700 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:20:01 -0000 Hi Keith, At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > Unless someone is defining a new usage for Call-Info beyond RFC7852 > then I have to agree with Ivo. That additional usage is not > currently defined in draft-ietf-ecrit-ecall, and I would need to > understand that usage before it is included. > > At the moment RFC7852 is only used for the transfer of MSD in > INVITE requests and 200 (OK) responses, and therefore that is the > only place where it should appear in association with RFC7852. RFC 7852 covers use of Call-Info to point to emergency call data blocks in any SIP message that is permitted to carry a body. > > Negotiation and transfer of MSD in association with INFO requests > is an entirely separate transfer mechanism, not covered by > draft-ietf-ecrit-data-only-ea and therefore it should never appear > there as though it had been. Inclusion will lead to complete > confusion as to whether the requirements of the INFO mechanism or > the requirements of draft-ietf-ecrit-data-only-ea apply, when it > should be absolutely clear that only the former apply. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 10 August 2016 08:41 > To: Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hello, > >> The invite response still has a body with content-disposition >> by-reference. If you remove the reference then its processing is >> undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the > Content-Disposition header field of the > application/emergencyCallData.eCall.control+xml body; > or > Alt2: an existing value could be used in the Content-Disposition > header field of the application/emergencyCallData.eCall.control+xml > body; > or > Alt3: the Content-Disposition header field can be omitted and thus > "render" would apply for the > application/emergencyCallData.eCall.control+xml body according to > RFC3261 section 13.2.1. > > We cannot use the Call-Info in INVITE response as described in > draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, > the Call-Info points to the > application/emergencyCallData.eCall.control+xml body. This body > contains a delivery report for the MSD sent in INVITE request. This > is NOT information about callee as described in RFC3261. > > Kind regards > > Ivo > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The idea that Bill Gates has appeared like a knight in shining armor to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. --Douglas Adams From nobody Wed Aug 10 10:30: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 6F11612D828 for ; Wed, 10 Aug 2016 10:30:22 -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 iZK0wocUQXFK for ; Wed, 10 Aug 2016 10:30:20 -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 4CF4E12D827 for ; Wed, 10 Aug 2016 10:30:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A86C4935A11B8; Wed, 10 Aug 2016 17:30:15 +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 u7AHUHbe014991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 17:30:18 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 u7AHRw3W018113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 19:30:17 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 19:29:28 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Ivo Sedlacek , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8yt5NlZovG1drEGrJAa3FjjZUaBCchNw Date: Wed, 10 Aug 2016 17:29:27 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@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] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:30:22 -0000 I disagree. The inclusion of the data element in INFO is nothing to do with RFC 7852. T= he data element is included because the use of an appropriate Info package = has been negotiated and used. That Info package definition and the INFO mec= hanism itself makes no mention of use of Call-Info in association with it.= =20 Further I see no justification for complicating any error handling by sudde= nly defining it to be applicable, as it is not necessary. INFO requests alw= ays contain a data element appropriate to the Info package that is defined = for its use - it absolutely does not need a secondary reference to the pack= age. Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 10 August 2016 18:20 To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Keith, At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > Unless someone is defining a new usage for Call-Info beyond RFC7852=20 > then I have to agree with Ivo. That additional usage is not currently=20 > defined in draft-ietf-ecrit-ecall, and I would need to understand that=20 > usage before it is included. > > At the moment RFC7852 is only used for the transfer of MSD in INVITE=20 > requests and 200 (OK) responses, and therefore that is the only place=20 > where it should appear in association with RFC7852. RFC 7852 covers use of Call-Info to point to emergency call data blocks in = any SIP message that is permitted to carry a body. > > Negotiation and transfer of MSD in association with INFO requests is=20 > an entirely separate transfer mechanism, not covered by=20 > draft-ietf-ecrit-data-only-ea and therefore it should never appear=20 > there as though it had been. Inclusion will lead to complete confusion=20 > as to whether the requirements of the INFO mechanism or the=20 > requirements of draft-ietf-ecrit-data-only-ea apply, when it should be=20 > absolutely clear that only the former apply. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 10 August 2016 08:41 > To: Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > Hello, > >> The invite response still has a body with content-disposition=20 >> by-reference. If you remove the reference then its processing is=20 >> undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the=20 > Content-Disposition header field of the=20 > application/emergencyCallData.eCall.control+xml body; > or > Alt2: an existing value could be used in the Content-Disposition=20 > header field of the application/emergencyCallData.eCall.control+xml > body; > or > Alt3: the Content-Disposition header field can be omitted and thus=20 > "render" would apply for the=20 > application/emergencyCallData.eCall.control+xml body according to > RFC3261 section 13.2.1. > > We cannot use the Call-Info in INVITE response as described in > draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the=20 > Call-Info points to the=20 > application/emergencyCallData.eCall.control+xml body. This body=20 > contains a delivery report for the MSD sent in INVITE request. This is=20 > NOT information about callee as described in RFC3261. > > Kind regards > > Ivo > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The idea that Bill Ga= tes has appeared like a knight in shining armor to lead all customers out o= f a mire of technological chaos neatly ignores the fact that it was he who,= by peddling second-rate technology, led them into it in the first place. --Douglas Adams From nobody Wed Aug 10 10:45: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 F377712D66C for ; Wed, 10 Aug 2016 10:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Uixlej7oCk2N for ; Wed, 10 Aug 2016 10:45:27 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 45C5C12D82C for ; Wed, 10 Aug 2016 10:45:27 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id x25so24470998qtx.2 for ; Wed, 10 Aug 2016 10:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=h+KrCF02OVM2YWYOC7AtAu2T2Botmcz/TubgGS9XtP8=; b=wDdFqFoTZXvSS/Qb6o0s2BdRFHHbcQYVCondtEZmNyJMsZDh1FNG7tqwnCpPmW9jKI 440Nl4uzLdJGcP0FvqLxL+8QqKUGAGepZZ04W6meF3/b5DYDM3oqJG8u3yeK0HYb7xe8 mSXLlPmLlG12qQicuJZpGNPJ6jJksiCV/I0v5p6e7nesmEU9nqDIHL8xvTh5Bm00O5WM iwE7lvcdTM1WUCFZWluakIVrfIpV/xL/7PahcIlmXyfZ5f8NSgvfGA0miuhi8N+xFBH9 KrqFSP5wISI/YsDjD6ltIi0u+MygJkYmg3uv8NHhyT31Q5Q/5I0abxRaT5IQbhZlOlJ8 qRug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=h+KrCF02OVM2YWYOC7AtAu2T2Botmcz/TubgGS9XtP8=; b=Ssan8QI4meV9KQ2MTnXEHWQsWRrP77x3tzP3HO1C63A0PzUc7lhfE32yG0K/c3pteo M+rn8p9plvHd72AyQ6X39frUEBMxY+UONuBFA3+fFCoy4hDunUvOB229skY4SGNq8kgG 2PTMn8tRcZn8vA5VuvEAf0VD86aH92jJeGVa0A0g55MmPv1kLzp+m5+2zQWIFLkjDB8A P+cnRd+67xcETgypOLprzeGVVKwXNS/prO+Sq8/xStkAUVukn5GnwYu876QffMV04sjM XKAB+CkJCEl4aAC8/SGBNqcJeffgT7gs63Jpm9TJAoWFkjVgXKbMGl/2GMPZHB5mAPdy nN+A== X-Gm-Message-State: AEkooutY39zvQyCwk3UbmUEbsyd3bN4yThMOE8IfjwtWgIwHUla0kSJRpNKve62KtfqdkA== X-Received: by 10.200.34.135 with SMTP id f7mr5888162qta.141.1470851126151; Wed, 10 Aug 2016 10:45:26 -0700 (PDT) Received: from [10.33.192.77] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id a193sm23842806qkc.24.2016.08.10.10.45.24 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 10:45:25 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_CAC5CE5D-FD07-4116-8AE3-93D50F1B6799" Message-Id: <68108852-9571-4246-A9D6-3B75FC449C71@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Wed, 10 Aug 2016 13:45:21 -0400 References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7C4AD75D-D0A4-478B-AAE5-72313A2A7B9E@salsgiver.com> To: Emergency Context Resolution with Internet Technologies Discussion List In-Reply-To: <7C4AD75D-D0A4-478B-AAE5-72313A2A7B9E@salsgiver.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:45:30 -0000 --Apple-Mail=_CAC5CE5D-FD07-4116-8AE3-93D50F1B6799 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just for the moment, put aside any specific issues with eCall. We/ve agreed that if one needs a mid-call update of Additional Data, = that one defines a new INFO package and uses that to send such an = update. Use some case like alarm data: you get alarm status when the INVITE = arrives with a call, and you can get an update of that alarm data mid = call using INFO. In these cases, the EXACT same data is being sent, for the exact same = use, with the only difference being mid call vs call establishment. = That=E2=80=99s very clearly Additional Data. Should the MIME type be different for these use cases? Is the mid call update different from the call establishment in any = respect other than the sip message used? I agree that including the Call-Info is duplicative of the INFO, but is = it harmful? Is eCall so fundamentally different that it warrants a completely = different answer? Brian >=20 >> On Aug 10, 2016, at 1:29 PM, Drage, Keith (Nokia - GB) = wrote: >>=20 >> I disagree. >>=20 >> The inclusion of the data element in INFO is nothing to do with RFC = 7852. The data element is included because the use of an appropriate = Info package has been negotiated and used. That Info package definition = and the INFO mechanism itself makes no mention of use of Call-Info in = association with it.=20 >>=20 >> Further I see no justification for complicating any error handling by = suddenly defining it to be applicable, as it is not necessary. INFO = requests always contain a data element appropriate to the Info package = that is defined for its use - it absolutely does not need a secondary = reference to the package. >>=20 >> Keith >>=20 >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 >> Sent: 10 August 2016 18:20 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; = ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage = brings no value) >>=20 >> Hi Keith, >>=20 >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>=20 >>> Unless someone is defining a new usage for Call-Info beyond RFC7852=20= >>> then I have to agree with Ivo. That additional usage is not = currently=20 >>> defined in draft-ietf-ecrit-ecall, and I would need to understand = that=20 >>> usage before it is included. >>>=20 >>> At the moment RFC7852 is only used for the transfer of MSD in INVITE=20= >>> requests and 200 (OK) responses, and therefore that is the only = place=20 >>> where it should appear in association with RFC7852. >>=20 >> RFC 7852 covers use of Call-Info to point to emergency call data = blocks in any SIP message that is permitted to carry a body. >>=20 >>>=20 >>> Negotiation and transfer of MSD in association with INFO requests is=20= >>> an entirely separate transfer mechanism, not covered by=20 >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear=20= >>> there as though it had been. Inclusion will lead to complete = confusion=20 >>> as to whether the requirements of the INFO mechanism or the=20 >>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should = be=20 >>> absolutely clear that only the former apply. >>>=20 >>> Regards >>>=20 >>> Keith >>>=20 >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo = Sedlacek >>> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20= >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20= >>> usage brings no value) >>>=20 >>> Hello, >>>=20 >>>> The invite response still has a body with content-disposition=20 >>>> by-reference. If you remove the reference then its processing is=20 >>>> undefined. >>>=20 >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the=20 >>> Content-Disposition header field of the=20 >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition=20 >>> header field of the application/emergencyCallData.eCall.control+xml >>> body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and thus=20= >>> "render" would apply for the=20 >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>>=20 >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, = the=20 >>> Call-Info points to the=20 >>> application/emergencyCallData.eCall.control+xml body. This body=20 >>> contains a delivery report for the MSD sent in INVITE request. This = is=20 >>> NOT information about callee as described in RFC3261. >>>=20 >>> Kind regards >>>=20 >>> Ivo >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself = only >> -------------- Randomly selected tag: --------------- The idea that = Bill Gates has appeared like a knight in shining armor to lead all = customers out of a mire of technological chaos neatly ignores the fact = that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas = Adams >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 --Apple-Mail=_CAC5CE5D-FD07-4116-8AE3-93D50F1B6799 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just for the moment, put aside any specific issues with = eCall.

We/ve agreed that if one needs a mid-call update of = Additional Data, that one defines a new INFO package and uses that to = send such an update.

Use some case like alarm data: you get alarm status = when the INVITE arrives with a call, and you can get an update of that = alarm data mid call using INFO.

In these cases, the EXACT same data is = being sent, for the exact same use, with the only difference being mid = call vs call establishment.  That=E2=80=99s very clearly Additional = Data.

Should the MIME type be different for these use = cases?

Is the mid call update different from the call = establishment in any respect other than the sip message used?

I = agree that including the Call-Info is duplicative of the INFO, but is it = harmful?

Is eCall so fundamentally different that it warrants a = completely different answer?

Brian


On Aug 10, 2016, at 1:29 = PM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com> wrote:

I disagree.

The inclusion of the = data element in INFO is nothing to do with RFC 7852. The data element is = included because the use of an appropriate Info package has been = negotiated and used. That Info package definition and the INFO mechanism = itself makes no mention of use of Call-Info in association with it.

Further I see no justification for = complicating any error handling by suddenly defining it to be = applicable, as it is not necessary. INFO requests always contain a data = element appropriate to the Info package that is defined for its use - it = absolutely does not need a secondary reference to the package.

Keith

-----Original= Message-----
From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]
Sent: 10 = August 2016 18:20
To: Drage, Keith (Nokia - GB); Ivo = Sedlacek; Paul Kyzivat; ecrit@ietf.org
Subject: Re: [Ecrit] = draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was = RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

At 3:11 = PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

Unless someone is = defining a new usage for Call-Info beyond RFC7852
then I = have to agree with Ivo. That additional usage is not currently
defined in draft-ietf-ecrit-ecall, and I would need to = understand that
usage before it is included.

At the moment RFC7852 is only used for the = transfer of MSD in INVITE
requests and 200 (OK) = responses, and therefore that is the only place
where it = should appear in association with RFC7852.

RFC 7852 covers use of Call-Info to point to emergency call = data blocks in any SIP message that is permitted to carry a body.


Negotiation and transfer of MSD in association with INFO = requests is
an entirely separate transfer mechanism, not = covered by
draft-ietf-ecrit-data-only-ea and therefore it = should never appear
there as though it had been. = Inclusion will lead to complete confusion
as to whether = the requirements of the INFO mechanism or the
requirements = of draft-ietf-ecrit-data-only-ea apply, when it should be
absolutely clear that only the former apply.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo = Sedlacek
Sent: 10 August 2016 08:41
To: Paul = Kyzivat; ecrit@ietf.org
Subject: Re: [Ecrit] = draft-ietf-ecrit-ecall-11- Call-Info usage not
aligned = with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info
usage brings no value)

Hello,

The = invite response still has a body with content-disposition
by-reference. If you remove the reference then its processing = is
undefined.

If = the Call-Info is omitted in INVITE response, then:
Alt1: a = new value could be defined and used in the
Content-Disposition header field of the
application/emergencyCallData.eCall.control+xml body;
= or
Alt2: an existing value could be used in the = Content-Disposition
header field of the = application/emergencyCallData.eCall.control+xml
body;
= or
Alt3: the Content-Disposition header field can = be omitted and thus
"render" would apply for the
application/emergencyCallData.eCall.control+xml body = according to
RFC3261 section 13.2.1.

We cannot use the Call-Info in INVITE response as described = in
draft-ietf-ecrit-ecall-11 - in the response to the = INVITE request, the
Call-Info points to the
application/emergencyCallData.eCall.control+xml body. This = body
contains a delivery report for the MSD sent in = INVITE request. This is
NOT information about callee as = described in RFC3261.

Kind regards

Ivo


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal; =    facts are suspect;    I speak for = myself only
-------------- Randomly selected tag: = --------------- The idea that Bill Gates has appeared like a knight in = shining armor to lead all customers out of a mire of technological chaos = neatly ignores the fact that it was he who, by peddling second-rate = technology,
led them into it in the first place. =             &n= bsp;      --Douglas Adams

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


= --Apple-Mail=_CAC5CE5D-FD07-4116-8AE3-93D50F1B6799-- From nobody Wed Aug 10 10:54:14 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 BFD5812D806 for ; Wed, 10 Aug 2016 10:54:12 -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 F1d7t26p_iJX for ; Wed, 10 Aug 2016 10:54:10 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 ADD8D12B00E for ; Wed, 10 Aug 2016 10:54:09 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-5a-57ab6a3fa517 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id FA.74.04209.F3A6BA75; Wed, 10 Aug 2016 19:54:08 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 19:54:05 +0200 From: Christer Holmberg To: Brian Rosen , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAMNJ+v//4ReAgAAmCpqAAAE9cA== Date: Wed, 10 Aug 2016 17:54:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBD6267@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7C4AD75D-D0A4-478B-AAE5-72313A2A7B9E@salsgiver.com> <68108852-9571-4246-A9D6-3B75FC449C71@brianrosen.net> In-Reply-To: <68108852-9571-4246-A9D6-3B75FC449C71@brianrosen.net> 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_7594FB04B1934943A5C02806D1A2204B4BBD6267ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdS9cha3W4wa4JjBZP709js2hc9JTV gcnj/re/7B5LlvxkCmCK4rJJSc3JLEst0rdL4MrYuPIXY8GHw4wVS/ffY2lgvLGPsYuRk0NC wETi44YuFhBbSGA9o8TZH5VdjFxA9hJGia2rn7N3MXJwsAlYSHT/0waJiwg0Mkp8n9zHBtIg LLCQUeLh8hgQW0RgEaPE4uVyEHaWxOuT99lBbBYBVYk/fY+ZQebwCvhK/PvuCzG/m03izroF LCBxTgEnidOzK0DKGQXEJL6fWsMEYjMLiEvcejKfCeJOAYkle84zQ9iiEi8f/2OFsJUkVmy/ xAhRny/xdl4v2Gm8AoISJ2c+YZnAKDwLyahZSMpmISmbBXQFs4CmxPpd+hAlihJTuh+yQ9ga Eq1z5rIjiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERg/B7f8Vt3BePmN4yFGAQ5G JR5eBalV4UKsiWXFlbmHGCU4mJVEeIWTVocL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRgu JJCeWJKanZpakFoEk2Xi4JRqYIyb3m5VIPhQ++etotaKVQEyq5Zrhsk4LY7TCmfIXbvy90oR x9ktOz68Tpgt9t/U1t2hJSeutMw7QueI2HUHJ4O1n2ewxbpIKSlUMhTcOV+t7Rv91/XnjJ77 XBqHWc581LheuvPLrd2BLTe4JSb8qTyzsvzT+cba7dcC5kkGv8jSSFQ59v2vnRJLcUaioRZz UXEiALfvJEWbAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 17:54:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BBD6267ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCk1heWJlIEnigJl2ZSBtaXNzZWQgc29tZXRoaW5nLCBidXQgSSBkb27igJl0 IHRoaW5rIGFueW9uZSBoYXMgc2FpZCB0aGF0IHlvdSBuZWVkIHRvIHVzZSBkaWZmZXJlbnQgTUlN RSB0eXBlcy4gWW91IGNhbiB1c2UgdGhlIHNhbWUgTUlNRSB0eXBlIGluIElOVklURSBhbmQgSU5G TywgYW5kIHlvdSBjYW4gdXNlIHRoZSBzYW1lIE1JTUUgdHlwZSBpbiBkaWZmZXJlbnQgaW5mbyBw YWNrYWdlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogRWNyaXQgW21haWx0bzpl Y3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NClNlbnQ6IDEw IEF1Z3VzdCAyMDE2IDIwOjQ1DQpUbzogRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRo IEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3QgPGVjcml0QGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZv IHVzYWdlIG5vdCBhbGlnbmVkIHdpdGggUkZDMzI2MSAod2FzIFJFOiBkcmFmdC1pZXRmLWVjcml0 LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2UgYnJpbmdzIG5vIHZhbHVlKQ0KDQpKdXN0IGZvciB0 aGUgbW9tZW50LCBwdXQgYXNpZGUgYW55IHNwZWNpZmljIGlzc3VlcyB3aXRoIGVDYWxsLg0KDQpX ZS92ZSBhZ3JlZWQgdGhhdCBpZiBvbmUgbmVlZHMgYSBtaWQtY2FsbCB1cGRhdGUgb2YgQWRkaXRp b25hbCBEYXRhLCB0aGF0IG9uZSBkZWZpbmVzIGEgbmV3IElORk8gcGFja2FnZSBhbmQgdXNlcyB0 aGF0IHRvIHNlbmQgc3VjaCBhbiB1cGRhdGUuDQoNClVzZSBzb21lIGNhc2UgbGlrZSBhbGFybSBk YXRhOiB5b3UgZ2V0IGFsYXJtIHN0YXR1cyB3aGVuIHRoZSBJTlZJVEUgYXJyaXZlcyB3aXRoIGEg Y2FsbCwgYW5kIHlvdSBjYW4gZ2V0IGFuIHVwZGF0ZSBvZiB0aGF0IGFsYXJtIGRhdGEgbWlkIGNh bGwgdXNpbmcgSU5GTy4NCg0KSW4gdGhlc2UgY2FzZXMsIHRoZSBFWEFDVCBzYW1lIGRhdGEgaXMg YmVpbmcgc2VudCwgZm9yIHRoZSBleGFjdCBzYW1lIHVzZSwgd2l0aCB0aGUgb25seSBkaWZmZXJl bmNlIGJlaW5nIG1pZCBjYWxsIHZzIGNhbGwgZXN0YWJsaXNobWVudC4gIFRoYXTigJlzIHZlcnkg Y2xlYXJseSBBZGRpdGlvbmFsIERhdGEuDQoNClNob3VsZCB0aGUgTUlNRSB0eXBlIGJlIGRpZmZl cmVudCBmb3IgdGhlc2UgdXNlIGNhc2VzPw0KDQpJcyB0aGUgbWlkIGNhbGwgdXBkYXRlIGRpZmZl cmVudCBmcm9tIHRoZSBjYWxsIGVzdGFibGlzaG1lbnQgaW4gYW55IHJlc3BlY3Qgb3RoZXIgdGhh biB0aGUgc2lwIG1lc3NhZ2UgdXNlZD8NCg0KSSBhZ3JlZSB0aGF0IGluY2x1ZGluZyB0aGUgQ2Fs bC1JbmZvIGlzIGR1cGxpY2F0aXZlIG9mIHRoZSBJTkZPLCBidXQgaXMgaXQgaGFybWZ1bD8NCg0K SXMgZUNhbGwgc28gZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgdGhhdCBpdCB3YXJyYW50cyBhIGNv bXBsZXRlbHkgZGlmZmVyZW50IGFuc3dlcj8NCg0KQnJpYW4NCg0KDQoNCg0KT24gQXVnIDEwLCAy MDE2LCBhdCAxOjI5IFBNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIDxrZWl0aC5kcmFnZUBu b2tpYS5jb208bWFpbHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbT4+IHdyb3RlOg0KDQpJIGRpc2Fn cmVlLg0KDQpUaGUgaW5jbHVzaW9uIG9mIHRoZSBkYXRhIGVsZW1lbnQgaW4gSU5GTyBpcyBub3Ro aW5nIHRvIGRvIHdpdGggUkZDIDc4NTIuIFRoZSBkYXRhIGVsZW1lbnQgaXMgaW5jbHVkZWQgYmVj YXVzZSB0aGUgdXNlIG9mIGFuIGFwcHJvcHJpYXRlIEluZm8gcGFja2FnZSBoYXMgYmVlbiBuZWdv dGlhdGVkIGFuZCB1c2VkLiBUaGF0IEluZm8gcGFja2FnZSBkZWZpbml0aW9uIGFuZCB0aGUgSU5G TyBtZWNoYW5pc20gaXRzZWxmIG1ha2VzIG5vIG1lbnRpb24gb2YgdXNlIG9mIENhbGwtSW5mbyBp biBhc3NvY2lhdGlvbiB3aXRoIGl0Lg0KDQpGdXJ0aGVyIEkgc2VlIG5vIGp1c3RpZmljYXRpb24g Zm9yIGNvbXBsaWNhdGluZyBhbnkgZXJyb3IgaGFuZGxpbmcgYnkgc3VkZGVubHkgZGVmaW5pbmcg aXQgdG8gYmUgYXBwbGljYWJsZSwgYXMgaXQgaXMgbm90IG5lY2Vzc2FyeS4gSU5GTyByZXF1ZXN0 cyBhbHdheXMgY29udGFpbiBhIGRhdGEgZWxlbWVudCBhcHByb3ByaWF0ZSB0byB0aGUgSW5mbyBw YWNrYWdlIHRoYXQgaXMgZGVmaW5lZCBmb3IgaXRzIHVzZSAtIGl0IGFic29sdXRlbHkgZG9lcyBu b3QgbmVlZCBhIHNlY29uZGFyeSByZWZlcmVuY2UgdG8gdGhlIHBhY2thZ2UuDQoNCktlaXRoDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYW5kYWxsIEdlbGxlbnMgW21haWx0 bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnXQ0KU2VudDogMTAgQXVndXN0IDIwMTYgMTg6MjAN ClRvOiBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpOyBJdm8gU2VkbGFjZWs7IFBhdWwgS3l6aXZh dDsgZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtF Y3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIG5vdCBhbGln bmVkIHdpdGggUkZDMzI2MSAod2FzIFJFOiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxs LUluZm8gdXNhZ2UgYnJpbmdzIG5vIHZhbHVlKQ0KDQpIaSBLZWl0aCwNCg0KQXQgMzoxMSBQTSAr MDAwMCA4LzEwLzE2LCBLZWl0aCAoTm9raWEgLSBHQikgRHJhZ2Ugd3JvdGU6DQoNCg0KVW5sZXNz IHNvbWVvbmUgaXMgZGVmaW5pbmcgYSBuZXcgdXNhZ2UgZm9yIENhbGwtSW5mbyBiZXlvbmQgUkZD Nzg1Mg0KdGhlbiBJIGhhdmUgdG8gYWdyZWUgd2l0aCBJdm8uIFRoYXQgYWRkaXRpb25hbCB1c2Fn ZSBpcyBub3QgY3VycmVudGx5DQpkZWZpbmVkIGluIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwsIGFu ZCBJIHdvdWxkIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0DQp1c2FnZSBiZWZvcmUgaXQgaXMgaW5j bHVkZWQuDQoNCkF0IHRoZSBtb21lbnQgUkZDNzg1MiBpcyBvbmx5IHVzZWQgZm9yIHRoZSB0cmFu c2ZlciBvZiBNU0QgaW4gSU5WSVRFDQpyZXF1ZXN0cyBhbmQgMjAwIChPSykgcmVzcG9uc2VzLCBh bmQgdGhlcmVmb3JlIHRoYXQgaXMgdGhlIG9ubHkgcGxhY2UNCndoZXJlIGl0IHNob3VsZCBhcHBl YXIgaW4gYXNzb2NpYXRpb24gd2l0aCBSRkM3ODUyLg0KDQpSRkMgNzg1MiBjb3ZlcnMgdXNlIG9m IENhbGwtSW5mbyB0byBwb2ludCB0byBlbWVyZ2VuY3kgY2FsbCBkYXRhIGJsb2NrcyBpbiBhbnkg U0lQIG1lc3NhZ2UgdGhhdCBpcyBwZXJtaXR0ZWQgdG8gY2FycnkgYSBib2R5Lg0KDQoNCg0KTmVn b3RpYXRpb24gYW5kIHRyYW5zZmVyIG9mIE1TRCBpbiBhc3NvY2lhdGlvbiB3aXRoIElORk8gcmVx dWVzdHMgaXMNCmFuIGVudGlyZWx5IHNlcGFyYXRlIHRyYW5zZmVyIG1lY2hhbmlzbSwgbm90IGNv dmVyZWQgYnkNCmRyYWZ0LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhIGFuZCB0aGVyZWZvcmUgaXQg c2hvdWxkIG5ldmVyIGFwcGVhcg0KdGhlcmUgYXMgdGhvdWdoIGl0IGhhZCBiZWVuLiBJbmNsdXNp b24gd2lsbCBsZWFkIHRvIGNvbXBsZXRlIGNvbmZ1c2lvbg0KYXMgdG8gd2hldGhlciB0aGUgcmVx dWlyZW1lbnRzIG9mIHRoZSBJTkZPIG1lY2hhbmlzbSBvciB0aGUNCnJlcXVpcmVtZW50cyBvZiBk cmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYSBhcHBseSwgd2hlbiBpdCBzaG91bGQgYmUNCmFi c29sdXRlbHkgY2xlYXIgdGhhdCBvbmx5IHRoZSBmb3JtZXIgYXBwbHkuDQoNClJlZ2FyZHMNCg0K S2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVjcml0IFttYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEl2byBTZWRsYWNlaw0KU2VudDog MTAgQXVndXN0IDIwMTYgMDg6NDENClRvOiBQYXVsIEt5eml2YXQ7IGVjcml0QGlldGYub3JnPG1h aWx0bzplY3JpdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNy aXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QNCmFsaWduZWQgd2l0aCBSRkMzMjYxICh3 YXMgUkU6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbw0KdXNhZ2UgYnJpbmdz IG5vIHZhbHVlKQ0KDQpIZWxsbywNCg0KDQpUaGUgaW52aXRlIHJlc3BvbnNlIHN0aWxsIGhhcyBh IGJvZHkgd2l0aCBjb250ZW50LWRpc3Bvc2l0aW9uDQpieS1yZWZlcmVuY2UuIElmIHlvdSByZW1v dmUgdGhlIHJlZmVyZW5jZSB0aGVuIGl0cyBwcm9jZXNzaW5nIGlzDQp1bmRlZmluZWQuDQoNCklm IHRoZSBDYWxsLUluZm8gaXMgb21pdHRlZCBpbiBJTlZJVEUgcmVzcG9uc2UsIHRoZW46DQpBbHQx OiBhIG5ldyB2YWx1ZSBjb3VsZCBiZSBkZWZpbmVkIGFuZCB1c2VkIGluIHRoZQ0KQ29udGVudC1E aXNwb3NpdGlvbiBoZWFkZXIgZmllbGQgb2YgdGhlDQphcHBsaWNhdGlvbi9lbWVyZ2VuY3lDYWxs RGF0YS5lQ2FsbC5jb250cm9sK3htbCBib2R5Ow0KICAgICAgICAgICAgb3INCkFsdDI6IGFuIGV4 aXN0aW5nIHZhbHVlIGNvdWxkIGJlIHVzZWQgaW4gdGhlIENvbnRlbnQtRGlzcG9zaXRpb24NCmhl YWRlciBmaWVsZCBvZiB0aGUgYXBwbGljYXRpb24vZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuY29u dHJvbCt4bWwNCmJvZHk7DQogICAgICAgICAgICBvcg0KQWx0MzogdGhlIENvbnRlbnQtRGlzcG9z aXRpb24gaGVhZGVyIGZpZWxkIGNhbiBiZSBvbWl0dGVkIGFuZCB0aHVzDQoicmVuZGVyIiB3b3Vs ZCBhcHBseSBmb3IgdGhlDQphcHBsaWNhdGlvbi9lbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5jb250 cm9sK3htbCBib2R5IGFjY29yZGluZyB0bw0KUkZDMzI2MSBzZWN0aW9uIDEzLjIuMS4NCg0KV2Ug Y2Fubm90IHVzZSB0aGUgQ2FsbC1JbmZvIGluIElOVklURSByZXNwb25zZSBhcyBkZXNjcmliZWQg aW4NCmRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEgLSBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIElO VklURSByZXF1ZXN0LCB0aGUNCkNhbGwtSW5mbyBwb2ludHMgdG8gdGhlDQphcHBsaWNhdGlvbi9l bWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5jb250cm9sK3htbCBib2R5LiBUaGlzIGJvZHkNCmNvbnRh aW5zIGEgZGVsaXZlcnkgcmVwb3J0IGZvciB0aGUgTVNEIHNlbnQgaW4gSU5WSVRFIHJlcXVlc3Qu IFRoaXMgaXMNCk5PVCBpbmZvcm1hdGlvbiBhYm91dCBjYWxsZWUgYXMgZGVzY3JpYmVkIGluIFJG QzMyNjEuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRm Lm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3Jp dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQN Cg0KDQotLQ0KUmFuZGFsbCBHZWxsZW5zDQpPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3Rz IGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KLS0tLS0tLS0tLS0tLS0g UmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0gVGhlIGlkZWEgdGhhdCBCaWxs IEdhdGVzIGhhcyBhcHBlYXJlZCBsaWtlIGEga25pZ2h0IGluIHNoaW5pbmcgYXJtb3IgdG8gbGVh ZCBhbGwgY3VzdG9tZXJzIG91dCBvZiBhIG1pcmUgb2YgdGVjaG5vbG9naWNhbCBjaGFvcyBuZWF0 bHkgaWdub3JlcyB0aGUgZmFjdCB0aGF0IGl0IHdhcyBoZSB3aG8sIGJ5IHBlZGRsaW5nIHNlY29u ZC1yYXRlIHRlY2hub2xvZ3ksDQpsZWQgdGhlbSBpbnRvIGl0IGluIHRoZSBmaXJzdCBwbGFjZS4g ICAgICAgICAgICAgICAgICAgIC0tRG91Z2xhcyBBZGFtcw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBp ZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BBD6267ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFu DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQnJpYW4s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NYXliZSBJ4oCZdmUgbWlz c2VkIHNvbWV0aGluZywgYnV0IEkgZG9u4oCZdCB0aGluayBhbnlvbmUgaGFzIHNhaWQgdGhhdCB5 b3UgbmVlZCB0byB1c2UgZGlmZmVyZW50IE1JTUUgdHlwZXMuIFlvdSBjYW4gdXNlIHRoZSBzYW1l IE1JTUUNCiB0eXBlIGluIElOVklURSBhbmQgSU5GTywgYW5kIHlvdSBjYW4gdXNlIHRoZSBzYW1l IE1JTUUgdHlwZSBpbiBkaWZmZXJlbnQgaW5mbyBwYWNrYWdlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFY3JpdCBbbWFpbHRvOmVjcml0LWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIFJvc2VuPGJyPg0KPGI+ U2VudDo8L2I+IDEwIEF1Z3VzdCAyMDE2IDIwOjQ1PGJyPg0KPGI+VG86PC9iPiBFbWVyZ2VuY3kg Q29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24g TGlzdCAmbHQ7ZWNyaXRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRWNy aXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25l ZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1J bmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KdXN0IGZvciB0aGUgbW9tZW50LCBwdXQgYXNpZGUgYW55IHNwZWNp ZmljIGlzc3VlcyB3aXRoIGVDYWxsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNTg1NkQ2Ij48YnI+DQo8L3NwYW4+V2UvdmUg YWdyZWVkIHRoYXQgaWYgb25lIG5lZWRzIGEgbWlkLWNhbGwgdXBkYXRlIG9mIEFkZGl0aW9uYWwg RGF0YSwgdGhhdCBvbmUgZGVmaW5lcyBhIG5ldyBJTkZPIHBhY2thZ2UgYW5kIHVzZXMgdGhhdCB0 byBzZW5kIHN1Y2ggYW4gdXBkYXRlLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNTg1NkQ2Ij48 YnI+DQo8L3NwYW4+VXNlIHNvbWUgY2FzZSBsaWtlIGFsYXJtIGRhdGE6IHlvdSBnZXQgYWxhcm0g c3RhdHVzIHdoZW4gdGhlIElOVklURSBhcnJpdmVzIHdpdGggYSBjYWxsLCBhbmQgeW91IGNhbiBn ZXQgYW4gdXBkYXRlIG9mIHRoYXQgYWxhcm0gZGF0YSBtaWQgY2FsbCB1c2luZyBJTkZPLjxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjojNTg1NkQ2Ij48YnI+DQo8L3NwYW4+SW4gdGhlc2UgY2FzZXMs IHRoZSBFWEFDVCBzYW1lIGRhdGEgaXMgYmVpbmcgc2VudCwgZm9yIHRoZSBleGFjdCBzYW1lIHVz ZSwgd2l0aCB0aGUgb25seSBkaWZmZXJlbmNlIGJlaW5nIG1pZCBjYWxsIHZzIGNhbGwgZXN0YWJs aXNobWVudC4gJm5ic3A7VGhhdOKAmXMgdmVyeSBjbGVhcmx5IEFkZGl0aW9uYWwgRGF0YS48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4NTZENiI+PGJyPg0KPC9zcGFuPlNob3VsZCB0aGUgTUlN RSB0eXBlIGJlIGRpZmZlcmVudCBmb3IgdGhlc2UgdXNlIGNhc2VzPzxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojNTg1NkQ2Ij48YnI+DQo8L3NwYW4+SXMgdGhlIG1pZCBjYWxsIHVwZGF0ZSBkaWZm ZXJlbnQgZnJvbSB0aGUgY2FsbCBlc3RhYmxpc2htZW50IGluIGFueSByZXNwZWN0IG90aGVyIHRo YW4gdGhlIHNpcCBtZXNzYWdlIHVzZWQ/PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1ODU2RDYi Pjxicj4NCjwvc3Bhbj5JIGFncmVlIHRoYXQgaW5jbHVkaW5nIHRoZSBDYWxsLUluZm8gaXMgZHVw bGljYXRpdmUgb2YgdGhlIElORk8sIGJ1dCBpcyBpdCBoYXJtZnVsPzxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojNTg1NkQ2Ij48YnI+DQo8L3NwYW4+SXMgZUNhbGwgc28gZnVuZGFtZW50YWxseSBk aWZmZXJlbnQgdGhhdCBpdCB3YXJyYW50cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFuc3dlcj88 YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4NTZENiI+PGJyPg0KPC9zcGFuPkJyaWFuPGJyPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiM1ODU2RDYiPjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDEwLCAyMDE2LCBh dCAxOjI5IFBNLCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpICZsdDs8YSBocmVmPSJtYWlsdG86 a2VpdGguZHJhZ2VAbm9raWEuY29tIj5rZWl0aC5kcmFnZUBub2tpYS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQpJIGRpc2FncmVlLjxicj4NCjxicj4NClRoZSBpbmNsdXNpb24gb2YgdGhl IGRhdGEgZWxlbWVudCBpbiBJTkZPIGlzIG5vdGhpbmcgdG8gZG8gd2l0aCBSRkMgNzg1Mi4gVGhl IGRhdGEgZWxlbWVudCBpcyBpbmNsdWRlZCBiZWNhdXNlIHRoZSB1c2Ugb2YgYW4gYXBwcm9wcmlh dGUgSW5mbyBwYWNrYWdlIGhhcyBiZWVuIG5lZ290aWF0ZWQgYW5kIHVzZWQuIFRoYXQgSW5mbyBw YWNrYWdlIGRlZmluaXRpb24gYW5kIHRoZSBJTkZPIG1lY2hhbmlzbSBpdHNlbGYgbWFrZXMgbm8g bWVudGlvbiBvZg0KIHVzZSBvZiBDYWxsLUluZm8gaW4gYXNzb2NpYXRpb24gd2l0aCBpdC4gPGJy Pg0KPGJyPg0KRnVydGhlciBJIHNlZSBubyBqdXN0aWZpY2F0aW9uIGZvciBjb21wbGljYXRpbmcg YW55IGVycm9yIGhhbmRsaW5nIGJ5IHN1ZGRlbmx5IGRlZmluaW5nIGl0IHRvIGJlIGFwcGxpY2Fi bGUsIGFzIGl0IGlzIG5vdCBuZWNlc3NhcnkuIElORk8gcmVxdWVzdHMgYWx3YXlzIGNvbnRhaW4g YSBkYXRhIGVsZW1lbnQgYXBwcm9wcmlhdGUgdG8gdGhlIEluZm8gcGFja2FnZSB0aGF0IGlzIGRl ZmluZWQgZm9yIGl0cyB1c2UgLSBpdCBhYnNvbHV0ZWx5IGRvZXMNCiBub3QgbmVlZCBhIHNlY29u ZGFyeSByZWZlcmVuY2UgdG8gdGhlIHBhY2thZ2UuPGJyPg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFJhbmRhbGwgR2VsbGVucyBb PGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnIj5tYWlsdG86cmcm IzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L2E+XQ0KPGJyPg0KU2VudDogMTAgQXVndXN0IDIw MTYgMTg6MjA8YnI+DQpUbzogRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgSXZvIFNlZGxhY2Vr OyBQYXVsIEt5eml2YXQ7IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+DQplY3JpdEBp ZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVj YWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6 IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8gdmFs dWUpPGJyPg0KPGJyPg0KSGkgS2VpdGgsPGJyPg0KPGJyPg0KQXQgMzoxMSBQTSAmIzQzOzAwMDAg OC8xMC8xNiwgS2VpdGggKE5va2lhIC0gR0IpIERyYWdlIHdyb3RlOjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Vbmxlc3Mgc29tZW9uZSBp cyBkZWZpbmluZyBhIG5ldyB1c2FnZSBmb3IgQ2FsbC1JbmZvIGJleW9uZCBSRkM3ODUyDQo8YnI+ DQp0aGVuIEkgaGF2ZSB0byBhZ3JlZSB3aXRoIEl2by4gVGhhdCBhZGRpdGlvbmFsIHVzYWdlIGlz IG5vdCBjdXJyZW50bHkgPGJyPg0KZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLCBh bmQgSSB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCA8YnI+DQp1c2FnZSBiZWZvcmUgaXQg aXMgaW5jbHVkZWQuPGJyPg0KPGJyPg0KQXQgdGhlIG1vbWVudCBSRkM3ODUyIGlzIG9ubHkgdXNl ZCBmb3IgdGhlIHRyYW5zZmVyIG9mIE1TRCBpbiBJTlZJVEUgPGJyPg0KcmVxdWVzdHMgYW5kIDIw MCAoT0spIHJlc3BvbnNlcywgYW5kIHRoZXJlZm9yZSB0aGF0IGlzIHRoZSBvbmx5IHBsYWNlIDxi cj4NCndoZXJlIGl0IHNob3VsZCBhcHBlYXIgaW4gYXNzb2NpYXRpb24gd2l0aCBSRkM3ODUyLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K UkZDIDc4NTIgY292ZXJzIHVzZSBvZiBDYWxsLUluZm8gdG8gcG9pbnQgdG8gZW1lcmdlbmN5IGNh bGwgZGF0YSBibG9ja3MgaW4gYW55IFNJUCBtZXNzYWdlIHRoYXQgaXMgcGVybWl0dGVkIHRvIGNh cnJ5IGEgYm9keS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KTmVnb3RpYXRpb24gYW5kIHRyYW5zZmVyIG9mIE1TRCBpbiBhc3Nv Y2lhdGlvbiB3aXRoIElORk8gcmVxdWVzdHMgaXMgPGJyPg0KYW4gZW50aXJlbHkgc2VwYXJhdGUg dHJhbnNmZXIgbWVjaGFuaXNtLCBub3QgY292ZXJlZCBieSA8YnI+DQpkcmFmdC1pZXRmLWVjcml0 LWRhdGEtb25seS1lYSBhbmQgdGhlcmVmb3JlIGl0IHNob3VsZCBuZXZlciBhcHBlYXIgPGJyPg0K dGhlcmUgYXMgdGhvdWdoIGl0IGhhZCBiZWVuLiBJbmNsdXNpb24gd2lsbCBsZWFkIHRvIGNvbXBs ZXRlIGNvbmZ1c2lvbiA8YnI+DQphcyB0byB3aGV0aGVyIHRoZSByZXF1aXJlbWVudHMgb2YgdGhl IElORk8gbWVjaGFuaXNtIG9yIHRoZSA8YnI+DQpyZXF1aXJlbWVudHMgb2YgZHJhZnQtaWV0Zi1l Y3JpdC1kYXRhLW9ubHktZWEgYXBwbHksIHdoZW4gaXQgc2hvdWxkIGJlIDxicj4NCmFic29sdXRl bHkgY2xlYXIgdGhhdCBvbmx5IHRoZSBmb3JtZXIgYXBwbHkuPGJyPg0KPGJyPg0KUmVnYXJkczxi cj4NCjxicj4NCktlaXRoPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQpGcm9tOiBFY3JpdCBbPGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEl2byBTZWRsYWNl azxicj4NClNlbnQ6IDEwIEF1Z3VzdCAyMDE2IDA4OjQxPGJyPg0KVG86IFBhdWwgS3l6aXZhdDsg PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT48YnI+DQpT dWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxsLUluZm8g dXNhZ2Ugbm90IDxicj4NCmFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6IGRyYWZ0LWlldGYt ZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyA8YnI+DQp1c2FnZSBicmluZ3Mgbm8gdmFsdWUpPGJy Pg0KPGJyPg0KSGVsbG8sPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBpbnZpdGUgcmVzcG9uc2Ugc3RpbGwgaGFzIGEgYm9keSB3aXRo IGNvbnRlbnQtZGlzcG9zaXRpb24NCjxicj4NCmJ5LXJlZmVyZW5jZS4gSWYgeW91IHJlbW92ZSB0 aGUgcmVmZXJlbmNlIHRoZW4gaXRzIHByb2Nlc3NpbmcgaXMgPGJyPg0KdW5kZWZpbmVkLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSWYg dGhlIENhbGwtSW5mbyBpcyBvbWl0dGVkIGluIElOVklURSByZXNwb25zZSwgdGhlbjo8YnI+DQpB bHQxOiBhIG5ldyB2YWx1ZSBjb3VsZCBiZSBkZWZpbmVkIGFuZCB1c2VkIGluIHRoZSA8YnI+DQpD b250ZW50LURpc3Bvc2l0aW9uIGhlYWRlciBmaWVsZCBvZiB0aGUgPGJyPg0KYXBwbGljYXRpb24v ZW1lcmdlbmN5Q2FsbERhdGEuZUNhbGwuY29udHJvbCYjNDM7eG1sIGJvZHk7PGJyPg0KPHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm9yPGJyPg0KQWx0MjogYW4g ZXhpc3RpbmcgdmFsdWUgY291bGQgYmUgdXNlZCBpbiB0aGUgQ29udGVudC1EaXNwb3NpdGlvbiA8 YnI+DQpoZWFkZXIgZmllbGQgb2YgdGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVD YWxsLmNvbnRyb2wmIzQzO3htbDxicj4NCmJvZHk7PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm9yPGJyPg0KQWx0MzogdGhlIENvbnRlbnQtRGlzcG9z aXRpb24gaGVhZGVyIGZpZWxkIGNhbiBiZSBvbWl0dGVkIGFuZCB0aHVzIDxicj4NCiZxdW90O3Jl bmRlciZxdW90OyB3b3VsZCBhcHBseSBmb3IgdGhlIDxicj4NCmFwcGxpY2F0aW9uL2VtZXJnZW5j eUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbCBib2R5IGFjY29yZGluZyB0bzxicj4NClJG QzMyNjEgc2VjdGlvbiAxMy4yLjEuPGJyPg0KPGJyPg0KV2UgY2Fubm90IHVzZSB0aGUgQ2FsbC1J bmZvIGluIElOVklURSByZXNwb25zZSBhcyBkZXNjcmliZWQgaW48YnI+DQpkcmFmdC1pZXRmLWVj cml0LWVjYWxsLTExIC0gaW4gdGhlIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCwgdGhl IDxicj4NCkNhbGwtSW5mbyBwb2ludHMgdG8gdGhlIDxicj4NCmFwcGxpY2F0aW9uL2VtZXJnZW5j eUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbCBib2R5LiBUaGlzIGJvZHkgPGJyPg0KY29u dGFpbnMgYSBkZWxpdmVyeSByZXBvcnQgZm9yIHRoZSBNU0Qgc2VudCBpbiBJTlZJVEUgcmVxdWVz dC4gVGhpcyBpcyA8YnI+DQpOT1QgaW5mb3JtYXRpb24gYWJvdXQgY2FsbGVlIGFzIGRlc2NyaWJl ZCBpbiBSRkMzMjYxLjxicj4NCjxicj4NCktpbmQgcmVnYXJkczxicj4NCjxicj4NCkl2bzxicj4N Cjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkVjcml0QGll dGYub3JnIj5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOkVjcml0QGlldGYub3JnIj5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS08YnI+DQpSYW5k YWxsIEdlbGxlbnM8YnI+DQpPcGluaW9ucyBhcmUgcGVyc29uYWw7ICZuYnNwOyZuYnNwOyZuYnNw O2ZhY3RzIGFyZSBzdXNwZWN0OyAmbmJzcDsmbmJzcDsmbmJzcDtJIHNwZWFrIGZvciBteXNlbGYg b25seTxicj4NCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0t LS0tLS0tIFRoZSBpZGVhIHRoYXQgQmlsbCBHYXRlcyBoYXMgYXBwZWFyZWQgbGlrZSBhIGtuaWdo dCBpbiBzaGluaW5nIGFybW9yIHRvIGxlYWQgYWxsIGN1c3RvbWVycyBvdXQgb2YgYSBtaXJlIG9m IHRlY2hub2xvZ2ljYWwgY2hhb3MgbmVhdGx5IGlnbm9yZXMgdGhlIGZhY3QgdGhhdCBpdCB3YXMg aGUgd2hvLCBieSBwZWRkbGluZyBzZWNvbmQtcmF0ZSB0ZWNobm9sb2d5LDxicj4NCmxlZCB0aGVt IGludG8gaXQgaW4gdGhlIGZpcnN0IHBsYWNlLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLURvdWdsYXMgQWRhbXM8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BBD6267ESESSMB208erics_-- From nobody Wed Aug 10 11:03: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 E72B312D80B for ; Wed, 10 Aug 2016 11:03:22 -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 2S2jYTgt-C53 for ; Wed, 10 Aug 2016 11:03:21 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A5BCE12D0F6 for ; Wed, 10 Aug 2016 11:03:20 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-2a-57ab6c665655 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id EC.5C.02493.66C6BA75; Wed, 10 Aug 2016 20:03:19 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Wed, 10 Aug 2016 20:03:15 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAMNJ+oAACbJQ Date: Wed, 10 Aug 2016 18:03:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BBD62DB@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdWjc9Z3W4wZdPjBaNi56yWmzYcpzF YsWGA6wW3593MTqwePx9/4HJY8mSn0wed29dYvLYeucxSwBLFJdNSmpOZllqkb5dAlfG/K9t rAVzlSvuzDjM0sB4XaaLkZNDQsBEYtuFtYxdjFwcQgLrGSWebrrBDOEsYZT49+4YexcjBweb gIVE9z9tkAYRgbuMErs2e4PYwgILGSUeLo+BiC9ilFi8XA6kXEQgSqJtniBImEVAVaJz4gom EJtXwFdi5ZOTrBDjT7JI3LuzCSzBKWAssX7hCTCbUUBM4vupNWA2s4C4xK0n85kgDhWQWLLn PDOELSrx8vE/VghbSWLF9kuMEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWYhGTsLScss JC2zkLQsYGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYNwe3/LbawXjwueMhRgEORiUe XgWpVeFCrIllxZW5hxglOJiVRHiFk1aHC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQ nliSmp2aWpBaBJNl4uCUamBs2Nsyb2Msu3vtrGNbE6TD/7VezZLlv371XtK3/GVhKavTvqYc YnMyjnryw2TF8+cx9pwL7CP0jr2YUS00ZeJKtXlzyhalKm37+yPW67dqxwrlk+VsN6Tf2Ly6 +mKXcu50kW71ifrVvof8hJ0m1p9Y/pVNz901JuO0dO/WiXorHzzP5m3Yfn+xEktxRqKhFnNR cSIAMR5nwZcCAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 18:03:23 -0000 Hi, Again, as we have discussed before, RFC 7852 does not apply to INFO. And, w= e did agree to not carry the bodies in INFO responses. And, again, in INFO we won't use the "by-reference" content type, which is = another example why you can't apply RFC 7852 to INFO. I DID raise these issues before 7852 was published, but was told it's too l= ate to change at that point. So, maybe we need to correct 7852 if that is u= nclear. Regards, Christer -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 10 August 2016 20:20 To: Drage, Keith (Nokia - GB) ; Ivo Sedlacek ; Paul Kyzivat ; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Keith, At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > Unless someone is defining a new usage for Call-Info beyond RFC7852=20 > then I have to agree with Ivo. That additional usage is not currently=20 > defined in draft-ietf-ecrit-ecall, and I would need to understand that=20 > usage before it is included. > > At the moment RFC7852 is only used for the transfer of MSD in INVITE=20 > requests and 200 (OK) responses, and therefore that is the only place=20 > where it should appear in association with RFC7852. RFC 7852 covers use of Call-Info to point to emergency call data blocks in = any SIP message that is permitted to carry a body. > > Negotiation and transfer of MSD in association with INFO requests is=20 > an entirely separate transfer mechanism, not covered by=20 > draft-ietf-ecrit-data-only-ea and therefore it should never appear=20 > there as though it had been. Inclusion will lead to complete confusion=20 > as to whether the requirements of the INFO mechanism or the=20 > requirements of draft-ietf-ecrit-data-only-ea apply, when it should be=20 > absolutely clear that only the former apply. > > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 10 August 2016 08:41 > To: Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > Hello, > >> The invite response still has a body with content-disposition=20 >> by-reference. If you remove the reference then its processing is=20 >> undefined. > > If the Call-Info is omitted in INVITE response, then: > Alt1: a new value could be defined and used in the=20 > Content-Disposition header field of the=20 > application/emergencyCallData.eCall.control+xml body; > or > Alt2: an existing value could be used in the Content-Disposition=20 > header field of the application/emergencyCallData.eCall.control+xml > body; > or > Alt3: the Content-Disposition header field can be omitted and thus=20 > "render" would apply for the=20 > application/emergencyCallData.eCall.control+xml body according to > RFC3261 section 13.2.1. > > We cannot use the Call-Info in INVITE response as described in > draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the=20 > Call-Info points to the=20 > application/emergencyCallData.eCall.control+xml body. This body=20 > contains a delivery report for the MSD sent in INVITE request. This is=20 > NOT information about callee as described in RFC3261. > > Kind regards > > Ivo > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The idea that Bill Ga= tes has appeared like a knight in shining armor to lead all customers out o= f a mire of technological chaos neatly ignores the fact that it was he who,= by peddling second-rate technology, led them into it in the first place. --Douglas Adams _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 10 11:14: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 C609612D193 for ; Wed, 10 Aug 2016 11:14: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 1eZkG21ssPt8 for ; Wed, 10 Aug 2016 11:14:13 -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 5D60012B01B for ; Wed, 10 Aug 2016 11:14:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 320A99B3DCA6E; Wed, 10 Aug 2016 18:14: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 u7AIEAt6008044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 18:14:10 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 u7AICshw004088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 20:14:10 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 20:13:59 +0200 From: "Drage, Keith (Nokia - GB)" To: Brian Rosen , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8y41G0zxC1j38UuGPF6mYu9SJKBCVgqAgAAjUWA= Date: Wed, 10 Aug 2016 18:13:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF451E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7C4AD75D-D0A4-478B-AAE5-72313A2A7B9E@salsgiver.com> <68108852-9571-4246-A9D6-3B75FC449C71@brianrosen.net> In-Reply-To: <68108852-9571-4246-A9D6-3B75FC449C71@brianrosen.net> 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF451E6FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 18:14:17 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF451E6FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdCB0aGUgaW5jbHVzaW9uIG9mIENhbGwtSW5mbyBpbiBJTkZPIHJlcXVlc3RzIGlu dHJvZHVjZXMgYWRkaXRpb25hbCBjb21wbGV4aXRpZXMgaW4gcHJvdG9jb2wgcHJvY2Vzc2luZywg d2hpY2ggY291bGQgcmVzdWx0IGluIHRoZSBkYXRhIGVsZW1lbnQgbm90IGJlaW5nIHByb2Nlc3Nl ZCwgd2hpY2ggaW4gbXkgdmlldyBpcyBoYXJtZnVsLg0KDQpJZiBmb3IgZXhhbXBsZSwgdGhlIENh bGwtSW5mbyBpcyBzZW50IHdpdGggYSBvbmUgY2hhcmFjdGVyIGVycm9yIGluIHRoZSByZWZlcmVu Y2UgdGV4dCAodGhlIGhlYWRlciBmaWVsZCB2YWx1ZSksIHdlIGNvdWxkIHdlbGwgZW5kIHVwIHdp dGggdGhlIHJlY2lwaWVudCBkcm9wcGluZyB0aGUgZGF0YSBlbGVtZW50Lg0KDQpLZWVwaW5nIGl0 IHNpbXBsZSBtZWFucyBub3QgaW5jbHVkaW5nIGFueXRoaW5nIGJleW9uZCB0aGF0IHJlcXVpcmVk IGJ5IHRoZSBTSVAgcGFydCBvZiB0aGUgZGF0YSB0cmFuc2ZlciBwcm90b2NvbC4gVGhhdCBwcm90 b2NvbCBpcyB0aGUgSU5GTyBtZWNoYW5pc20gd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFja2FnZSBk ZWZpbml0aW9uLg0KDQpJIGRvIGFncmVlIHRoYXQgd2UgY291bGQgZG8gbW9yZSBpbiB0aGUgZHJh ZnQgdG8gc3RyZXNzIHRoYXQgd2UgZG8gaGF2ZSB0d28gZW50aXJlbHkgc2VwYXJhdGUgU0lQIGRh dGEgdHJhbnNmZXIgbWVjaGFuaXNtIOKAkyBvYnZpb3VzbHkgYm90aCBjb250YWluIE1TRHMsIGNv ZGVkIHVzaW5nIHRoZSBzYW1lIHN5bnRheCwgYnV0IHRoZSBzdXJyb3VuZGluZyBwcm90b2NvbCBp cyBkaWZmZXJlbnQuIEFzIGEgcmVzdWx0IHRoZSBlcnJvciBoYW5kbGluZyBpcyB0aGF0IGRlZmlu ZWQgZm9yIGVhY2ggaW5kaXZpZHVhbCB0cmFuc2ZlciBtZWNoYW5pc20sIGFuZCBub3QgY2Fycmll ZCBvdmVyIHRvIHRoZSBvdGhlci4gRGF0YSBmcm9tIHRoZSB0d28gc2VwYXJhdGUgbWVjaGFuaXNt IGlzIG9ubHkgY29tYmluZWQgaW4gYSBsYXllciBhYm92ZSB0aGUgU0lQIGFjdGlvbnMuDQoNCkkg ZG8gbm90IGJlbGlldmUgdGhlIE1JTUUgdHlwZSBuZWVkcyB0byBiZSBkaWZmZXJlbnQsIHRoZSBN SU1FIHR5cGUgZGVzY3JpYmVzIHRoZSBib2R5IHN5bnRheCBhbmQgdGhlIGJvZHkgaXMgb25lIGFu ZCB0aGUgc2FtZSAoYXQgdGhlIG1vbWVudCkuIFdlIGFyZSBkaXNjdXNzaW5nIENhbGwtSW5mbyB2 ZXJzdXMgdGhlIEluZm8tUGFja2FnZSBoZWFkZXIgZmllbGRzLCBib3RoIG9mIHdoaWNoIHBlcmZv cm0gc2ltaWxhciB0YXNrcyBpbiBpZGVudGlmeWluZyBhIGJvZHkgYW5kIHRoZSB1c2FnZSBpdCBi ZWxvbmdzIHRvLCBlYWNoIGZvciBpdHMgYXBwcm9wcmlhdGUgZGF0YSB0cmFuc2ZlciBtZWNoYW5p c20uDQoNCktlaXRoDQoNCkZyb206IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQpTZW50OiAxMCBBdWd1c3QgMjAxNiAxODo0NQ0K VG86IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dp ZXMgRGlzY3Vzc2lvbiBMaXN0DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0 LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMg UkU6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8g dmFsdWUpDQoNCkp1c3QgZm9yIHRoZSBtb21lbnQsIHB1dCBhc2lkZSBhbnkgc3BlY2lmaWMgaXNz dWVzIHdpdGggZUNhbGwuDQoNCldlL3ZlIGFncmVlZCB0aGF0IGlmIG9uZSBuZWVkcyBhIG1pZC1j YWxsIHVwZGF0ZSBvZiBBZGRpdGlvbmFsIERhdGEsIHRoYXQgb25lIGRlZmluZXMgYSBuZXcgSU5G TyBwYWNrYWdlIGFuZCB1c2VzIHRoYXQgdG8gc2VuZCBzdWNoIGFuIHVwZGF0ZS4NCg0KVXNlIHNv bWUgY2FzZSBsaWtlIGFsYXJtIGRhdGE6IHlvdSBnZXQgYWxhcm0gc3RhdHVzIHdoZW4gdGhlIElO VklURSBhcnJpdmVzIHdpdGggYSBjYWxsLCBhbmQgeW91IGNhbiBnZXQgYW4gdXBkYXRlIG9mIHRo YXQgYWxhcm0gZGF0YSBtaWQgY2FsbCB1c2luZyBJTkZPLg0KDQpJbiB0aGVzZSBjYXNlcywgdGhl IEVYQUNUIHNhbWUgZGF0YSBpcyBiZWluZyBzZW50LCBmb3IgdGhlIGV4YWN0IHNhbWUgdXNlLCB3 aXRoIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmVpbmcgbWlkIGNhbGwgdnMgY2FsbCBlc3RhYmxpc2ht ZW50LiAgVGhhdOKAmXMgdmVyeSBjbGVhcmx5IEFkZGl0aW9uYWwgRGF0YS4NCg0KU2hvdWxkIHRo ZSBNSU1FIHR5cGUgYmUgZGlmZmVyZW50IGZvciB0aGVzZSB1c2UgY2FzZXM/DQoNCklzIHRoZSBt aWQgY2FsbCB1cGRhdGUgZGlmZmVyZW50IGZyb20gdGhlIGNhbGwgZXN0YWJsaXNobWVudCBpbiBh bnkgcmVzcGVjdCBvdGhlciB0aGFuIHRoZSBzaXAgbWVzc2FnZSB1c2VkPw0KDQpJIGFncmVlIHRo YXQgaW5jbHVkaW5nIHRoZSBDYWxsLUluZm8gaXMgZHVwbGljYXRpdmUgb2YgdGhlIElORk8sIGJ1 dCBpcyBpdCBoYXJtZnVsPw0KDQpJcyBlQ2FsbCBzbyBmdW5kYW1lbnRhbGx5IGRpZmZlcmVudCB0 aGF0IGl0IHdhcnJhbnRzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgYW5zd2VyPw0KDQpCcmlhbg0K DQoNCg0KDQpPbiBBdWcgMTAsIDIwMTYsIGF0IDE6MjkgUE0sIERyYWdlLCBLZWl0aCAoTm9raWEg LSBHQikgPGtlaXRoLmRyYWdlQG5va2lhLmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29t Pj4gd3JvdGU6DQoNCkkgZGlzYWdyZWUuDQoNClRoZSBpbmNsdXNpb24gb2YgdGhlIGRhdGEgZWxl bWVudCBpbiBJTkZPIGlzIG5vdGhpbmcgdG8gZG8gd2l0aCBSRkMgNzg1Mi4gVGhlIGRhdGEgZWxl bWVudCBpcyBpbmNsdWRlZCBiZWNhdXNlIHRoZSB1c2Ugb2YgYW4gYXBwcm9wcmlhdGUgSW5mbyBw YWNrYWdlIGhhcyBiZWVuIG5lZ290aWF0ZWQgYW5kIHVzZWQuIFRoYXQgSW5mbyBwYWNrYWdlIGRl ZmluaXRpb24gYW5kIHRoZSBJTkZPIG1lY2hhbmlzbSBpdHNlbGYgbWFrZXMgbm8gbWVudGlvbiBv ZiB1c2Ugb2YgQ2FsbC1JbmZvIGluIGFzc29jaWF0aW9uIHdpdGggaXQuDQoNCkZ1cnRoZXIgSSBz ZWUgbm8ganVzdGlmaWNhdGlvbiBmb3IgY29tcGxpY2F0aW5nIGFueSBlcnJvciBoYW5kbGluZyBi eSBzdWRkZW5seSBkZWZpbmluZyBpdCB0byBiZSBhcHBsaWNhYmxlLCBhcyBpdCBpcyBub3QgbmVj ZXNzYXJ5LiBJTkZPIHJlcXVlc3RzIGFsd2F5cyBjb250YWluIGEgZGF0YSBlbGVtZW50IGFwcHJv cHJpYXRlIHRvIHRoZSBJbmZvIHBhY2thZ2UgdGhhdCBpcyBkZWZpbmVkIGZvciBpdHMgdXNlIC0g aXQgYWJzb2x1dGVseSBkb2VzIG5vdCBuZWVkIGEgc2Vjb25kYXJ5IHJlZmVyZW5jZSB0byB0aGUg cGFja2FnZS4NCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJh bmRhbGwgR2VsbGVucyBbbWFpbHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmddDQpTZW50OiAx MCBBdWd1c3QgMjAxNiAxODoyMA0KVG86IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQik7IEl2byBT ZWRsYWNlazsgUGF1bCBLeXppdmF0OyBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxs LUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6IGRyYWZ0LWlldGYt ZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8gdmFsdWUpDQoNCkhpIEtl aXRoLA0KDQpBdCAzOjExIFBNICswMDAwIDgvMTAvMTYsIEtlaXRoIChOb2tpYSAtIEdCKSBEcmFn ZSB3cm90ZToNCg0KDQpVbmxlc3Mgc29tZW9uZSBpcyBkZWZpbmluZyBhIG5ldyB1c2FnZSBmb3Ig Q2FsbC1JbmZvIGJleW9uZCBSRkM3ODUyDQp0aGVuIEkgaGF2ZSB0byBhZ3JlZSB3aXRoIEl2by4g VGhhdCBhZGRpdGlvbmFsIHVzYWdlIGlzIG5vdCBjdXJyZW50bHkNCmRlZmluZWQgaW4gZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbCwgYW5kIEkgd291bGQgbmVlZCB0byB1bmRlcnN0YW5kIHRoYXQNCnVz YWdlIGJlZm9yZSBpdCBpcyBpbmNsdWRlZC4NCg0KQXQgdGhlIG1vbWVudCBSRkM3ODUyIGlzIG9u bHkgdXNlZCBmb3IgdGhlIHRyYW5zZmVyIG9mIE1TRCBpbiBJTlZJVEUNCnJlcXVlc3RzIGFuZCAy MDAgKE9LKSByZXNwb25zZXMsIGFuZCB0aGVyZWZvcmUgdGhhdCBpcyB0aGUgb25seSBwbGFjZQ0K d2hlcmUgaXQgc2hvdWxkIGFwcGVhciBpbiBhc3NvY2lhdGlvbiB3aXRoIFJGQzc4NTIuDQoNClJG QyA3ODUyIGNvdmVycyB1c2Ugb2YgQ2FsbC1JbmZvIHRvIHBvaW50IHRvIGVtZXJnZW5jeSBjYWxs IGRhdGEgYmxvY2tzIGluIGFueSBTSVAgbWVzc2FnZSB0aGF0IGlzIHBlcm1pdHRlZCB0byBjYXJy eSBhIGJvZHkuDQoNCg0KDQpOZWdvdGlhdGlvbiBhbmQgdHJhbnNmZXIgb2YgTVNEIGluIGFzc29j aWF0aW9uIHdpdGggSU5GTyByZXF1ZXN0cyBpcw0KYW4gZW50aXJlbHkgc2VwYXJhdGUgdHJhbnNm ZXIgbWVjaGFuaXNtLCBub3QgY292ZXJlZCBieQ0KZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHkt ZWEgYW5kIHRoZXJlZm9yZSBpdCBzaG91bGQgbmV2ZXIgYXBwZWFyDQp0aGVyZSBhcyB0aG91Z2gg aXQgaGFkIGJlZW4uIEluY2x1c2lvbiB3aWxsIGxlYWQgdG8gY29tcGxldGUgY29uZnVzaW9uDQph cyB0byB3aGV0aGVyIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIElORk8gbWVjaGFuaXNtIG9yIHRo ZQ0KcmVxdWlyZW1lbnRzIG9mIGRyYWZ0LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhIGFwcGx5LCB3 aGVuIGl0IHNob3VsZCBiZQ0KYWJzb2x1dGVseSBjbGVhciB0aGF0IG9ubHkgdGhlIGZvcm1lciBh cHBseS4NCg0KUmVnYXJkcw0KDQpLZWl0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SXZvIFNlZGxhY2VrDQpTZW50OiAxMCBBdWd1c3QgMjAxNiAwODo0MQ0KVG86IFBhdWwgS3l6aXZh dDsgZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtF Y3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIG5vdA0KYWxp Z25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2Fs bC1JbmZvDQp1c2FnZSBicmluZ3Mgbm8gdmFsdWUpDQoNCkhlbGxvLA0KDQoNClRoZSBpbnZpdGUg cmVzcG9uc2Ugc3RpbGwgaGFzIGEgYm9keSB3aXRoIGNvbnRlbnQtZGlzcG9zaXRpb24NCmJ5LXJl ZmVyZW5jZS4gSWYgeW91IHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRoZW4gaXRzIHByb2Nlc3Npbmcg aXMNCnVuZGVmaW5lZC4NCg0KSWYgdGhlIENhbGwtSW5mbyBpcyBvbWl0dGVkIGluIElOVklURSBy ZXNwb25zZSwgdGhlbjoNCkFsdDE6IGEgbmV3IHZhbHVlIGNvdWxkIGJlIGRlZmluZWQgYW5kIHVz ZWQgaW4gdGhlDQpDb250ZW50LURpc3Bvc2l0aW9uIGhlYWRlciBmaWVsZCBvZiB0aGUNCmFwcGxp Y2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wreG1sIGJvZHk7DQogICAgICAg ICAgICBvcg0KQWx0MjogYW4gZXhpc3RpbmcgdmFsdWUgY291bGQgYmUgdXNlZCBpbiB0aGUgQ29u dGVudC1EaXNwb3NpdGlvbg0KaGVhZGVyIGZpZWxkIG9mIHRoZSBhcHBsaWNhdGlvbi9lbWVyZ2Vu Y3lDYWxsRGF0YS5lQ2FsbC5jb250cm9sK3htbA0KYm9keTsNCiAgICAgICAgICAgIG9yDQpBbHQz OiB0aGUgQ29udGVudC1EaXNwb3NpdGlvbiBoZWFkZXIgZmllbGQgY2FuIGJlIG9taXR0ZWQgYW5k IHRodXMNCiJyZW5kZXIiIHdvdWxkIGFwcGx5IGZvciB0aGUNCmFwcGxpY2F0aW9uL2VtZXJnZW5j eUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wreG1sIGJvZHkgYWNjb3JkaW5nIHRvDQpSRkMzMjYxIHNl Y3Rpb24gMTMuMi4xLg0KDQpXZSBjYW5ub3QgdXNlIHRoZSBDYWxsLUluZm8gaW4gSU5WSVRFIHJl c3BvbnNlIGFzIGRlc2NyaWJlZCBpbg0KZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMSAtIGluIHRo ZSByZXNwb25zZSB0byB0aGUgSU5WSVRFIHJlcXVlc3QsIHRoZQ0KQ2FsbC1JbmZvIHBvaW50cyB0 byB0aGUNCmFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNvbnRyb2wreG1sIGJv ZHkuIFRoaXMgYm9keQ0KY29udGFpbnMgYSBkZWxpdmVyeSByZXBvcnQgZm9yIHRoZSBNU0Qgc2Vu dCBpbiBJTlZJVEUgcmVxdWVzdC4gVGhpcyBpcw0KTk9UIGluZm9ybWF0aW9uIGFib3V0IGNhbGxl ZSBhcyBkZXNjcmliZWQgaW4gUkZDMzI2MS4NCg0KS2luZCByZWdhcmRzDQoNCkl2bw0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWls aW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRA aWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCi0tDQpSYW5kYWxsIEdlbGxlbnMNCk9waW5pb25zIGFy ZSBwZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBv bmx5DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0t LSBUaGUgaWRlYSB0aGF0IEJpbGwgR2F0ZXMgaGFzIGFwcGVhcmVkIGxpa2UgYSBrbmlnaHQgaW4g c2hpbmluZyBhcm1vciB0byBsZWFkIGFsbCBjdXN0b21lcnMgb3V0IG9mIGEgbWlyZSBvZiB0ZWNo bm9sb2dpY2FsIGNoYW9zIG5lYXRseSBpZ25vcmVzIHRoZSBmYWN0IHRoYXQgaXQgd2FzIGhlIHdo bywgYnkgcGVkZGxpbmcgc2Vjb25kLXJhdGUgdGVjaG5vbG9neSwNCmxlZCB0aGVtIGludG8gaXQg aW4gdGhlIGZpcnN0IHBsYWNlLiAgICAgICAgICAgICAgICAgICAgLS1Eb3VnbGFzIEFkYW1zDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBt YWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADF451E6FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB0aGluayBpdCB0aGUgaW5jbHVzaW9uIG9mIENhbGwtSW5mbyBpbiBJTkZP IHJlcXVlc3RzIGludHJvZHVjZXMgYWRkaXRpb25hbCBjb21wbGV4aXRpZXMgaW4gcHJvdG9jb2wg cHJvY2Vzc2luZywgd2hpY2ggY291bGQgcmVzdWx0IGluIHRoZSBkYXRhIGVsZW1lbnQgbm90DQog YmVpbmcgcHJvY2Vzc2VkLCB3aGljaCBpbiBteSB2aWV3IGlzIGhhcm1mdWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiBmb3IgZXhhbXBsZSwgdGhlIENhbGwtSW5mbyBpcyBzZW50IHdpdGggYSBvbmUgY2hhcmFjdGVy IGVycm9yIGluIHRoZSByZWZlcmVuY2UgdGV4dCAodGhlIGhlYWRlciBmaWVsZCB2YWx1ZSksIHdl IGNvdWxkIHdlbGwgZW5kIHVwIHdpdGggdGhlIHJlY2lwaWVudCBkcm9wcGluZw0KIHRoZSBkYXRh IGVsZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5LZWVwaW5nIGl0IHNpbXBsZSBtZWFucyBub3QgaW5jbHVkaW5n IGFueXRoaW5nIGJleW9uZCB0aGF0IHJlcXVpcmVkIGJ5IHRoZSBTSVAgcGFydCBvZiB0aGUgZGF0 YSB0cmFuc2ZlciBwcm90b2NvbC4gVGhhdCBwcm90b2NvbCBpcyB0aGUgSU5GTyBtZWNoYW5pc20g d2l0aA0KIHRoZSBhcHByb3ByaWF0ZSBwYWNrYWdlIGRlZmluaXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRv IGFncmVlIHRoYXQgd2UgY291bGQgZG8gbW9yZSBpbiB0aGUgZHJhZnQgdG8gc3RyZXNzIHRoYXQg d2UgZG8gaGF2ZSB0d28gZW50aXJlbHkgc2VwYXJhdGUgU0lQIGRhdGEgdHJhbnNmZXIgbWVjaGFu aXNtIOKAkyBvYnZpb3VzbHkgYm90aCBjb250YWluIE1TRHMsIGNvZGVkDQogdXNpbmcgdGhlIHNh bWUgc3ludGF4LCBidXQgdGhlIHN1cnJvdW5kaW5nIHByb3RvY29sIGlzIGRpZmZlcmVudC4gQXMg YSByZXN1bHQgdGhlIGVycm9yIGhhbmRsaW5nIGlzIHRoYXQgZGVmaW5lZCBmb3IgZWFjaCBpbmRp dmlkdWFsIHRyYW5zZmVyIG1lY2hhbmlzbSwgYW5kIG5vdCBjYXJyaWVkIG92ZXIgdG8gdGhlIG90 aGVyLiBEYXRhIGZyb20gdGhlIHR3byBzZXBhcmF0ZSBtZWNoYW5pc20gaXMgb25seSBjb21iaW5l ZCBpbiBhIGxheWVyIGFib3ZlDQogdGhlIFNJUCBhY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3Qg YmVsaWV2ZSB0aGUgTUlNRSB0eXBlIG5lZWRzIHRvIGJlIGRpZmZlcmVudCwgdGhlIE1JTUUgdHlw ZSBkZXNjcmliZXMgdGhlIGJvZHkgc3ludGF4IGFuZCB0aGUgYm9keSBpcyBvbmUgYW5kIHRoZSBz YW1lIChhdCB0aGUgbW9tZW50KS4gV2UgYXJlIGRpc2N1c3NpbmcNCiBDYWxsLUluZm8gdmVyc3Vz IHRoZSBJbmZvLVBhY2thZ2UgaGVhZGVyIGZpZWxkcywgYm90aCBvZiB3aGljaCBwZXJmb3JtIHNp bWlsYXIgdGFza3MgaW4gaWRlbnRpZnlpbmcgYSBib2R5IGFuZCB0aGUgdXNhZ2UgaXQgYmVsb25n cyB0bywgZWFjaCBmb3IgaXRzIGFwcHJvcHJpYXRlIGRhdGEgdHJhbnNmZXIgbWVjaGFuaXNtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+S2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFY3JpdCBbbWFpbHRvOmVjcml0LWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIFJvc2VuPGJyPg0KPGI+ U2VudDo8L2I+IDEwIEF1Z3VzdCAyMDE2IDE4OjQ1PGJyPg0KPGI+VG86PC9iPiBFbWVyZ2VuY3kg Q29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24g TGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVj YWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6 IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8gdmFs dWUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBm b3IgdGhlIG1vbWVudCwgcHV0IGFzaWRlIGFueSBzcGVjaWZpYyBpc3N1ZXMgd2l0aCBlQ2FsbC48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzU4NTZENiI+PGJyPg0KPC9zcGFuPldlL3ZlIGFncmVlZCB0aGF0IGlmIG9uZSBuZWVk cyBhIG1pZC1jYWxsIHVwZGF0ZSBvZiBBZGRpdGlvbmFsIERhdGEsIHRoYXQgb25lIGRlZmluZXMg YSBuZXcgSU5GTyBwYWNrYWdlIGFuZCB1c2VzIHRoYXQgdG8gc2VuZCBzdWNoIGFuIHVwZGF0ZS48 YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4NTZENiI+PGJyPg0KPC9zcGFuPlVzZSBzb21lIGNh c2UgbGlrZSBhbGFybSBkYXRhOiB5b3UgZ2V0IGFsYXJtIHN0YXR1cyB3aGVuIHRoZSBJTlZJVEUg YXJyaXZlcyB3aXRoIGEgY2FsbCwgYW5kIHlvdSBjYW4gZ2V0IGFuIHVwZGF0ZSBvZiB0aGF0IGFs YXJtIGRhdGEgbWlkIGNhbGwgdXNpbmcgSU5GTy48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4 NTZENiI+PGJyPg0KPC9zcGFuPkluIHRoZXNlIGNhc2VzLCB0aGUgRVhBQ1Qgc2FtZSBkYXRhIGlz IGJlaW5nIHNlbnQsIGZvciB0aGUgZXhhY3Qgc2FtZSB1c2UsIHdpdGggdGhlIG9ubHkgZGlmZmVy ZW5jZSBiZWluZyBtaWQgY2FsbCB2cyBjYWxsIGVzdGFibGlzaG1lbnQuICZuYnNwO1RoYXTigJlz IHZlcnkgY2xlYXJseSBBZGRpdGlvbmFsIERhdGEuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1 ODU2RDYiPjxicj4NCjwvc3Bhbj5TaG91bGQgdGhlIE1JTUUgdHlwZSBiZSBkaWZmZXJlbnQgZm9y IHRoZXNlIHVzZSBjYXNlcz88YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4NTZENiI+PGJyPg0K PC9zcGFuPklzIHRoZSBtaWQgY2FsbCB1cGRhdGUgZGlmZmVyZW50IGZyb20gdGhlIGNhbGwgZXN0 YWJsaXNobWVudCBpbiBhbnkgcmVzcGVjdCBvdGhlciB0aGFuIHRoZSBzaXAgbWVzc2FnZSB1c2Vk Pzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNTg1NkQ2Ij48YnI+DQo8L3NwYW4+SSBhZ3JlZSB0 aGF0IGluY2x1ZGluZyB0aGUgQ2FsbC1JbmZvIGlzIGR1cGxpY2F0aXZlIG9mIHRoZSBJTkZPLCBi dXQgaXMgaXQgaGFybWZ1bD88YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzU4NTZENiI+PGJyPg0K PC9zcGFuPklzIGVDYWxsIHNvIGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50IHRoYXQgaXQgd2FycmFu dHMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBhbnN3ZXI/PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiM1ODU2RDYiPjxicj4NCjwvc3Bhbj5Ccmlhbjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNTg1 NkQ2Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gQXVnIDEwLCAyMDE2LCBhdCAxOjI5IFBNLCBEcmFnZSwgS2VpdGggKE5v a2lhIC0gR0IpICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29tIj5rZWl0 aC5kcmFnZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpJIGRpc2FncmVlLjxi cj4NCjxicj4NClRoZSBpbmNsdXNpb24gb2YgdGhlIGRhdGEgZWxlbWVudCBpbiBJTkZPIGlzIG5v dGhpbmcgdG8gZG8gd2l0aCBSRkMgNzg1Mi4gVGhlIGRhdGEgZWxlbWVudCBpcyBpbmNsdWRlZCBi ZWNhdXNlIHRoZSB1c2Ugb2YgYW4gYXBwcm9wcmlhdGUgSW5mbyBwYWNrYWdlIGhhcyBiZWVuIG5l Z290aWF0ZWQgYW5kIHVzZWQuIFRoYXQgSW5mbyBwYWNrYWdlIGRlZmluaXRpb24gYW5kIHRoZSBJ TkZPIG1lY2hhbmlzbSBpdHNlbGYgbWFrZXMgbm8gbWVudGlvbiBvZg0KIHVzZSBvZiBDYWxsLUlu Zm8gaW4gYXNzb2NpYXRpb24gd2l0aCBpdC4gPGJyPg0KPGJyPg0KRnVydGhlciBJIHNlZSBubyBq dXN0aWZpY2F0aW9uIGZvciBjb21wbGljYXRpbmcgYW55IGVycm9yIGhhbmRsaW5nIGJ5IHN1ZGRl bmx5IGRlZmluaW5nIGl0IHRvIGJlIGFwcGxpY2FibGUsIGFzIGl0IGlzIG5vdCBuZWNlc3Nhcnku IElORk8gcmVxdWVzdHMgYWx3YXlzIGNvbnRhaW4gYSBkYXRhIGVsZW1lbnQgYXBwcm9wcmlhdGUg dG8gdGhlIEluZm8gcGFja2FnZSB0aGF0IGlzIGRlZmluZWQgZm9yIGl0cyB1c2UgLSBpdCBhYnNv bHV0ZWx5IGRvZXMNCiBub3QgbmVlZCBhIHNlY29uZGFyeSByZWZlcmVuY2UgdG8gdGhlIHBhY2th Z2UuPGJyPg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IFJhbmRhbGwgR2VsbGVucyBbPGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRm QHJhbmR5LnBlbnNpdmUub3JnIj5tYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8 L2E+XQ0KPGJyPg0KU2VudDogMTAgQXVndXN0IDIwMTYgMTg6MjA8YnI+DQpUbzogRHJhZ2UsIEtl aXRoIChOb2tpYSAtIEdCKTsgSXZvIFNlZGxhY2VrOyBQYXVsIEt5eml2YXQ7IDxhIGhyZWY9Im1h aWx0bzplY3JpdEBpZXRmLm9yZyI+DQplY3JpdEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBS ZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTExLSBDYWxsLUluZm8gdXNhZ2Ugbm90 IGFsaWduZWQgd2l0aCBSRkMzMjYxICh3YXMgUkU6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEt IENhbGwtSW5mbyB1c2FnZSBicmluZ3Mgbm8gdmFsdWUpPGJyPg0KPGJyPg0KSGkgS2VpdGgsPGJy Pg0KPGJyPg0KQXQgMzoxMSBQTSAmIzQzOzAwMDAgOC8xMC8xNiwgS2VpdGggKE5va2lhIC0gR0Ip IERyYWdlIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VW5sZXNzIHNvbWVvbmUgaXMgZGVmaW5pbmcgYSBuZXcgdXNhZ2UgZm9yIENh bGwtSW5mbyBiZXlvbmQgUkZDNzg1Mg0KPGJyPg0KdGhlbiBJIGhhdmUgdG8gYWdyZWUgd2l0aCBJ dm8uIFRoYXQgYWRkaXRpb25hbCB1c2FnZSBpcyBub3QgY3VycmVudGx5IDxicj4NCmRlZmluZWQg aW4gZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCwgYW5kIEkgd291bGQgbmVlZCB0byB1bmRlcnN0YW5k IHRoYXQgPGJyPg0KdXNhZ2UgYmVmb3JlIGl0IGlzIGluY2x1ZGVkLjxicj4NCjxicj4NCkF0IHRo ZSBtb21lbnQgUkZDNzg1MiBpcyBvbmx5IHVzZWQgZm9yIHRoZSB0cmFuc2ZlciBvZiBNU0QgaW4g SU5WSVRFIDxicj4NCnJlcXVlc3RzIGFuZCAyMDAgKE9LKSByZXNwb25zZXMsIGFuZCB0aGVyZWZv cmUgdGhhdCBpcyB0aGUgb25seSBwbGFjZSA8YnI+DQp3aGVyZSBpdCBzaG91bGQgYXBwZWFyIGlu IGFzc29jaWF0aW9uIHdpdGggUkZDNzg1Mi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NClJGQyA3ODUyIGNvdmVycyB1c2Ugb2YgQ2FsbC1JbmZvIHRvIHBvaW50IHRv IGVtZXJnZW5jeSBjYWxsIGRhdGEgYmxvY2tzIGluIGFueSBTSVAgbWVzc2FnZSB0aGF0IGlzIHBl cm1pdHRlZCB0byBjYXJyeSBhIGJvZHkuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpOZWdvdGlhdGlvbiBhbmQgdHJhbnNmZXIgb2Yg TVNEIGluIGFzc29jaWF0aW9uIHdpdGggSU5GTyByZXF1ZXN0cyBpcyA8YnI+DQphbiBlbnRpcmVs eSBzZXBhcmF0ZSB0cmFuc2ZlciBtZWNoYW5pc20sIG5vdCBjb3ZlcmVkIGJ5IDxicj4NCmRyYWZ0 LWlldGYtZWNyaXQtZGF0YS1vbmx5LWVhIGFuZCB0aGVyZWZvcmUgaXQgc2hvdWxkIG5ldmVyIGFw cGVhciA8YnI+DQp0aGVyZSBhcyB0aG91Z2ggaXQgaGFkIGJlZW4uIEluY2x1c2lvbiB3aWxsIGxl YWQgdG8gY29tcGxldGUgY29uZnVzaW9uIDxicj4NCmFzIHRvIHdoZXRoZXIgdGhlIHJlcXVpcmVt ZW50cyBvZiB0aGUgSU5GTyBtZWNoYW5pc20gb3IgdGhlIDxicj4NCnJlcXVpcmVtZW50cyBvZiBk cmFmdC1pZXRmLWVjcml0LWRhdGEtb25seS1lYSBhcHBseSwgd2hlbiBpdCBzaG91bGQgYmUgPGJy Pg0KYWJzb2x1dGVseSBjbGVhciB0aGF0IG9ubHkgdGhlIGZvcm1lciBhcHBseS48YnI+DQo8YnI+ DQpSZWdhcmRzPGJyPg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCkZyb206IEVjcml0IFs8YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg SXZvIFNlZGxhY2VrPGJyPg0KU2VudDogMTAgQXVndXN0IDIwMTYgMDg6NDE8YnI+DQpUbzogUGF1 bCBLeXppdmF0OyA8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3Jn PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEt IENhbGwtSW5mbyB1c2FnZSBub3QgPGJyPg0KYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTog ZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIDxicj4NCnVzYWdlIGJyaW5ncyBu byB2YWx1ZSk8YnI+DQo8YnI+DQpIZWxsbyw8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbnZpdGUgcmVzcG9uc2Ugc3RpbGwgaGFzIGEg Ym9keSB3aXRoIGNvbnRlbnQtZGlzcG9zaXRpb24NCjxicj4NCmJ5LXJlZmVyZW5jZS4gSWYgeW91 IHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRoZW4gaXRzIHByb2Nlc3NpbmcgaXMgPGJyPg0KdW5kZWZp bmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSWYgdGhlIENh bGwtSW5mbyBpcyBvbWl0dGVkIGluIElOVklURSByZXNwb25zZSwgdGhlbjo8YnI+DQpBbHQxOiBh IG5ldyB2YWx1ZSBjb3VsZCBiZSBkZWZpbmVkIGFuZCB1c2VkIGluIHRoZSA8YnI+DQpDb250ZW50 LURpc3Bvc2l0aW9uIGhlYWRlciBmaWVsZCBvZiB0aGUgPGJyPg0KYXBwbGljYXRpb24vZW1lcmdl bmN5Q2FsbERhdGEuZUNhbGwuY29udHJvbCYjNDM7eG1sIGJvZHk7PGJyPg0KPHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm9yPGJyPg0KQWx0MjogYW4gZXhpc3Rp bmcgdmFsdWUgY291bGQgYmUgdXNlZCBpbiB0aGUgQ29udGVudC1EaXNwb3NpdGlvbiA8YnI+DQpo ZWFkZXIgZmllbGQgb2YgdGhlIGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLmNv bnRyb2wmIzQzO3htbDxicj4NCmJvZHk7PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPm9yPGJyPg0KQWx0MzogdGhlIENvbnRlbnQtRGlzcG9zaXRpb24g aGVhZGVyIGZpZWxkIGNhbiBiZSBvbWl0dGVkIGFuZCB0aHVzIDxicj4NCiZxdW90O3JlbmRlciZx dW90OyB3b3VsZCBhcHBseSBmb3IgdGhlIDxicj4NCmFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxE YXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbCBib2R5IGFjY29yZGluZyB0bzxicj4NClJGQzMyNjEg c2VjdGlvbiAxMy4yLjEuPGJyPg0KPGJyPg0KV2UgY2Fubm90IHVzZSB0aGUgQ2FsbC1JbmZvIGlu IElOVklURSByZXNwb25zZSBhcyBkZXNjcmliZWQgaW48YnI+DQpkcmFmdC1pZXRmLWVjcml0LWVj YWxsLTExIC0gaW4gdGhlIHJlc3BvbnNlIHRvIHRoZSBJTlZJVEUgcmVxdWVzdCwgdGhlIDxicj4N CkNhbGwtSW5mbyBwb2ludHMgdG8gdGhlIDxicj4NCmFwcGxpY2F0aW9uL2VtZXJnZW5jeUNhbGxE YXRhLmVDYWxsLmNvbnRyb2wmIzQzO3htbCBib2R5LiBUaGlzIGJvZHkgPGJyPg0KY29udGFpbnMg YSBkZWxpdmVyeSByZXBvcnQgZm9yIHRoZSBNU0Qgc2VudCBpbiBJTlZJVEUgcmVxdWVzdC4gVGhp cyBpcyA8YnI+DQpOT1QgaW5mb3JtYXRpb24gYWJvdXQgY2FsbGVlIGFzIGRlc2NyaWJlZCBpbiBS RkMzMjYxLjxicj4NCjxicj4NCktpbmQgcmVnYXJkczxicj4NCjxicj4NCkl2bzxicj4NCjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3Jn Ij5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOkVjcml0QGlldGYub3JnIj5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS08YnI+DQpSYW5kYWxsIEdlbGxlbnM8YnI+DQpPcGlu aW9ucyBhcmUgcGVyc29uYWw7ICZuYnNwOyZuYnNwOyZuYnNwO2ZhY3RzIGFyZSBzdXNwZWN0OyAm bmJzcDsmbmJzcDsmbmJzcDtJIHNwZWFrIGZvciBteXNlbGYgb25seTxicj4NCi0tLS0tLS0tLS0t LS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tIFRoZSBpZGVhIHRoYXQg QmlsbCBHYXRlcyBoYXMgYXBwZWFyZWQgbGlrZSBhIGtuaWdodCBpbiBzaGluaW5nIGFybW9yIHRv IGxlYWQgYWxsIGN1c3RvbWVycyBvdXQgb2YgYSBtaXJlIG9mIHRlY2hub2xvZ2ljYWwgY2hhb3Mg bmVhdGx5IGlnbm9yZXMgdGhlIGZhY3QgdGhhdCBpdCB3YXMgaGUgd2hvLCBieSBwZWRkbGluZyBz ZWNvbmQtcmF0ZSB0ZWNobm9sb2d5LDxicj4NCmxlZCB0aGVtIGludG8gaXQgaW4gdGhlIGZpcnN0 IHBsYWNlLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDstLURvdWdsYXMgQWRhbXM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADF451E6FR712WXCHMBA11z_-- From nobody Wed Aug 10 13:37: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 3DFE2126FDC for ; Wed, 10 Aug 2016 13:37: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 pbT36Ua6537l for ; Wed, 10 Aug 2016 13:37:02 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1AD12D587 for ; Wed, 10 Aug 2016 13:37:02 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 13:37:01 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> <949EF20990823C4C85C18D59AA11AD8BADF44F1A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 13:36:56 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 20:37:04 -0000 implementations can mess up in an almost infinite=20 variety of ways. Call-Info could indicate a=20 different block than actually present. The MIME=20 type of a body part could be incorrect. A data=20 object could be malformed. Since our context is=20 emergency calls, in general the call won't be=20 failed and the SIP message won't be rejected.=20 RFC 7852 contains language regarding this. --Randy At 3:22 PM +0000 8/10/16, Christer Holmberg wrote: > Hi, > > >I don't believe it is "useless". > > > > > >I believe it is dangerous because it=20 > introduces an interaction between two separate=20 > protocol mechanisms. > > > Correct, and I earlier said that we'd have to=20 > define what happens if there e.g. is a=20 > missmatch between the mechanisms. > > What I meant by "useless" is that since the=20 > content disposition type of the INFO message=20 > bodies are "info package", there is no=20 > reference to the Call-Info header fields - the=20 > semantics must be defined in the info package=20 > description. > > Regards, > > Christer > > > > > From: Ecrit=20 > [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Christer Holmberg > Sent: 10 August 2016 14:09 > To: Rosen, Brian; Emergency Context Resolution=20 > with Internet Technologies Discussion List > Subject: Re: [Ecrit] Fwd:=20 > draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE:=20 > draft-ietf-ecrit-ecall-11- Call-Info usage=20 > brings no value) > > > > Hi, > > > > =8A > > > > >I acknowledge that it's not needed with the=20 > INFO package, but I think it does no harm, and=20 > makes the entire mechanism consistent with all=20 > the other parts of additional data > > > > No, it doesn't. We don't use the "by-reference"=20 > disposition type in INFO, so there would not be=20 > a reference between the Call-Info value and the=20 > message body. Message bodies associated with=20 > info packages have the "info-package"=20 > disposition type, and the semantics are covered=20 > by the info package specification. > > > > So, the information is useless. > > > > Regards, > > > > Christer > > > > > > Begin forwarded message: > > > > From: Ivo Sedlacek=20 > <ivo.sedlacek@ericsson.com> > > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11-=20 > Call-Info usage not aligned with RFC3261 (was=20 > RE: draft-ietf-ecrit-ecall-11- Call-Info usage=20 > brings no value) > > Date: August 10, 2016 at 3:32:00 AM EDT > > To: "Rosen, Brian"=20 > <Brian.Rosen@neustar.biz>,=20 > Randall Gellens=20 > <rg+ietf@randy.pensive.org> > > > > Hello, > > In the response to the INVITE request, the=20 > Call-Info points to the=20 > application/emergencyCallData.eCall.control+xml=20 > body. This body contains a delivery report for=20 > the MSD sent in INVITE request. This is NOT=20 > information about callee. Thus, RFC3261=20 > semantic is not fulfilled. > > In the INFO request, the Call-Info points to=20 > the=20 > application/emergencyCallData.eCall.control+xml=20 > body. This body describes an action to be=20 > performed at the remote UE. This is NOT=20 > information about the sender of the INFO=20 > request. Thus, RFC3261 semantic is not=20 > fulfilled. Also, as other people indicated,=20 > this is not needed with info package mechanism. > > Kind regards > > Ivo > > -----Original Message----- > From: Rosen, Brian=20 > [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, August 09, 2016 11:22 PM > To: Randall Gellens > Cc: Ivo Sedlacek > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11-=20 > Call-Info usage not aligned with RFC3261 (was=20 > RE: draft-ietf-ecrit-ecall-11- Call-Info usage=20 > brings no value) > > I strongly agree. > > It's small cost and I think a substantial=20 > benefit to treat all the blocks as additional=20 > data blocks, put them in the registry, etc.=20 > INFO is a solution to a mid-call need to send=20 > additional data, and we should treat it that=20 > way in my opinion. > > We can state that the block reference in the=20 > INFO package must match that in the Call-Info. > > Brian > > On Aug 9, 2016, at 1:22 PM, Randall Gellens=20 > <rg+ietf@randy.pensive.org>=20 > wrote: > > I prefer to keep the use of Call-Info for all=20 > three cases (INVITE, response, INFO) to=20 > maintain compatibility with RFC 7852=20 > (Additional Data) and car-crash (North American=20 > NG-AACN). I see benefit without any real-world=20 > harm in using Call-Info even if not strictly=20 > necessary (e.g., INFO). > > --Randy > > At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: > > Hello, > > given the use case raised by Roland and=20 > clarified by Paul, let me suggest the following=20 > compromise: > > Call-Info included in an INVITE request and=20 > pointing to the=20 > application/emergencyCallData.eCall.MSD+per=20 > body of the INVITE request is kept, while=20 > Call-Info in a response to the INVITE request=20 > and in an INFO request is removed. > > Does this work for everyone? > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org >=20 > https://www.ietf.org/mailman/= listinfo/ecrit > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- I hold that the > very purpose of existence is to reconcile the glowing opinion we have > of ourselves with the terrible things > that other people say about us. --Quentin Crisp > > > > > > > _______________________________________________ > 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: --------------- Ever notice that people who are late are much jollier than the people who have to wait for them? From nobody Wed Aug 10 14:31: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 9A19612D881 for ; Wed, 10 Aug 2016 14:31: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 osaOCeGEfe7h for ; Wed, 10 Aug 2016 14:31:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE4212D877 for ; Wed, 10 Aug 2016 14:31:05 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 14:31:03 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF44F13@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F13@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 14:30:59 -0700 To: "Drage, Keith (Nokia - GB)" , "R.Jesske@telekom.de" , "ivo.sedlacek@ericsson.com" , "pkyzivat@alum.mit.edu" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:31:07 -0000 I see it as one data transfer mechanism, which has additional restrictions/impositions when used with INFO. INFO has various prohibitions and restrictions and mandates in an attempt to reign in the former freewheeling use of INFO as a generic data transfer mechanism. In our case, we're using INFO only for mid-call updates, and only because it seemed at the time to be cleaner than using re-INVITE or UPDATE or OPTIONS or something else. If we diverge into two entirely separate mechanisms, one just for INFO, then we will do a disservice to emergency call processing. At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > > I fundamentally disagree. We have two different data transfer > mechanisms, and the presence of the data should be clearly > understood from the appropriate transfer mechanism protocol. > > So Call-Info applies when RFC 7852 applies, which is the INVITE and > 200 (OK) response, and does not when the INFO mechanism is in use. > > Additionally it only applies when it is pointing to data which is > actually attached to the message. > > Keith > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 08 August 2016 10:45 > To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hi Ivo, > using the ecall urn (urn:service:sos.ecall.automatic) does not > implicitly means using the MSD within the Body. It could be also an > interworked call where all ecall information is included inband > using the In-band modem solution. > > We have to think also on backwards compatibility issues. Thus when > moving PSAP's to SIP imply also that there must exist an > interworking between the old mobile world towards the new mobile > world using SIP. > > Using the Call-Info header would help the PAST to distinguish the > in-band and outband solution. Perhaps it would be worth to define > an additional value for inband data, to identify ecalls coming from > other networks not supporting the MSD Body. > > Best Regards > > Roland. > > > Von: Ecrit > [mailto:ecrit-bounces@ietf.org] Im > Auftrag von Ivo Sedlacek > Gesendet: Montag, 8. August 2016 09:59 > An: Paul Kyzivat; ecrit@ietf.org > Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hello, > > According to RFC3261, the Call-Info header field provides > additional information about the caller or callee. > > According to draft-ietf-ecrit-ecall-11, the Call-Info header field > is used to form a "content-table" of pointers to bodies INVITE > request (and of INVITE response, of INFO request) in headers of > INVITE request (and of INVITE response, of INFO request). > > If the Call-Info header field points to a body which describes the > callers or callee, then Call-Info semantic fits (even though I > would still question usefulness of such Call-Info inclusion). > > If the Call-Info header field points to a body which request an > action in remote UE and which reports to remote UE an outcome of an > action done by the local UE, then Call-Info semantic does not fit. > > Particularly: > > ------------------------------------------------------------------------------ > A PSAP or IVS transmits a metadata/control object (see Section 9) by > encoding it per the description in this document and attaching it to > a SIP message as a MIME body part per [RFC7852]. The body part is > identified by its MIME content-type ('application/ > emergencyCallData.eCall.control+xml') in the Content-Type header > field of the body part. The body part is assigned a unique > identifier which is listed in a Content-ID header field in the body > part. The SIP message is marked as containing the metadata/control > object by adding (or appending to) a Call-Info header field at the > top level of the SIP message. This Call-Info header field contains a > CID URL referencing the body part's unique identifier, and a > 'purpose' parameter identifying the data as an eCall metadata/control > block per the Emergency Call Additional Data Blocks registry entry; > the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. > > ------------------------------------------------------------------------------ > and > > ------------------------------------------------------------------------------ > SIP/2.0 200 OK > To: > <sip:+13145551111@example.com>;tag=9fxced76sl > From: Exemplar PSAP > Call-ID: > 3848276298220188511@atlanta.example.com > Call-Info: > cid:2345678901@atlanta.example.com; > purpose=emergencyCallData.eCall.control; > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml, > application/emergencyCallData.eCall.MSD+per > CSeq: 31862 INVITE > Recv-Info: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Type: multipart/mixed; boundary=boundaryX > Content-Length: ... > > --boundaryX > Content-Type: application/sdp > > ...Session Description Protocol (SDP) goes here... > > --boundaryX > Content-Type: application/EmergencyCallData.eCall.control+xml > Content-ID: > 2345678901@atlanta.example.com > Content-Disposition: by-reference;handling=optional > > > xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation= > "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> > > ref="1234567890@atlanta.example.com"/> > > > > --boundaryX-- > > ------------------------------------------------------------------------------ > > Kind regards > > Ivo > > -----Original Message----- > From: Ecrit > [mailto:ecrit-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, August 05, 2016 4:43 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage > brings no value > > Ivo, > > IIUC, you are saying that the Call-Info that refers to the body is > unnecessary because the recipient will know what to do with the > body even in the absence of the Call-Info. Is that right? > > This assumption mixes up two things: > - understanding a body syntactically > - understanding *why* the body is present and how it should be used. > > Historically, processing of body parts in sip was very poorly defined. > Initially the only body of interest was SDP, so how one might > process other bodies or body parts was not well considered. > Eventually this started to be a liability, so RFC5621 was published > to clarify it. > > Processing of body parts is governed by a complex interaction > between Content-Type, Content-Disposition, Content-ID. > > So the call-info header indicates the reason that body is being > included. I realize that there is one predominant reason for doing > so, but that is not the only possible reason. (E.g., it might be > included as context in an intended discussion about problems > handling a call in the > past.) > > If all the handling of the call is coded in a special purpose way, > solely for the emergency call path, then alternatives may be of no > concern. But ideally the call will largely be handled via standard > library code that is also used for other call paths and other > message processing. So processing body parts in a "standard" way, > rather than special casing, is desirable. > > Thanks, > Paul > > On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > > Hello, > > > > > > > > COMMENT: > > > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > \\\\\\\\ > > > > Inclusion of Call-Info header field with > > purpose=emergencyCallData.eCall.MSD or > > purpose=emergencyCallData.eCall.control in requests and responses does > > not seem to bring any value. It seems to only waste radio resources. > > > > > > > > For Call-Info with purpose=emergencyCallData.eCall.MSD included in the > > initial INVITE request: > > > > - if this is meant to be used by a proxy for routing of the eCall > > emergency call to a PSAP supporting eCall emergency call, then this > > seems to be redundant to the eCall URN included in the Request-URI and > > the Recv-Info header field containing eCall specific info package > > (emergencyCallData.eCall.MSD). > > > > - if this is meant to be used by UAS (i.e. PSAP), then according to > > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > > the bodies of the INVITE request not marked with Content-Disposition: > > ...; handling=optional are understood. So, > > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > > found by UAS during the INVITE request processing. > > > > > > > > For Call-Info with purpose=emergencyCallData.eCall.control included in > > a response to the initial INVITE request > > > > - no routing decisions are done by proxies when receiving a response > > to the initial INVITE request so this does not seem to have any value > > for the proxies > > > > - UAC includes Accept with supported MIME types in INVITE request so > > why would UAS send any MIME body not wished by the UAC? > > > > > > > > For Call-Info with purpose=emergencyCallData.eCall.control included in > > the INFO request > > > > - no routing decisions are done by proxies when receiving an in-dialog > > request so this does not seem to have any value for the proxies > > > > - support of info package emergencyCallData.eCall.MSD in the call > > implies that either application/EmergencyCallData.eCall.control+xml > > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > > needs to check that all the bodies of the INFO request not marked with > > Content-Disposition: ...; handling=optional are understood. So, > > application/EmergencyCallData.eCall.control+xml MIME body or > > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > > found by UAS during the INFO request processing. > > > > ////////////////////////////////////////////////////////////////////// > > //////// > > > > PROPOSED SOLUTION to COMMENT > > > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > \\\\\\\\ > > > > Remove insertion of Call-Info header field. > > > > ////////////////////////////////////////////////////////////////////// > > //////// > > > > > > > > Kind regards > > > > > > > > Ivo Sedlacek > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I asked President Reagan what he thought about the IBM PC Jr., and he replied that he didn't believe in abortions --Steve Wozniac From nobody Wed Aug 10 14:32: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 6478312D873 for ; Wed, 10 Aug 2016 14:32:07 -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 QURmi3ZMm6R5 for ; Wed, 10 Aug 2016 14:32:03 -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 4A7E512D877 for ; Wed, 10 Aug 2016 14:32:02 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B3E5CA43DB527; Wed, 10 Aug 2016 21:31:56 +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 u7ALVxED003828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Aug 2016 21:32:00 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7ALUn3c027588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Aug 2016 23:31:58 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 10 Aug 2016 23:30:46 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR80b/Afd2EPXlp0GSSqkBVzdLAKBCs5PA Date: Wed, 10 Aug 2016 21:30:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF453AF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> <949EF20990823C4C85C18D59AA11AD8BADF44F1A@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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:32:07 -0000 I think we have to be absolutely clear. RFC 7852 DOES NOT apply in the case of the data element attached to an INFO packa= ge in support of ecrit. I thought we had reached agreement that when INFO was used, then an Info pa= ckage would be defined and the rules for supporting an Info Package would b= e used. Attempting to suggest that a Call-Info is used appears to me to per= sisting in the previous attempt to reuse INFO in support of something that = is not an Info package. In respect of an Info-Package usage, Call-Info has no semantic meaning, and= to me that is an implicit message to any protocol implementor never to inc= lude it. Of course you may be trying to hint that somehow the use of the Call-Info h= as some semantic meaning across messages (following some of Brian's comment= s on same usage from one message to another), but that semantic does not ex= ist in RFC 7852 and has never been defined. RFC 7852 usage applies only to = the message in which it appears. Also possibly, you might be thinking of a = use case where additional data is used in parallel to to a separate Info-Pa= ckage, but I have the greatest difficulty in identifying that as a use case= as opposed to where two separate and parallel Info packages might have bee= n used. Regards Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 10 August 2016 21:37 To: Christer Holmberg; Drage, Keith (Nokia - GB); Rosen, Brian; Emergency C= ontext Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not al= igned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brin= gs no value) implementations can mess up in an almost infinite variety of ways. Call-In= fo could indicate a different block than actually present. The MIME type o= f a body part could be incorrect. A data object could be malformed. Since= our context is emergency calls, in general the call won't be failed and th= e SIP message won't be rejected.=20 RFC 7852 contains language regarding this. --Randy At 3:22 PM +0000 8/10/16, Christer Holmberg wrote: > Hi, > > >I don't believe it is "useless". > > > > > >I believe it is dangerous because it introduces an interaction=20 > between two separate protocol mechanisms. > > > Correct, and I earlier said that we'd have to define what happens if=20 > there e.g. is a missmatch between the mechanisms. > > What I meant by "useless" is that since the content disposition type=20 > of the INFO message bodies are "info package", there is no reference=20 > to the Call-Info header fields - the semantics must be defined in the=20 > info package description. > > Regards, > > Christer > > > > > From: Ecrit > [mailto:ecrit-bounces@ietf.org] > On Behalf Of Christer Holmberg > Sent: 10 August 2016 14:09 > To: Rosen, Brian; Emergency Context Resolution with Internet=20 > Technologies Discussion List > Subject: Re: [Ecrit] Fwd:=20 > draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261=20 > (was RE: > draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > > > Hi, > > > > =A9 > > > > >I acknowledge that it's not needed with the INFO package, but I=20 > think it does no harm, and makes the entire mechanism consistent with=20 > all the other parts of additional data > > > > No, it doesn't. We don't use the "by-reference"=20 > disposition type in INFO, so there would not be a reference between=20 > the Call-Info value and the message body. Message bodies associated=20 > with info packages have the "info-package" > disposition type, and the semantics are covered by the info package=20 > specification. > > > > So, the information is useless. > > > > Regards, > > > > Christer > > > > > > Begin forwarded message: > > > > From: Ivo Sedlacek > <ivo.sedlacek@ericsson.com> > > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was > RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > Date: August 10, 2016 at 3:32:00 AM EDT > > To: "Rosen, Brian"=20 > <Brian.Rosen@neustar.biz>, > Randall Gellens > <rg+ietf@randy.pensive.org> > > > > Hello, > > In the response to the INVITE request, the=20 > Call-Info points to the=20 > application/emergencyCallData.eCall.control+xml=20 > body. This body contains a delivery report for=20 > the MSD sent in INVITE request. This is NOT=20 > information about callee. Thus, RFC3261=20 > semantic is not fulfilled. > > In the INFO request, the Call-Info points to=20 > the=20 > application/emergencyCallData.eCall.control+xml=20 > body. This body describes an action to be=20 > performed at the remote UE. This is NOT=20 > information about the sender of the INFO=20 > request. Thus, RFC3261 semantic is not=20 > fulfilled. Also, as other people indicated,=20 > this is not needed with info package mechanism. > > Kind regards > > Ivo > > -----Original Message----- > From: Rosen, Brian=20 > [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, August 09, 2016 11:22 PM > To: Randall Gellens > Cc: Ivo Sedlacek > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11-=20 > Call-Info usage not aligned with RFC3261 (was=20 > RE: draft-ietf-ecrit-ecall-11- Call-Info usage=20 > brings no value) > > I strongly agree. > > It's small cost and I think a substantial=20 > benefit to treat all the blocks as additional=20 > data blocks, put them in the registry, etc.=20 > INFO is a solution to a mid-call need to send=20 > additional data, and we should treat it that=20 > way in my opinion. > > We can state that the block reference in the=20 > INFO package must match that in the Call-Info. > > Brian > > On Aug 9, 2016, at 1:22 PM, Randall Gellens=20 > <rg+ietf@randy.pensive.org>=20 > wrote: > > I prefer to keep the use of Call-Info for all=20 > three cases (INVITE, response, INFO) to=20 > maintain compatibility with RFC 7852=20 > (Additional Data) and car-crash (North American=20 > NG-AACN). I see benefit without any real-world=20 > harm in using Call-Info even if not strictly=20 > necessary (e.g., INFO). > > --Randy > > At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: > > Hello, > > given the use case raised by Roland and=20 > clarified by Paul, let me suggest the following=20 > compromise: > > Call-Info included in an INVITE request and=20 > pointing to the=20 > application/emergencyCallData.eCall.MSD+per=20 > body of the INVITE request is kept, while=20 > Call-Info in a response to the INVITE request=20 > and in an INFO request is removed. > > Does this work for everyone? > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org >=20 > https://www.ietf.org/mailman= /listinfo/ecrit > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- I hold that the > very purpose of existence is to reconcile the glowing opinion we have > of ourselves with the terrible things > that other people say about us. --Quentin Crisp > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Ever notice that people who are late are much jollier than the people who have to wait for them? From nobody Wed Aug 10 14:36:14 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 1313612D887 for ; Wed, 10 Aug 2016 14:36:13 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 i6ixWzP2r_tl for ; Wed, 10 Aug 2016 14:36:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9637D12D85B for ; Wed, 10 Aug 2016 14:36:11 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 14:36:10 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF45100@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF45100@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 14:36:07 -0700 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:36:13 -0000 As I see it, we have one data transfer mechanism which is used in all messages and responses. At 5:19 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > Is this response only in respect of the INVITE / 200 (OK) inclusion? > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: 10 August 2016 18:13 > To: Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > At 7:41 AM +0000 8/10/16, Ivo Sedlacek wrote: > >> Hello, >> >>> The invite response still has a body with content-disposition >>> by-reference. If you remove the reference then its processing is >>> undefined. >> >> If the Call-Info is omitted in INVITE response, then: >> Alt1: a new value could be defined and used in the >> Content-Disposition header field of the >> application/emergencyCallData.eCall.control+xml body; >> or >> Alt2: an existing value could be used in the Content-Disposition >> header field of the application/emergencyCallData.eCall.control+xml >> body; >> or >> Alt3: the Content-Disposition header field can be omitted and thus >> "render" would apply for the >> application/emergencyCallData.eCall.control+xml body according to >> RFC3261 section 13.2.1. >> >> We cannot use the Call-Info in INVITE response as described in >> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >> Call-Info points to the >> application/emergencyCallData.eCall.control+xml body. This body >> contains a delivery report for the MSD sent in INVITE request. This is >> NOT information about callee as described in RFC3261. > > Hi Ivo, > > Call-Info is used in accordance with RFC 7852. > > --Randy > >> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- History has > the relation to truth that theology has to > religion -- i.e., none to speak of. --Lazarus Long > > _______________________________________________ > 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: --------------- Dr. Beverly Crusher to Wesley Crusher as he is about to beam down to begin his journey with the Traveler into other dimensions: "Be sure to dress warmly on those other planes of existence." From nobody Wed Aug 10 14:38: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 94A9312D851 for ; Wed, 10 Aug 2016 14:38: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 q6pE4EO3nRX4 for ; Wed, 10 Aug 2016 14:38:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 053B612D0DF for ; Wed, 10 Aug 2016 14:38:48 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 14:38:47 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 14:38:42 -0700 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:38:50 -0000 In reality, there is no separate INFO package negotiation. The endpoints support the data types not because they support the iNFO package, but rather they support the INFO package and the data types and Call-Info because they comply with the draft. At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > I disagree. > > The inclusion of the data element in INFO is nothing to do with RFC > 7852. The data element is included because the use of an > appropriate Info package has been negotiated and used. That Info > package definition and the INFO mechanism itself makes no mention > of use of Call-Info in association with it. > > Further I see no justification for complicating any error handling > by suddenly defining it to be applicable, as it is not necessary. > INFO requests always contain a data element appropriate to the Info > package that is defined for its use - it absolutely does not need a > secondary reference to the package. > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 10 August 2016 18:20 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hi Keith, > > At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> Unless someone is defining a new usage for Call-Info beyond RFC7852 >> then I have to agree with Ivo. That additional usage is not currently >> defined in draft-ietf-ecrit-ecall, and I would need to understand that >> usage before it is included. >> >> At the moment RFC7852 is only used for the transfer of MSD in INVITE >> requests and 200 (OK) responses, and therefore that is the only place >> where it should appear in association with RFC7852. > > RFC 7852 covers use of Call-Info to point to emergency call data > blocks in any SIP message that is permitted to carry a body. > >> >> Negotiation and transfer of MSD in association with INFO requests is >> an entirely separate transfer mechanism, not covered by >> draft-ietf-ecrit-data-only-ea and therefore it should never appear >> there as though it had been. Inclusion will lead to complete confusion >> as to whether the requirements of the INFO mechanism or the >> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >> absolutely clear that only the former apply. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >> Sent: 10 August 2016 08:41 >> To: Paul Kyzivat; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hello, >> >>> The invite response still has a body with content-disposition >>> by-reference. If you remove the reference then its processing is >>> undefined. >> >> If the Call-Info is omitted in INVITE response, then: >> Alt1: a new value could be defined and used in the >> Content-Disposition header field of the >> application/emergencyCallData.eCall.control+xml body; >> or >> Alt2: an existing value could be used in the Content-Disposition >> header field of the application/emergencyCallData.eCall.control+xml >> body; >> or >> Alt3: the Content-Disposition header field can be omitted and thus >> "render" would apply for the >> application/emergencyCallData.eCall.control+xml body according to >> RFC3261 section 13.2.1. >> >> We cannot use the Call-Info in INVITE response as described in >> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >> Call-Info points to the >> application/emergencyCallData.eCall.control+xml body. This body > > contains a delivery report for the MSD sent in INVITE request. This is >> NOT information about callee as described in RFC3261. >> >> Kind regards >> >> Ivo >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- The idea that > Bill Gates has appeared like a knight in shining armor to lead all > customers out of a mire of technological chaos neatly ignores the > fact that it was he who, by peddling second-rate technology, > led them into it in the first place. --Douglas Adams -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Einstein never accepted quantum mechanics because of this element of chance and uncertainty. He said, "God does not play dice." It seems that Einstein was doubly wrong. The quantum effects of black holes suggests that not only does God play dice, He sometimes throws them where they cannot be seen. --Steven Hawking From nobody Wed Aug 10 14:46:02 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 05B9612D86C for ; Wed, 10 Aug 2016 14:46:00 -0700 (PDT) X-Quarantine-ID: <5RUJB-yP42GR> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 5RUJB-yP42GR for ; Wed, 10 Aug 2016 14:45:58 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F15A212D869 for ; Wed, 10 Aug 2016 14:45:57 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 14:45:56 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BBD62DB@ESESSMB208.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <7594FB04B1934943A5C02806D1A2204B4BBD62DB@ESESSMB208.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 14:45:53 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:46:00 -0000 Hi Christer, RFC 7852 is not excluded for use in INFO. We did agree to not send data in an INFO response, not because it is harmful to do so, but to avoid argument about legalistic interpretations of INFO. In our case, INFO is being used exactly as any other SIP message, not in any special/unique way. I realize that to some, INFO is the unaccompanied minor of SIP messages: it must be constantly chaperoned and protected against wanton misuse as a generic transport mechanism where random data types are sent to unsuspecting endpoints that don't know how to process them. That's an entirely different situation than we have. We have endpoints in a limited domain that exchange a very small number of data types. At 6:03 PM +0000 8/10/16, Christer Holmberg wrote: > Hi, > > Again, as we have discussed before, RFC 7852 does not apply to > INFO. And, we did agree to not carry the bodies in INFO responses. > > And, again, in INFO we won't use the "by-reference" content type, > which is another example why you can't apply RFC 7852 to INFO. > > I DID raise these issues before 7852 was published, but was told > it's too late to change at that point. So, maybe we need to correct > 7852 if that is unclear. > > Regards, > > Christer > > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: 10 August 2016 20:20 > To: Drage, Keith (Nokia - GB) ; Ivo Sedlacek > ; Paul Kyzivat ; > ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hi Keith, > > At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> Unless someone is defining a new usage for Call-Info beyond RFC7852 >> then I have to agree with Ivo. That additional usage is not currently >> defined in draft-ietf-ecrit-ecall, and I would need to understand that >> usage before it is included. >> >> At the moment RFC7852 is only used for the transfer of MSD in INVITE >> requests and 200 (OK) responses, and therefore that is the only place >> where it should appear in association with RFC7852. > > RFC 7852 covers use of Call-Info to point to emergency call data > blocks in any SIP message that is permitted to carry a body. > >> >> Negotiation and transfer of MSD in association with INFO requests is >> an entirely separate transfer mechanism, not covered by >> draft-ietf-ecrit-data-only-ea and therefore it should never appear >> there as though it had been. Inclusion will lead to complete confusion >> as to whether the requirements of the INFO mechanism or the >> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >> absolutely clear that only the former apply. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >> Sent: 10 August 2016 08:41 >> To: Paul Kyzivat; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hello, >> >>> The invite response still has a body with content-disposition >>> by-reference. If you remove the reference then its processing is >>> undefined. >> >> If the Call-Info is omitted in INVITE response, then: >> Alt1: a new value could be defined and used in the >> Content-Disposition header field of the >> application/emergencyCallData.eCall.control+xml body; >> or >> Alt2: an existing value could be used in the Content-Disposition >> header field of the application/emergencyCallData.eCall.control+xml > > body; >> or >> Alt3: the Content-Disposition header field can be omitted and thus >> "render" would apply for the >> application/emergencyCallData.eCall.control+xml body according to >> RFC3261 section 13.2.1. >> >> We cannot use the Call-Info in INVITE response as described in >> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >> Call-Info points to the >> application/emergencyCallData.eCall.control+xml body. This body >> contains a delivery report for the MSD sent in INVITE request. This is >> NOT information about callee as described in RFC3261. >> >> Kind regards >> >> Ivo >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- The idea that > Bill Gates has appeared like a knight in shining armor to lead all > customers out of a mire of technological chaos neatly ignores the > fact that it was he who, by peddling second-rate technology, > led them into it in the first place. --Douglas Adams > > _______________________________________________ > 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: --------------- ...All repairs tend to destroy the structure [of the software], to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. [...] Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence. --Fred Brooks in _The Mythical Man Month_ From nobody Wed Aug 10 14:49: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 9DB3F12D851 for ; Wed, 10 Aug 2016 14:49:05 -0700 (PDT) X-Quarantine-ID: <3nd552gQJTJ5> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 3nd552gQJTJ5 for ; Wed, 10 Aug 2016 14:49:03 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49F126579 for ; Wed, 10 Aug 2016 14:49:00 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 10 Aug 2016 14:48:59 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF453AF@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164C3BFC@ESESSMB301.ericsson.se> <9A5A1E0F-8725-4EF9-9A2D-5264932AA1F3@neustar.biz> <949EF20990823C4C85C18D59AA11AD8BADF44F1A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF453AF@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 10 Aug 2016 14:48:55 -0700 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , "Rosen, Brian" , "Emergency Context Resolution with Internet Technologies Discussion List" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 10 Aug 2016 21:49:05 -0000 RFC 7852 is not prohibited from applying to INFO.=20 Yes, we agree that when INFO is used, we=20 (underline)also(stop underline) need to include=20 an INFO package. That's in addition, not instead=20 of. At 9:30 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > I think we have to be absolutely clear. RFC=20 > 7852 DOES NOT =20 > apply in the case of the data element attached=20 > to an INFO package in support of ecrit. > > I thought we had reached agreement that when=20 > INFO was used, then an Info package would be=20 > defined and the rules for supporting an Info=20 > Package would be used. Attempting to suggest=20 > that a Call-Info is used appears to me to=20 > persisting in the previous attempt to reuse=20 > INFO in support of something that is not an=20 > Info package. > > In respect of an Info-Package usage, Call-Info=20 > has no semantic meaning, and to me that is an=20 > implicit message to any protocol implementor=20 > never to include it. > > Of course you may be trying to hint that=20 > somehow the use of the Call-Info has some=20 > semantic meaning across messages (following=20 > some of Brian's comments on same usage from one=20 > message to another), but that semantic does not=20 > exist in RFC 7852 and has never been defined.=20 > RFC 7852 usage applies only to the message in=20 > which it appears. Also possibly, you might be=20 > thinking of a use case where additional data is=20 > used in parallel to to a separate Info-Package,=20 > but I have the greatest difficulty in=20 > identifying that as a use case as opposed to=20 > where two separate and parallel Info packages=20 > might have been used. > > Regards > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 10 August 2016 21:37 > To: Christer Holmberg; Drage, Keith (Nokia -=20 > GB); Rosen, Brian; Emergency Context Resolution=20 > with Internet Technologies Discussion List > Subject: Re: [Ecrit] Fwd:=20 > draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE:=20 > draft-ietf-ecrit-ecall-11- Call-Info usage=20 > brings no value) > > implementations can mess up in an almost=20 > infinite variety of ways. Call-Info could=20 > indicate a different block than actually=20 > present. The MIME type of a body part could be=20 > incorrect. A data object could be malformed.=20 > Since our context is emergency calls, in=20 > general the call won't be failed and the SIP=20 > message won't be rejected. > RFC 7852 contains language regarding this. > > --Randy > > At 3:22 PM +0000 8/10/16, Christer Holmberg wrote: > >> Hi, >> >> >I don't believe it is "useless". >> >> > >> >> >I believe it is dangerous because it introduces an interaction >> between two separate protocol mechanisms. >> >> >> Correct, and I earlier said that we'd have to define what happens if >> there e.g. is a missmatch between the mechanisms. >> >> What I meant by "useless" is that since the content disposition type >> of the INFO message bodies are "info package", there is no reference >> to the Call-Info header fields - the semantics must be defined in the >> info package description. >> >> Regards, >> >> Christer >> >> >> >> >> From: Ecrit >> [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Christer Holmberg >> Sent: 10 August 2016 14:09 >> To: Rosen, Brian; Emergency Context Resolution with Internet >> Technologies Discussion List >> Subject: Re: [Ecrit] Fwd: >> draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 >> (was RE: >> draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) >> >> >> >> Hi, >> >> >> >> =B7 >> >> >> >> >I acknowledge that it's not needed with the INFO package, but I >> think it does no harm, and makes the entire mechanism consistent with >> all the other parts of additional data > > >> >> >> No, it doesn't. We don't use the "by-reference" >> disposition type in INFO, so there would not be a reference between >> the Call-Info value and the message body. Message bodies associated >> with info packages have the "info-package" >> disposition type, and the semantics are covered by the info package >> specification. >> >> >> >> So, the information is useless. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> Begin forwarded message: >> >> >> >> From: Ivo Sedlacek >> <ivo.sedlacek@ericsson.com> >> >> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was >> RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) >> >> Date: August 10, 2016 at 3:32:00 AM EDT >> >> To: "Rosen, Brian" >> <Brian.Rosen@neustar.biz>, >> Randall Gellens >> <rg+ietf@randy.pensive.org> >> >> >> >> Hello, >> >> In the response to the INVITE request, the >> Call-Info points to the >> application/emergencyCallData.eCall.control+xml >> body. This body contains a delivery report for >> the MSD sent in INVITE request. This is NOT >> information about callee. Thus, RFC3261 >> semantic is not fulfilled. >> >> In the INFO request, the Call-Info points to >> the >> application/emergencyCallData.eCall.control+xml >> body. This body describes an action to be >> performed at the remote UE. This is NOT >> information about the sender of the INFO >> request. Thus, RFC3261 semantic is not >> fulfilled. Also, as other people indicated, >> this is not needed with info package mechanism. >> >> Kind regards >> >> Ivo >> >> -----Original Message----- >> From: Rosen, Brian >> [mailto:Brian.Rosen@neustar.biz] >> Sent: Tuesday, August 09, 2016 11:22 PM >> To: Randall Gellens >> Cc: Ivo Sedlacek >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- >> Call-Info usage not aligned with RFC3261 (was >> RE: draft-ietf-ecrit-ecall-11- Call-Info usage >> brings no value) >> >> I strongly agree. >> >> It's small cost and I think a substantial >> benefit to treat all the blocks as additional >> data blocks, put them in the registry, etc. >> INFO is a solution to a mid-call need to send >> additional data, and we should treat it that >> way in my opinion. >> >> We can state that the block reference in the >> INFO package must match that in the Call-Info. >> >> Brian >> >> On Aug 9, 2016, at 1:22 PM, Randall Gellens >> <rg+ietf@randy.pensive.org> >> wrote: >> >> I prefer to keep the use of Call-Info for all >> three cases (INVITE, response, INFO) to >> maintain compatibility with RFC 7852 >> (Additional Data) and car-crash (North American >> NG-AACN). I see benefit without any real-world >> harm in using Call-Info even if not strictly >> necessary (e.g., INFO). >> >> --Randy >> >> At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote: >> >> Hello, >> >> given the use case raised by Roland and >> clarified by Paul, let me suggest the following >> compromise: >> >> Call-Info included in an INVITE request and >> pointing to the >> application/emergencyCallData.eCall.MSD+per >> body of the INVITE request is kept, while >> Call-Info in a response to the INVITE request >> and in an INFO request is removed. >> >> Does this work for everyone? >> >> Kind regards >> >> Ivo Sedlacek >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> >>=20 >> https://www.ietf.org/mailman= /listinfo/ecrit >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- I hold that the >> very purpose of existence is to reconcile the glowing opinion we have >> of ourselves with the terrible things >> that other people say about us. --Quentin Crisp >> >> >> >> >> >> >> _______________________________________________ >> 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: --------------- > Ever notice that people who are late are much jollier > than the people who have to wait for them? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Anything labeled "NEW" and/or "IMPROVED" isn't. The label means the price went up. The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW" means the price went way up. From nobody Wed Aug 10 22:29: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 87E6812B01A for ; Wed, 10 Aug 2016 22:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 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, RP_MATCHES_RCVD=-1.247, T_KAM_HTML_FONT_INVALID=0.01, T_MIME_MALF=0.01] 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 5QJQiQggQGM4 for ; Wed, 10 Aug 2016 22:29:04 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD75D12B012 for ; Wed, 10 Aug 2016 22:29:03 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Aug 2016 07:28:58 +0200 X-IronPort-AV: E=Sophos;i="5.28,503,1464645600"; d="scan'208,217";a="509015801" Received: from he105661.emea1.cds.t-internal.com ([10.169.119.57]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Aug 2016 07:28:58 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105661.emea1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 11 Aug 2016 07:28:58 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Thu, 11 Aug 2016 07:28:58 +0200 From: To: , , , Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8VmdxDkSwOuNt0up/ReUYIGPc6BCLtCAgAEP5mA= Date: Thu, 11 Aug 2016 05:28:58 +0000 Message-ID: <4296a801793a496f81559bece9ed5071@HE105660.emea1.cds.t-internal.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F13@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF44F13@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.244.47] Content-Type: multipart/alternative; boundary="_000_4296a801793a496f81559bece9ed5071HE105660emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 05:29:08 -0000 --_000_4296a801793a496f81559bece9ed5071HE105660emea1cdstintern_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keith, since my statement I learned from the mail discussion hat such a mechanism = is not appropriate. So I agree your statement. Nevertheless another mechanism for inband indication of ecall would be nice= but I understand that such an issue is more or less out of scope of this d= raft. Best Regards Roland Von: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com] Gesendet: Mittwoch, 10. August 2016 17:12 An: Jesske, Roland; ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit= @ietf.org Betreff: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) I fundamentally disagree. We have two different data transfer mechanisms, a= nd the presence of the data should be clearly understood from the appropria= te transfer mechanism protocol. So Call-Info applies when RFC 7852 applies, which is the INVITE and 200 (OK= ) response, and does not when the INFO mechanism is in use. Additionally it only applies when it is pointing to data which is actually = attached to the message. Keith From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.d= e Sent: 08 August 2016 10:45 To: ivo.sedlacek@ericsson.com; pkyzivat@a= lum.mit.edu; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Ivo, using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly m= eans using the MSD within the Body. It could be also an interworked call wh= ere all ecall information is included inband using the In-band modem soluti= on. We have to think also on backwards compatibility issues. Thus when moving = PSAP's to SIP imply also that there must exist an interworking between the = old mobile world towards the new mobile world using SIP. Using the Call-Info header would help the PAST to distinguish the in-band a= nd outband solution. Perhaps it would be worth to define an additional valu= e for inband data, to identify ecalls coming from other networks not suppor= ting the MSD Body. Best Regards Roland. Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek Gesendet: Montag, 8. August 2016 09:59 An: Paul Kyzivat; ecrit@ietf.org Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned wit= h RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no val= ue) Hello, According to RFC3261, the Call-Info header field provides additional inform= ation about the caller or callee. According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used = to form a "content-table" of pointers to bodies INVITE request (and of INVI= TE response, of INFO request) in headers of INVITE request (and of INVITE r= esponse, of INFO request). If the Call-Info header field points to a body which describes the callers = or callee, then Call-Info semantic fits (even though I would still question= usefulness of such Call-Info inclusion). If the Call-Info header field points to a body which request an action in r= emote UE and which reports to remote UE an outcome of an action done by the= local UE, then Call-Info semantic does not fit. Particularly: ---------------------------------------------------------------------------= --- A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. The body part is identified by its MIME content-type ('application/ emergencyCallData.eCall.control+xml') in the Content-Type header field of the body part. The body part is assigned a unique identifier which is listed in a Content-ID header field in the body part. The SIP message is marked as containing the metadata/control object by adding (or appending to) a Call-Info header field at the top level of the SIP message. This Call-Info header field contains a CID URL referencing the body part's unique identifier, and a 'purpose' parameter identifying the data as an eCall metadata/control block per the Emergency Call Additional Data Blocks registry entry; the 'purpose' parameter's value is 'emergencyCallData.eCall.control'. ---------------------------------------------------------------------------= --- and ---------------------------------------------------------------------------= --- SIP/2.0 200 OK To: ;tag=3D9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:2345678901@atlanta.example.com; purpose=3DemergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 31862 INVITE Recv-Info: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryX Content-Length: ... --boundaryX Content-Type: application/sdp ...Session Description Protocol (SDP) goes here... --boundaryX Content-Type: application/EmergencyCallData.eCall.control+xml Content-ID: 2345678901@atlanta.example.com Content-Disposition: by-reference;handling=3Doptional "/> --boundaryX-- ---------------------------------------------------------------------------= --- Kind regards Ivo -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, August 05, 2016 4:43 PM To: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue Ivo, IIUC, you are saying that the Call-Info that refers to the body is unnecess= ary because the recipient will know what to do with the body even in the ab= sence of the Call-Info. Is that right? This assumption mixes up two things: - understanding a body syntactically - understanding *why* the body is present and how it should be used. Historically, processing of body parts in sip was very poorly defined. Initially the only body of interest was SDP, so how one might process other= bodies or body parts was not well considered. Eventually this started to b= e a liability, so RFC5621 was published to clarify it. Processing of body parts is governed by a complex interaction between Conte= nt-Type, Content-Disposition, Content-ID. So the call-info header indicates the reason that body is being included. I= realize that there is one predominant reason for doing so, but that is not= the only possible reason. (E.g., it might be included as context in an int= ended discussion about problems handling a call in the past.) If all the handling of the call is coded in a special purpose way, solely f= or the emergency call path, then alternatives may be of no concern. But ide= ally the call will largely be handled via standard library code that is als= o used for other call paths and other message processing. So processing bod= y parts in a "standard" way, rather than special casing, is desirable. Thanks, Paul On 8/5/16 7:15 AM, Ivo Sedlacek wrote: > Hello, > > > > COMMENT: > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Inclusion of Call-Info header field with > purpose=3DemergencyCallData.eCall.MSD or > purpose=3DemergencyCallData.eCall.control in requests and responses does > not seem to bring any value. It seems to only waste radio resources. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in the > initial INVITE request: > > - if this is meant to be used by a proxy for routing of the eCall > emergency call to a PSAP supporting eCall emergency call, then this > seems to be redundant to the eCall URN included in the Request-URI and > the Recv-Info header field containing eCall specific info package > (emergencyCallData.eCall.MSD). > > - if this is meant to be used by UAS (i.e. PSAP), then according to > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all > the bodies of the INVITE request not marked with Content-Disposition: > ...; handling=3Doptional are understood. So, > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INVITE request processing. > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > a response to the initial INVITE request > > - no routing decisions are done by proxies when receiving a response > to the initial INVITE request so this does not seem to have any value > for the proxies > > - UAC includes Accept with supported MIME types in INVITE request so > why would UAS send any MIME body not wished by the UAC? > > > > For Call-Info with purpose=3DemergencyCallData.eCall.control included in > the INFO request > > - no routing decisions are done by proxies when receiving an in-dialog > request so this does not seem to have any value for the proxies > > - support of info package emergencyCallData.eCall.MSD in the call > implies that either application/EmergencyCallData.eCall.control+xml > MIME body or application/emergencyCallData.eCall.MSD+per MIME body is > included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway > needs to check that all the bodies of the INFO request not marked with > Content-Disposition: ...; handling=3Doptional are understood. So, > application/EmergencyCallData.eCall.control+xml MIME body or > application/emergencyCallData.eCall.MSD+per MIME body will anyway be > found by UAS during the INFO request processing. > > ////////////////////////////////////////////////////////////////////// > //////// > > PROPOSED SOLUTION to COMMENT > > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > \\\\\\\\ > > Remove insertion of Call-Info header field. > > ////////////////////////////////////////////////////////////////////// > //////// > > > > Kind regards > > > > Ivo Sedlacek > > > > _______________________________________________ > 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 --_000_4296a801793a496f81559bece9ed5071HE105660emea1cdstintern_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Keit= h,

since m= y statement I learned from the mail discussion hat such a mechanism is not = appropriate. So I agree your statement.

Neverth= eless another mechanism for inband indication of ecall would be nice but I = understand that such an issue is more or less out of scope of this draft.

&n= bsp;

Best Re= gards

&n= bsp;

Roland<= o:p>

&n= bsp;

Von: Drage, Ke= ith (Nokia - GB) [mailto:keith.drage@nokia.com]
Gesendet: Mittwoch, 10. August 2016 17:12
An: Jesske, Roland; ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu= ; ecrit@ietf.org
Betreff: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage br= ings no value)

 

I funda= mentally disagree. We have two different data transfer mechanisms, and the = presence of the data should be clearly understood from the appropriate tran= sfer mechanism protocol.


So Call-Info applies when RFC 7852 applies, which is the INVITE and 200 (OK= ) response, and does not when the INFO mechanism is in use.

&n= bsp;

Additio= nally it only applies when it is pointing to data which is actually attache= d to the message.

&n= bsp;

Keith

&n= bsp;

From: Ecrit [mail= to:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom= .de
Sent: 08 August 2016 10:45
To: ivo.sedlacek@ericss= on.com; pkyzivat@alum.mit.edu; ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage br= ings no value)

 

Hi Ivo,= <= /o:p>

using th=
e ecall urn (urn:service:sos.ecall.automatic) does not implicitly means usi=
ng the MSD within the Body. It could be also an interworked call where all =
ecall information is included inband using the In-band modem solution.=

&nb=
sp;
We have =
to think also on backwards compatibility issues.  Thus when moving PSA=
P’s to SIP imply also that there must exist an interworking between t=
he old mobile world towards the new mobile world using SIP.
&nb=
sp;
Using th=
e Call-Info header would help the PAST to distinguish the in-band and outba=
nd solution. Perhaps it would be worth to define an additional value for in=
band data, to identify ecalls coming from other networks not supporting the=
 MSD Body.
&nb=
sp;
Best Regards=


Roland. =

 

 

Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; ecrit@ietf.org
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not alig= ned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings= no value)

 

Hello,

 

According to RFC3261, the Ca= ll-Info header field provides additional information about the caller or ca= llee.

 

According to draft-ietf-ecri= t-ecall-11, the Call-Info header field is used to form a "content-tabl= e" of pointers to bodies INVITE request (and of INVITE response, of IN= FO request) in headers of INVITE request (and of INVITE response, of INFO request).

 

If the Call-Info header fiel= d points to a body which describes the callers or callee, then Call-Info se= mantic fits (even though I would still question usefulness of such Call-Inf= o inclusion).

 

If the Call-Info header fiel= d points to a body which request an action in remote UE and which reports t= o remote UE an outcome of an action done by the local UE, then Call-Info se= mantic does not fit.

 

Particularly:

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

   A PSAP or IVS t= ransmits a metadata/control object (see Section 9) by

   encoding it per= the description in this document and attaching it to

   a SIP message a= s a MIME body part per [RFC7852].  The body part is<= /p>

   identified by i= ts MIME content-type ('application/

   emergencyCallDa= ta.eCall.control+xml') in the Content-Type header

   field of the bo= dy part.  The body part is assigned a unique

   identifier whic= h is listed in a Content-ID header field in the body

   part.  The= SIP message is marked as containing the metadata/control=

   object by addin= g (or appending to) a Call-Info header field at the

   top level of th= e SIP message.  This Call-Info header field contains a

   CID URL referencing the body part's uniqu= e identifier, and a

   'purpose' parameter identifying the data = as an eCall metadata/control

   block per the Emergency Call Additional D= ata Blocks registry entry;

   the 'purpose' parameter's value is 'emerg= encyCallData.eCall.control'.<= /p>

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

and

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

SIP/2.0 200 OK

    &nbs= p; To: <sip:+1314555111= 1@example.com>;tag=3D9fxced76sl

    &nbs= p; From: Exemplar PSAP <urn:service:sos.ecall.automatic>

    &nbs= p; Call-ID: 3848276298220188511@atlanta.example.com

    &nbs= p; Call-Info: cid:2345678901@at= lanta.example.com;

         =         purpose=3DemergencyCallData.eCal= l.control;

    &nbs= p; Accept: application/sdp, application/pidf+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.control+xml,

    &nbs= p;         application/emergencyCal= lData.eCall.MSD+per

    &nbs= p; CSeq: 31862 INVITE

    &nbs= p; Recv-Info: emergencyCallData.eCall.MSD

    &nbs= p; Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,=

    &nbs= p;        SUBSCRIBE, NOTIFY, UPDATE=

    &nbs= p; Content-Type: multipart/mixed; boundary=3DboundaryX

    &nbs= p; Content-Length: ...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/sdp

 

    &nbs= p;      ...Session Description Protocol (SDP) goes= here...

 

    &nbs= p; --boundaryX

    &nbs= p; Content-Type: application/EmergencyCallData.eCall.control+xml

    &nbs= p; Content-ID: 2345678901@at= lanta.example.com

    &nbs= p; Content-Disposition: by-reference;handling=3Doptional<= /p>

 

    &nbs= p; <?xml version=3D"1.0" encoding=3D"UTF-8"?>

    &nbs= p; <EmergencyCallData.eCall.Control

    &nbs= p;     xmlns=3D"urn:ietf:params:xml:ns:EmergencyCa= llData:eCall:control"

    &nbs= p;     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=

    &nbs= p;     xsi:schemaLocation=3D

    &nbs= p;         "urn:ietf:params:xm= l:ns:EmergencyCallData:eCall:control">

 

    &nbs= p; <ack received=3D"true" ref=3D"1234567890@atlanta.example.com"/>=

 

    &nbs= p; </EmergencyCallData.eCall.Control>

 

    &nbs= p; --boundaryX--

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

 

Kind regards

 

Ivo

 

-----Original Message----- From: Ecrit [mailto:ecrit-bounces= @ietf.org] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no v= alue

 

Ivo,

 

IIUC, you are saying that th= e Call-Info that refers to the body is unnecessary because the recipient wi= ll know what to do with the body even in the absence of the Call-Info. Is t= hat right?

 

This assumption mixes up two= things:

- understanding a body synta= ctically

- understanding *why* the bo= dy is present and how it should be used.

 

Historically, processing of = body parts in sip was very poorly defined.

Initially the only body of i= nterest was SDP, so how one might process other bodies or body parts was no= t well considered. Eventually this started to be a liability, so RFC5621 wa= s published to clarify it.

 

Processing of body parts is = governed by a complex interaction between Content-Type, Content-Disposition= , Content-ID.

 

So the call-info header indi= cates the reason that body is being included. I realize that there is one p= redominant reason for doing so, but that is not the only possible reason. (= E.g., it might be included as context in an intended discussion about problems handling a call in the=

past.)

 

If all the handling of the c= all is coded in a special purpose way, solely for the emergency call path, = then alternatives may be of no concern. But ideally the call will largely b= e handled via standard library code that is also used for other call paths and other message processing. So pr= ocessing body parts in a "standard" way, rather than special casi= ng, is desirable.

 

    &nbs= p;           Thanks,=

    &nbs= p;           Paul

 

On 8/5/16 7:15 AM, Ivo Sedla= cek wrote:

> Hello,

> =

> =

> =

> COMMENT:

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Inclusion of Call-Info = header field with

> purpose=3DemergencyCall= Data.eCall.MSD or

> purpose=3DemergencyCall= Data.eCall.control in requests and responses does

> not seem to bring any v= alue. It seems to only waste radio resources.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.MSD included in the

> initial INVITE request:=

> =

> - if this is meant to b= e used by a proxy for routing of the eCall

> emergency call to a PSA= P supporting eCall emergency call, then this

> seems to be redundant t= o the eCall URN included in the Request-URI and

> the Recv-Info header fi= eld containing eCall specific info package

> (emergencyCallData.eCal= l.MSD).

> =

> - if this is meant to b= e used by UAS (i.e. PSAP), then according to

> RFC3261 subclause 8.2.3= , then the UAS anyway needs to check that all

> the bodies of the INVIT= E request not marked with Content-Disposition:

> ...; handling=3Doptiona= l are understood. So,

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INVITE request processing.

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> a response to the initi= al INVITE request

> =

> - no routing decisions = are done by proxies when receiving a response

> to the initial INVITE r= equest so this does not seem to have any value

> for the proxies

> =

> - UAC includes Accept w= ith supported MIME types in INVITE request so

> why would UAS send any = MIME body not wished by the UAC?

> =

> =

> =

> For Call-Info with purp= ose=3DemergencyCallData.eCall.control included in

> the INFO request

> =

> - no routing decisions = are done by proxies when receiving an in-dialog

> request so this does no= t seem to have any value for the proxies

> =

> - support of info packa= ge emergencyCallData.eCall.MSD in the call

> implies that either app= lication/EmergencyCallData.eCall.control+xml

> MIME body or applicatio= n/emergencyCallData.eCall.MSD+per MIME body is

> included. Again, accord= ing to RFC3261 subclause 8.2.3, the UAS anyway

> needs to check that all= the bodies of the INFO request not marked with

> Content-Disposition: ..= .; handling=3Doptional are understood. So,

> application/EmergencyCa= llData.eCall.control+xml MIME body or

> application/emergencyCa= llData.eCall.MSD+per MIME body will anyway be

> found by UAS during the= INFO request processing.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> PROPOSED SOLUTION to CO= MMENT

> =

> \\\\\\\\\\\\\\\\\\\\\\\= \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> =

> Remove insertion of Cal= l-Info header field.

> =

> ///////////////////////= ///////////////////////////////////////////////

> ////////

> =

> =

> =

> Kind regards=

> =

> =

> =

> Ivo Sedlacek=

> =

> =

> =

> _______________________= ________________________

> Ecrit mailing list=

> Ecrit@ietf= .org

> https://www.ietf.org/= mailman/listinfo/ecrit

> =

 

____________________________= ___________________

Ecrit mailing list

Ecrit@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/ecrit

--_000_4296a801793a496f81559bece9ed5071HE105660emea1cdstintern_-- From nobody Wed Aug 10 22:56: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 00509126FDC for ; Wed, 10 Aug 2016 22:56:06 -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 LmZiZiqTrtxj for ; Wed, 10 Aug 2016 22:56:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6E24212B038 for ; Wed, 10 Aug 2016 22:56:01 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-d2-57ac1370d13d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id F1.36.04209.0731CA75; Thu, 11 Aug 2016 07:56:00 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 07:55:59 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "R.Jesske@telekom.de" , "Ivo Sedlacek" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qBCulbYgACe0YA= Date: Thu, 11 Aug 2016 05:55:58 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7sW6B8Jpwg9kr5CwaFz1ltdiw5TiL xYoNB1gtmu50sVl8f97F6MDq8ff9ByaPJUt+MnncvXWJyWPrnccsHm0vFQJYo7hsUlJzMstS i/TtErgyLu87ylQwI7fiyOpHbA2MF8O6GDk5JARMJDY1HWYBsYUE1jNKrOnR7WLkArKXMEo8 /dTF3sXIwcEmYCHR/U8bJC4iMJ1J4vqJa0wgDcICCxklLjwQAbFFBBYxSixeLgdhW0msunKY DcRmEVCVOD3lGyvIHF6g+NxLmRDz9zJKdF+6CDaHU8BYYuHTl+wgNqOAmMT3U2vA4swC4hK3 nsxngjhUQGLJnvPMELaoxMvH/1hBbFEBPYnvX2dDxRUlPr7axwjRqydxY+oUNgjbWuLTtTOs ELa2xLKFr8HqeQUEJU7OfMIygVFsFpJ1s5C0z0LSPgtJ+ywk7QsYWVcxihanFiflphsZ66UW ZSYXF+fn6eWllmxiBEbkwS2/VXcwXn7jeIhRgINRiYd3QfbqcCHWxLLiytxDjBIczEoivJ4C a8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MGp5nMg/ tEWRt/LRkcfZjo9f/r34Y8ek4o2i/NL/3zim2h+aPvWYw6SD6/lY/+XMTPg/d330lL9mjxeq unkrZ/tybZeOW1FjulV0a9YSLWFh+dlNdn+n7/Q9f6ne1W512f33ldsntGi2nBP9K/Uz/dmK 586F4X0JwSIcP9WkDmUz+uQ++Ner4KDEUpyRaKjFXFScCADrAxMoxAIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 05:56:06 -0000 Hi, >I see it as one data transfer mechanism, which has additional >restrictions/impositions when used with INFO. INFO has various >prohibitions and restrictions and mandates in an attempt to reign in >the former freewheeling use of INFO as a generic data transfer >mechanism. In our case, we're using INFO only for mid-call updates, We don=B9t have the authority to say =B3Well, we only use INFO for this special case, so therefore we don=B9t need to follow RFC 6086=B2. And, most usages of INFO are for a specific purpose. That=B9s the whole ide= a of the info package mechanism - to to have a clear scope and semantics of the usage. >=20 >and only because it seemed at the time to be cleaner than using >re-INVITE or UPDATE or OPTIONS or something else. If we diverge into >two entirely separate mechanisms, one just for INFO, then we will do >a disservice to emergency call processing. The difference is on the SIP level. As the same MIME types etc are used, the applications will see no difference. Regards, Christer > >At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> >> I fundamentally disagree. We have two different data transfer >> mechanisms, and the presence of the data should be clearly >> understood from the appropriate transfer mechanism protocol. >> >> So Call-Info applies when RFC 7852 applies, which is the INVITE and >> 200 (OK) response, and does not when the INFO mechanism is in use. >> >> Additionally it only applies when it is pointing to data which is >> actually attached to the message. >> >> Keith >> >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >>R.Jesske@telekom.de >> Sent: 08 August 2016 10:45 >> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Ivo, >> using the ecall urn (urn:service:sos.ecall.automatic) does not >> implicitly means using the MSD within the Body. It could be also an >> interworked call where all ecall information is included inband >> using the In-band modem solution. >> >> We have to think also on backwards compatibility issues. Thus when >> moving PSAP's to SIP imply also that there must exist an >> interworking between the old mobile world towards the new mobile >> world using SIP. >> >> Using the Call-Info header would help the PAST to distinguish the >> in-band and outband solution. Perhaps it would be worth to define >> an additional value for inband data, to identify ecalls coming from >> other networks not supporting the MSD Body. >> >> Best Regards >> >> Roland. >> >> >> Von: Ecrit=20 >> [mailto:ecrit-bounces@ietf.org] Im >> Auftrag von Ivo Sedlacek >> Gesendet: Montag, 8. August 2016 09:59 >> An: Paul Kyzivat; ecrit@ietf.org >> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hello, >> >> According to RFC3261, the Call-Info header field provides >> additional information about the caller or callee. >> >> According to draft-ietf-ecrit-ecall-11, the Call-Info header field >> is used to form a "content-table" of pointers to bodies INVITE >> request (and of INVITE response, of INFO request) in headers of >> INVITE request (and of INVITE response, of INFO request). >> >> If the Call-Info header field points to a body which describes the >> callers or callee, then Call-Info semantic fits (even though I >> would still question usefulness of such Call-Info inclusion). >> >> If the Call-Info header field points to a body which request an >> action in remote UE and which reports to remote UE an outcome of an >> action done by the local UE, then Call-Info semantic does not fit. >> >> Particularly: >>=20 >>=20 >>------------------------------------------------------------------------- >>----- >> A PSAP or IVS transmits a metadata/control object (see Section 9) by >> encoding it per the description in this document and attaching it to >> a SIP message as a MIME body part per [RFC7852]. The body part is >> identified by its MIME content-type ('application/ >> emergencyCallData.eCall.control+xml') in the Content-Type header >> field of the body part. The body part is assigned a unique >> identifier which is listed in a Content-ID header field in the body >> part. The SIP message is marked as containing the metadata/control >> object by adding (or appending to) a Call-Info header field at the >> top level of the SIP message. This Call-Info header field contains >>a >> CID URL referencing the body part's unique identifier, and a >> 'purpose' parameter identifying the data as an eCall >>metadata/control >> block per the Emergency Call Additional Data Blocks registry entry; >> the 'purpose' parameter's value is >>'emergencyCallData.eCall.control'. >>=20 >>=20 >>------------------------------------------------------------------------- >>----- >> and >>=20 >>=20 >>------------------------------------------------------------------------- >>----- >> SIP/2.0 200 OK >> To:=20 >>=20 >><sip:+13145551111@example.com>;tag=3D9fxced= 76 >>sl >> From: Exemplar PSAP >> Call-ID: >> 3848276298220188511@atlanta.example.com >> Call-Info: >> cid:2345678901@atlanta.example.com; >> purpose=3DemergencyCallData.eCall.control; >> Accept: application/sdp, application/pidf+xml, >> application/emergencyCallData.eCall.control+xml, >> application/emergencyCallData.eCall.MSD+per >> CSeq: 31862 INVITE >> Recv-Info: emergencyCallData.eCall.MSD >> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >> SUBSCRIBE, NOTIFY, UPDATE >> Content-Type: multipart/mixed; boundary=3DboundaryX >> Content-Length: ... >> >> --boundaryX >> Content-Type: application/sdp >> >> ...Session Description Protocol (SDP) goes here... >> >> --boundaryX >> Content-Type: application/EmergencyCallData.eCall.control+xml >> Content-ID: >> 2345678901@atlanta.example.com >> Content-Disposition: by-reference;handling=3Doptional >> >> >> > =20 >>xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>=20 >>=20 >>xmlns:xsi=3D"http://www.w3.org= /2 >>001/XMLSchema-instance" >> xsi:schemaLocation=3D >> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >> >> >=20 >>ref=3D"1234567890@atlanta.example.= co >>m"/> >> >> >> >> --boundaryX-- >>=20 >>=20 >>------------------------------------------------------------------------- >>----- >> >> Kind regards >> >> Ivo >> >> -----Original Message----- >> From: Ecrit=20 >> [mailto:ecrit-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, August 05, 2016 4:43 PM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >> brings no value >> >> Ivo, >> >> IIUC, you are saying that the Call-Info that refers to the body is >> unnecessary because the recipient will know what to do with the >> body even in the absence of the Call-Info. Is that right? >> >> This assumption mixes up two things: >> - understanding a body syntactically >> - understanding *why* the body is present and how it should be used. >> >> Historically, processing of body parts in sip was very poorly defined. >> Initially the only body of interest was SDP, so how one might >> process other bodies or body parts was not well considered. >> Eventually this started to be a liability, so RFC5621 was published >> to clarify it. >> >> Processing of body parts is governed by a complex interaction >> between Content-Type, Content-Disposition, Content-ID. >> >> So the call-info header indicates the reason that body is being >> included. I realize that there is one predominant reason for doing >> so, but that is not the only possible reason. (E.g., it might be >> included as context in an intended discussion about problems >> handling a call in the >> past.) >> >> If all the handling of the call is coded in a special purpose way, >> solely for the emergency call path, then alternatives may be of no >> concern. But ideally the call will largely be handled via standard >> library code that is also used for other call paths and other >> message processing. So processing body parts in a "standard" way, >> rather than special casing, is desirable. >> >> Thanks, >> Paul >> >> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >> > Hello, >> > >> > >> > >> > COMMENT: >> > >> >=20 >>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> > \\\\\\\\ >> > >> > Inclusion of Call-Info header field with >> > purpose=3DemergencyCallData.eCall.MSD or >> > purpose=3DemergencyCallData.eCall.control in requests and responses >>does >> > not seem to bring any value. It seems to only waste radio resources. >> > >> > >> > >> > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included in >>the >> > initial INVITE request: >> > >> > - if this is meant to be used by a proxy for routing of the eCall >> > emergency call to a PSAP supporting eCall emergency call, then this >> > seems to be redundant to the eCall URN included in the Request-URI >>and >> > the Recv-Info header field containing eCall specific info package >> > (emergencyCallData.eCall.MSD). >> > >> > - if this is meant to be used by UAS (i.e. PSAP), then according to >> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >> > the bodies of the INVITE request not marked with >>Content-Disposition: >> > ...; handling=3Doptional are understood. So, >> > application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> > found by UAS during the INVITE request processing. >> > >> > >> > >> > For Call-Info with purpose=3DemergencyCallData.eCall.control include= d >>in >> > a response to the initial INVITE request >> > >> > - no routing decisions are done by proxies when receiving a response >> > to the initial INVITE request so this does not seem to have any >>value >> > for the proxies >> > >> > - UAC includes Accept with supported MIME types in INVITE request so >> > why would UAS send any MIME body not wished by the UAC? >> > >> > >> > >> > For Call-Info with purpose=3DemergencyCallData.eCall.control include= d >>in >> > the INFO request >> > >> > - no routing decisions are done by proxies when receiving an >>in-dialog >> > request so this does not seem to have any value for the proxies >> > >> > - support of info package emergencyCallData.eCall.MSD in the call >> > implies that either application/EmergencyCallData.eCall.control+xml >> > MIME body or application/emergencyCallData.eCall.MSD+per MIME body >>is >> > included. Again, according to RFC3261 subclause 8.2.3, the UAS >>anyway >> > needs to check that all the bodies of the INFO request not marked >>with >> > Content-Disposition: ...; handling=3Doptional are understood. So, >> > application/EmergencyCallData.eCall.control+xml MIME body or >> > application/emergencyCallData.eCall.MSD+per MIME body will anyway be >> > found by UAS during the INFO request processing. >> > >> >=20 >>////////////////////////////////////////////////////////////////////// >> > //////// >> > >> > PROPOSED SOLUTION to COMMENT >> > >> >=20 >>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> > \\\\\\\\ >> > >> > Remove insertion of Call-Info header field. >> > >> >=20 >>////////////////////////////////////////////////////////////////////// >> > //////// >> > >> > >> > >> > Kind regards >> > >> > >> > >> > Ivo Sedlacek >> > >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> >=20 >>=20 >>https://www.ietf.org/mailman >>/listinfo/ecrit >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >>=20 >>=20 >>https://www.ietf.org/mailman >>/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >I asked President Reagan what he thought about the IBM PC Jr., >and he replied that he didn't believe in abortions > --Steve Wozniac > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 10 23:00:58 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 8AA6312B01F for ; Wed, 10 Aug 2016 23:00:56 -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 SAjyRSCLZuzY for ; Wed, 10 Aug 2016 23:00:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 DD1E2126FDC for ; Wed, 10 Aug 2016 23:00:53 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-b5-57ac1493f5f8 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 5D.58.02553.3941CA75; Thu, 11 Aug 2016 08:00:52 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 07:59:48 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAMNJ+oAASFKCgACdvIA= Date: Thu, 11 Aug 2016 05:59:48 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.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.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7lO4UkTXhBlM7+SwaFz1ltdiw5TiL xYoNB1gtvj/vYnRg8fj7/gOTx5IlP5k87t66xOSx9c5jlgCWKC6blNSczLLUIn27BK6Mtcsv sRYs1avYNOUXawPjAtUuRg4OCQETibuzorsYuTiEBNYzSqzqPswM4SxhlGj/+4YFpIhNwEKi +592FyMnh4jAXUaJXZu9QWxhgYWMEhceiEDEFzFKLF4uB2EnSUy5eowJxGYRUJXYt+0LI4jN K2Al0fzmPjvE/DksEn2rXoAlOAWMJa6ebmIBsRkFxCS+n1oD1swsIC5x68l8MFtCQEBiyZ7z zBC2qMTLx/9YQWxRAT2J719nQ8UVJdqfNjBC9OpILNj9iQ3Ctpb4uvIvlK0tsWzha2aIgwQl Ts58wjKBUWwWknWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIE xt/BLb8NdjC+fO54iFGAg1GJh3dB9upwIdbEsuLK3EOMEhzMSiK8ngJrwoV4UxIrq1KL8uOL SnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwtoqEf2F/clIxxGFGsZjEefaV /TITm/OC04VDNvWrT0xz3a92e//ErrYFqt33Jh1jfrlvv6q1Z1XbxJxvRf/4H77231ofaPf+ rGJoZsPOGevW/Exe/u1AsX3+Mq4rvxj+Wl5ckJ35QsnvVcO6+5x+e17dizU585/1mWLt689J Otv7Q0pkTacaKrEUZyQaajEXFScCADyI37y7AgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 06:00:56 -0000 Hi, >In reality, there is no separate INFO package negotiation. The >endpoints support the data types not because they support the iNFO >package, but rather they support the INFO package and the data types >and Call-Info because they comply with the draft. Specifications may mandate you to support certain SIP extensions in order to be compliant with the specification, but you still need to comply with the SIP procedures associated with indicating support and using those extensions. Regards, Christer > >At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> I disagree. >> >> The inclusion of the data element in INFO is nothing to do with RFC >> 7852. The data element is included because the use of an >> appropriate Info package has been negotiated and used. That Info >> package definition and the INFO mechanism itself makes no mention >> of use of Call-Info in association with it. >> >> Further I see no justification for complicating any error handling >> by suddenly defining it to be applicable, as it is not necessary. >> INFO requests always contain a data element appropriate to the Info >> package that is defined for its use - it absolutely does not need a >> secondary reference to the package. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 18:20 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Keith, >> >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>> then I have to agree with Ivo. That additional usage is not currently >>> defined in draft-ietf-ecrit-ecall, and I would need to understand that >>> usage before it is included. >>> >>> At the moment RFC7852 is only used for the transfer of MSD in INVITE >>> requests and 200 (OK) responses, and therefore that is the only place >>> where it should appear in association with RFC7852. >> >> RFC 7852 covers use of Call-Info to point to emergency call data >> blocks in any SIP message that is permitted to carry a body. >> >>> >>> Negotiation and transfer of MSD in association with INFO requests is >>> an entirely separate transfer mechanism, not covered by >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>> there as though it had been. Inclusion will lead to complete confusion >>> as to whether the requirements of the INFO mechanism or the >>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >>> absolutely clear that only the former apply. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >>> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hello, >>> >>>> The invite response still has a body with content-disposition >>>> by-reference. If you remove the reference then its processing is >>>> undefined. >>> >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the >>> Content-Disposition header field of the >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition >>> header field of the application/emergencyCallData.eCall.control+xml >>> body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and thus >>> "render" would apply for the >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>> >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >>> Call-Info points to the >>> application/emergencyCallData.eCall.control+xml body. This body >> > contains a delivery report for the MSD sent in INVITE request. This >>is >>> NOT information about callee as described in RFC3261. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- The idea that >> Bill Gates has appeared like a knight in shining armor to lead all >> customers out of a mire of technological chaos neatly ignores the >> fact that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas Adams > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >Einstein never accepted quantum mechanics because of this element >of chance and uncertainty. He said, "God does not play dice." >It seems that Einstein was doubly wrong. The quantum effects >of black holes suggests that not only does God play dice, He >sometimes throws them where they cannot be seen. --Steven Hawking > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 11 00:45: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 B262F12D0BF for ; Thu, 11 Aug 2016 00:45:29 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 HB962BvujJdq for ; Thu, 11 Aug 2016 00:45:27 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 115B912B060 for ; Thu, 11 Aug 2016 00:45:27 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Aug 2016 00:45:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Aug 2016 00:44:16 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "R.Jesske@telekom.de" , "Ivo Sedlacek" , "pkyzivat@alum.mit.edu" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 07:45:30 -0000 At 5:55 AM +0000 8/11/16, Christer Holmberg wrote: > Hi, > >>I see it as one data transfer mechanism, which has additional >>restrictions/impositions when used with INFO. INFO has various >>prohibitions and restrictions and mandates in an attempt to reign in >>the former freewheeling use of INFO as a generic data transfer >>mechanism. In our case, we're using INFO only for mid-call updates, > > We don't have the authority to say "Well, we only use INFO for this > special case, so therefore we don't need to follow RFC 6086". We are following RFC 6086. > > And, most usages of INFO are for a specific purpose. That's the whole idea > of the info package mechanism - to to have a clear scope and semantics of > the usage. > >> >>and only because it seemed at the time to be cleaner than using >>re-INVITE or UPDATE or OPTIONS or something else. If we diverge into >>two entirely separate mechanisms, one just for INFO, then we will do >>a disservice to emergency call processing. > > The difference is on the SIP level. As the same MIME types etc are used, > the applications will see no difference. > > Regards, > > Christer > > > >> >>At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> >>> I fundamentally disagree. We have two different data transfer >>> mechanisms, and the presence of the data should be clearly >>> understood from the appropriate transfer mechanism protocol. >>> >>> So Call-Info applies when RFC 7852 applies, which is the INVITE and >>> 200 (OK) response, and does not when the INFO mechanism is in use. >>> >>> Additionally it only applies when it is pointing to data which is >>> actually attached to the message. >>> >>> Keith >>> >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>R.Jesske@telekom.de >>> Sent: 08 August 2016 10:45 >>> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hi Ivo, >>> using the ecall urn (urn:service:sos.ecall.automatic) does not >>> implicitly means using the MSD within the Body. It could be also an >>> interworked call where all ecall information is included inband >>> using the In-band modem solution. >>> >>> We have to think also on backwards compatibility issues. Thus when >>> moving PSAP's to SIP imply also that there must exist an >>> interworking between the old mobile world towards the new mobile >>> world using SIP. >>> >>> Using the Call-Info header would help the PAST to distinguish the >>> in-band and outband solution. Perhaps it would be worth to define >>> an additional value for inband data, to identify ecalls coming from >>> other networks not supporting the MSD Body. >>> >>> Best Regards >>> >>> Roland. >>> >>> >>> Von: Ecrit >>> [mailto:ecrit-bounces@ietf.org] Im >>> Auftrag von Ivo Sedlacek >>> Gesendet: Montag, 8. August 2016 09:59 >>> An: Paul Kyzivat; ecrit@ietf.org >>> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hello, >>> >>> According to RFC3261, the Call-Info header field provides >>> additional information about the caller or callee. >>> >>> According to draft-ietf-ecrit-ecall-11, the Call-Info header field >>> is used to form a "content-table" of pointers to bodies INVITE >>> request (and of INVITE response, of INFO request) in headers of >>> INVITE request (and of INVITE response, of INFO request). > >> >>> If the Call-Info header field points to a body which describes the >>> callers or callee, then Call-Info semantic fits (even though I >>> would still question usefulness of such Call-Info inclusion). >>> >>> If the Call-Info header field points to a body which request an >>> action in remote UE and which reports to remote UE an outcome of an >>> action done by the local UE, then Call-Info semantic does not fit. >>> >>> Particularly: >>> >>> >>>------------------------------------------------------------------------- >>>----- >>> A PSAP or IVS transmits a metadata/control object (see Section 9) by >>> encoding it per the description in this document and attaching it to >>> a SIP message as a MIME body part per [RFC7852]. The body part is >>> identified by its MIME content-type ('application/ >>> emergencyCallData.eCall.control+xml') in the Content-Type header >>> field of the body part. The body part is assigned a unique >>> identifier which is listed in a Content-ID header field in the body >>> part. The SIP message is marked as containing the metadata/control >>> object by adding (or appending to) a Call-Info header field at the >>> top level of the SIP message. This Call-Info header field contains >>>a >>> CID URL referencing the body part's unique identifier, and a >>> 'purpose' parameter identifying the data as an eCall >>>metadata/control >>> block per the Emergency Call Additional Data Blocks registry entry; >>> the 'purpose' parameter's value is >>>'emergencyCallData.eCall.control'. >>> >>> >>>------------------------------------------------------------------------- >>>----- >>> and >>> >>> >>>------------------------------------------------------------------------- >>>----- >>> SIP/2.0 200 OK >>> To: >>> >>><sip:+13145551111@example.com>;tag=9fxced76 >>>sl >>> From: Exemplar PSAP >>> Call-ID: >>> 3848276298220188511@atlanta.example.com >>> Call-Info: >>> cid:2345678901@atlanta.example.com; >>> purpose=emergencyCallData.eCall.control; >>> Accept: application/sdp, application/pidf+xml, >>> application/emergencyCallData.eCall.control+xml, >>> application/emergencyCallData.eCall.MSD+per >>> CSeq: 31862 INVITE >>> Recv-Info: emergencyCallData.eCall.MSD >>> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >>> SUBSCRIBE, NOTIFY, UPDATE >>> Content-Type: multipart/mixed; boundary=boundaryX >>> Content-Length: ... >>> >>> --boundaryX >>> Content-Type: application/sdp >>> >>> ...Session Description Protocol (SDP) goes here... >>> >>> --boundaryX >>> Content-Type: application/EmergencyCallData.eCall.control+xml >>> Content-ID: >>> 2345678901@atlanta.example.com >>> Content-Disposition: by-reference;handling=optional >>> >>> >>> >> >>>xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>> >>> >>>xmlns:xsi="http://www.w3.org/2 >>>001/XMLSchema-instance" >>> xsi:schemaLocation= >>> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >>> >>> >> >>>ref="1234567890@atlanta.example.co >>>m"/> >>> >>> >>> >>> --boundaryX-- >>> >>> >>>------------------------------------------------------------------------- >>>----- >>> >>> Kind regards >>> >>> Ivo >>> >>> -----Original Message----- >>> From: Ecrit >>> [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Friday, August 05, 2016 4:43 PM >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>> brings no value >>> >>> Ivo, > >> >>> IIUC, you are saying that the Call-Info that refers to the body is > >> unnecessary because the recipient will know what to do with the >>> body even in the absence of the Call-Info. Is that right? >>> >>> This assumption mixes up two things: >>> - understanding a body syntactically >>> - understanding *why* the body is present and how it should be used. >>> >>> Historically, processing of body parts in sip was very poorly defined. >>> Initially the only body of interest was SDP, so how one might >>> process other bodies or body parts was not well considered. >>> Eventually this started to be a liability, so RFC5621 was published >>> to clarify it. >>> >>> Processing of body parts is governed by a complex interaction >>> between Content-Type, Content-Disposition, Content-ID. >>> >>> So the call-info header indicates the reason that body is being >>> included. I realize that there is one predominant reason for doing >>> so, but that is not the only possible reason. (E.g., it might be >>> included as context in an intended discussion about problems >>> handling a call in the >>> past.) >>> >>> If all the handling of the call is coded in a special purpose way, >>> solely for the emergency call path, then alternatives may be of no >>> concern. But ideally the call will largely be handled via standard >>> library code that is also used for other call paths and other >>> message processing. So processing body parts in a "standard" way, >>> rather than special casing, is desirable. >>> >>> Thanks, >>> Paul >>> >>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >>> > Hello, >>> > >>> > >>> > >>> > COMMENT: >>> > >>> > >>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> > \\\\\\\\ >>> > >>> > Inclusion of Call-Info header field with >>> > purpose=emergencyCallData.eCall.MSD or >>> > purpose=emergencyCallData.eCall.control in requests and responses >>>does >>> > not seem to bring any value. It seems to only waste radio resources. >>> > >>> > >>> > >>> > For Call-Info with purpose=emergencyCallData.eCall.MSD included in >>>the >>> > initial INVITE request: >>> > >>> > - if this is meant to be used by a proxy for routing of the eCall >>> > emergency call to a PSAP supporting eCall emergency call, then this >>> > seems to be redundant to the eCall URN included in the Request-URI >>>and >>> > the Recv-Info header field containing eCall specific info package >>> > (emergencyCallData.eCall.MSD). >>> > >>> > - if this is meant to be used by UAS (i.e. PSAP), then according to >>> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all >>> > the bodies of the INVITE request not marked with >>>Content-Disposition: >>> > ...; handling=optional are understood. So, >>> > application/emergencyCallData.eCall.MSD+per MIME body will anyway be >>> > found by UAS during the INVITE request processing. >>> > >>> > >>> > >>> > For Call-Info with purpose=emergencyCallData.eCall.control included >>>in >>> > a response to the initial INVITE request >>> > >>> > - no routing decisions are done by proxies when receiving a response >>> > to the initial INVITE request so this does not seem to have any >>>value >>> > for the proxies >>> > >>> > - UAC includes Accept with supported MIME types in INVITE request so >>> > why would UAS send any MIME body not wished by the UAC? >>> > >>> > >>> > >>> > For Call-Info with purpose=emergencyCallData.eCall.control included >>>in >>> > the INFO request >>> > >>> > - no routing decisions are done by proxies when receiving an >>>in-dialog >>> > request so this does not seem to have any value for the proxies >>> > >>> > - support of info package emergencyCallData.eCall.MSD in the call >>> > implies that either application/EmergencyCallData.eCall.control+xml >>> > MIME body or application/emergencyCallData.eCall.MSD+per MIME body >>>is >>> > included. Again, according to RFC3261 subclause 8.2.3, the UAS >>>anyway >>> > needs to check that all the bodies of the INFO request not marked >>>with >>> > Content-Disposition: ...; handling=optional are understood. So, > >> > application/EmergencyCallData.eCall.control+xml MIME body or > >> > application/emergencyCallData.eCall.MSD+per MIME body will anyway be >>> > found by UAS during the INFO request processing. >>> > >>> > >>>////////////////////////////////////////////////////////////////////// >>> > //////// >>> > >>> > PROPOSED SOLUTION to COMMENT >>> > >>> > >>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> > \\\\\\\\ >>> > >>> > Remove insertion of Call-Info header field. >>> > >>> > >>>////////////////////////////////////////////////////////////////////// >>> > //////// >>> > >>> > >>> > >>> > Kind regards >>> > >>> > >>> > >>> > Ivo Sedlacek >>> > >>> > >>> > >>> > _______________________________________________ >>> > Ecrit mailing list >>> > Ecrit@ietf.org >>> > >>> >>>https://www.ietf.org/mailman >>>/listinfo/ecrit >>> > >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> >>> >>>https://www.ietf.org/mailman >>>/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>I asked President Reagan what he thought about the IBM PC Jr., >>and he replied that he didn't believe in abortions >> --Steve Wozniac >> >>_______________________________________________ >>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: --------------- Probable-Possible, my black hen, She lays eggs in the Relative When. She doesn't lay eggs in the Positive Now Because she's unable to postulate how. --Frederick Winsor, "The Space Child's Mother Goose" [Simon & Schuster 1966], paperback From nobody Thu Aug 11 00:55:10 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 7BF4012D537 for ; Thu, 11 Aug 2016 00:55:04 -0700 (PDT) X-Quarantine-ID: <7wSDqG8y-GzT> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 7wSDqG8y-GzT for ; Thu, 11 Aug 2016 00:55:02 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA7C12D1EA for ; Thu, 11 Aug 2016 00:55:02 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Aug 2016 00:55:01 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Aug 2016 00:54:56 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 07:55:04 -0000 Hi Christer, We are complying, of course. --Randy At 5:59 AM +0000 8/11/16, Christer Holmberg wrote: > Hi, > >>In reality, there is no separate INFO package negotiation. The >>endpoints support the data types not because they support the iNFO >>package, but rather they support the INFO package and the data types >>and Call-Info because they comply with the draft. > > Specifications may mandate you to support certain SIP extensions in order > to be compliant with the specification, but you still need to comply with > the SIP procedures associated with indicating support and using those > extensions. > > Regards, > > Christer > > >> >>At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> I disagree. >>> >>> The inclusion of the data element in INFO is nothing to do with RFC >>> 7852. The data element is included because the use of an >>> appropriate Info package has been negotiated and used. That Info >>> package definition and the INFO mechanism itself makes no mention >>> of use of Call-Info in association with it. >>> >>> Further I see no justification for complicating any error handling >>> by suddenly defining it to be applicable, as it is not necessary. >>> INFO requests always contain a data element appropriate to the Info >>> package that is defined for its use - it absolutely does not need a >>> secondary reference to the package. >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 18:20 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hi Keith, >>> >>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>>> then I have to agree with Ivo. That additional usage is not currently >>>> defined in draft-ietf-ecrit-ecall, and I would need to understand that >>>> usage before it is included. >>>> >>>> At the moment RFC7852 is only used for the transfer of MSD in INVITE >>>> requests and 200 (OK) responses, and therefore that is the only place >>>> where it should appear in association with RFC7852. >>> >>> RFC 7852 covers use of Call-Info to point to emergency call data >>> blocks in any SIP message that is permitted to carry a body. >>> >>>> >>>> Negotiation and transfer of MSD in association with INFO requests is >>>> an entirely separate transfer mechanism, not covered by >>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>> there as though it had been. Inclusion will lead to complete confusion >>>> as to whether the requirements of the INFO mechanism or the >>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >>>> absolutely clear that only the former apply. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >>>> Sent: 10 August 2016 08:41 >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hello, >>>> >>>>> The invite response still has a body with content-disposition >>>>> by-reference. If you remove the reference then its processing is >>>>> undefined. >>>> >>>> If the Call-Info is omitted in INVITE response, then: >>>> Alt1: a new value could be defined and used in the > >>> Content-Disposition header field of the >>>> application/emergencyCallData.eCall.control+xml body; >>>> or >>>> Alt2: an existing value could be used in the Content-Disposition >>>> header field of the application/emergencyCallData.eCall.control+xml >>>> body; >>>> or >>>> Alt3: the Content-Disposition header field can be omitted and thus >>>> "render" would apply for the >>>> application/emergencyCallData.eCall.control+xml body according to >>>> RFC3261 section 13.2.1. >>>> >>>> We cannot use the Call-Info in INVITE response as described in >>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >>>> Call-Info points to the >>>> application/emergencyCallData.eCall.control+xml body. This body >>> > contains a delivery report for the MSD sent in INVITE request. This >>>is >>>> NOT information about callee as described in RFC3261. >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- The idea that >>> Bill Gates has appeared like a knight in shining armor to lead all >>> customers out of a mire of technological chaos neatly ignores the >>> fact that it was he who, by peddling second-rate technology, >>> led them into it in the first place. --Douglas Adams >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>Einstein never accepted quantum mechanics because of this element >>of chance and uncertainty. He said, "God does not play dice." >>It seems that Einstein was doubly wrong. The quantum effects >>of black holes suggests that not only does God play dice, He >>sometimes throws them where they cannot be seen. --Steven Hawking >> >>_______________________________________________ >>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: --------------- The brain is a wonderful organ; it starts working the moment you get up in the morning, and does not stop until you get to work. --Robert Frost From nobody Thu Aug 11 00:59:20 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 83D4A12D6B5 for ; Thu, 11 Aug 2016 00:59:18 -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 dCcOy5x_b2Wi for ; Thu, 11 Aug 2016 00:59:17 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 078D412D5EC for ; Thu, 11 Aug 2016 00:59:16 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-d3-57ac30521b32 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 22.75.02493.2503CA75; Thu, 11 Aug 2016 09:59:14 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 09:59:13 +0200 From: Ivo Sedlacek To: Randall Gellens , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8ysO0ExZlXEZoU6jfl1Bl3eVi6BDZU/Q Date: Thu, 11 Aug 2016 07:59:13 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7gW6QwZpwg5ufrS0aFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Ms5c2s1c8IO5YmdDL2sD 4xTmLkYODgkBE4kT/yq6GLk4hATWM0psmT2THcJZwihx4M15li5GTg42AT2JiVuOsILYIgJV Ep/O3WcDKRIWWMwosWtFKwuIIwLSsfDXRUaIKiOJqRv72UBsFgFVieXvV4JN4hXwlXi8fRfU itUsEu9/fGIHSXAKGEs8m3ETrIhRQFbi6p9esEHMAuISt57MZwKxJQQEJJbsOc8MYYtKvHz8 jxXCVpJYdPszE0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZ VjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERsrBLb+tdjAefO54iFGAg1GJh/fB4tXhQqyJ ZcWVuYcYJTiYlUR48+TWhAvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQ WgSTZeLglGpgDD6bMLnp+o/uc2VbLTVvL0hr9oqZUzLj2YSY3jMKmZ9Mj3y/EdYn19gsMz1q N/vBVM3LDcVZZx2eLjtbsCjQtOv3MuOp6qlJSp/uctTEdvvslDsW8Dv8bfpBFvdDVbnr8u/f n89zTyD+nnxQdMd2mwxh9o3m0s+dnjc+2jchg2W1ypeKsOUlSizFGYmGWsxFxYkAQyqS/ZAC AAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 07:59:19 -0000 Hello, > Use of Call-Info to identify emergency data blocks is defined in RFC 7852= . RFC 7852 does not change RFC3261 so any usage of Call-Info must be complian= t to RFC3261 definition of the Call-Info. I.e. Call-Info must provide addit= ional information about the caller or callee.=20 This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INV= ITE response and INFO request. In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. Kind regards Ivo From nobody Thu Aug 11 01:00:50 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 CE26312D729 for ; Thu, 11 Aug 2016 01:00:48 -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 AV0ojkqVM80U for ; Thu, 11 Aug 2016 01:00:46 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EB7C412D6B1 for ; Thu, 11 Aug 2016 01:00:45 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-6a-57ac30acc31a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id ED.4E.04209.BA03CA75; Thu, 11 Aug 2016 10:00:44 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.233]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 10:00:36 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , "R.Jesske@telekom.de" , "Ivo Sedlacek" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR86RVl6L3FqkxAk60MvRVQQz8waBDd2MA Date: Thu, 11 Aug 2016 08:00:36 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.5.160527 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+NgFtrCIsWRmVeSWpSXmKPExsUyM+Jvje4agzXhBi++8ls0LnrKarFhy3EW ixUbDrBaNN3pYrP4/ryL0YHV4+/7D0weS5b8ZPK4e+sSk8fWO49ZPNpeKgSwRnHZpKTmZJal FunbJXBlfGj+z1JwvKaif0kbawNjR1IXIyeHhICJxN6fs9m6GLk4hAQ2MEocXXiKEcJZwiix 6s8S1i5GDg42AQuJ7n/aIHERgelMEtdPXGMCcYQFFjNKnD94nx0iA9Sx8NdFRpC5IgJGEo8e r2UBsVkEVCVWze5jArF5Bawk9k0+xQZiC4GM6rvlBWJzChhLTN/yDyzOKCAm8f3UGrB6ZgFx iVtP5jNB3CogsWTPeWYIW1Ti5eN/rCC2qICexPevs6HiihLtTxsYIXr1JG5MncIGYVtLfHm1 ix3C1pZYtvA1M8Q9ghInZz5hmcAoNgvJullI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPVS izKTi4vz8/TyUks2MQLj8uCW36o7GC+/cTzEKMDBqMTDuyB7dbgQa2JZcWXuIUYJDmYlEd48 uTXhQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhi7o7Vf PVeX3L9vedh73yNZ81W88p++2ZJWK6Hb2x3R6Gs/wyzf92RTdvusnnWPzhdN/xFcePFeEHPe iesV05iiM/+W9Fef4sixfj3restupuvai19kFHl/NV3TEbTLz+xLitD/fsuK/TqzNWeu4Ogy ial7MeHy/bvNW9we/hMrfrj368JrOwKVWIozEg21mIuKEwFq3qc+xwIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 08:00:49 -0000 Hi, >>>I see it as one data transfer mechanism, which has additional >>>restrictions/impositions when used with INFO. INFO has various >>>prohibitions and restrictions and mandates in an attempt to reign in >>>the former freewheeling use of INFO as a generic data transfer >>>mechanism. In our case, we're using INFO only for mid-call updates, >> >> We don't have the authority to say "Well, we only use INFO for this >> special case, so therefore we don't need to follow RFC 6086". > >We are following RFC 6086. Yes, but it seems you only want to do it for =B3cosmetic purpose=B2, becaus= e you still want to use 7852 for INFO. Again, as per RFC 6086, the semantics of the MIMEs shall be described by by the info package specification. Whether the info package is used for some =B3special purpose=B2 and/or =B3between a small set of devices" is irrelevant. Regards, Christer > >> >> And, most usages of INFO are for a specific purpose. That's the whole >>idea >> of the info package mechanism - to to have a clear scope and semantics >>of >> the usage. >> >>> >>>and only because it seemed at the time to be cleaner than using >>>re-INVITE or UPDATE or OPTIONS or something else. If we diverge into >>>two entirely separate mechanisms, one just for INFO, then we will do >>>a disservice to emergency call processing. >> >> The difference is on the SIP level. As the same MIME types etc are >>used, >> the applications will see no difference. >> >> Regards, >> >> Christer >> >> >> >>> >>>At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> >>>> I fundamentally disagree. We have two different data transfer >>>> mechanisms, and the presence of the data should be clearly >>>> understood from the appropriate transfer mechanism protocol. >>>> >>>> So Call-Info applies when RFC 7852 applies, which is the INVITE and >>>> 200 (OK) response, and does not when the INFO mechanism is in use. >>>> >>>> Additionally it only applies when it is pointing to data which is >>>> actually attached to the message. >>>> >>>> Keith >>>> >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>>R.Jesske@telekom.de >>>> Sent: 08 August 2016 10:45 >>>> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Ivo, >>>> using the ecall urn (urn:service:sos.ecall.automatic) does not >>>> implicitly means using the MSD within the Body. It could be also an >>>> interworked call where all ecall information is included inband >>>> using the In-band modem solution. >>>> >>>> We have to think also on backwards compatibility issues. Thus when >>>> moving PSAP's to SIP imply also that there must exist an >>>> interworking between the old mobile world towards the new mobile >>>> world using SIP. >>>> >>>> Using the Call-Info header would help the PAST to distinguish the >>>> in-band and outband solution. Perhaps it would be worth to define >>>> an additional value for inband data, to identify ecalls coming from >>>> other networks not supporting the MSD Body. >>>> >>>> Best Regards >>>> >>>> Roland. >>>> >>>> >>>> Von: Ecrit >>>> [mailto:ecrit-bounces@ietf.org] Im >>>> Auftrag von Ivo Sedlacek >>>> Gesendet: Montag, 8. August 2016 09:59 >>>> An: Paul Kyzivat; ecrit@ietf.org >>>> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hello, >>>> >>>> According to RFC3261, the Call-Info header field provides >>>> additional information about the caller or callee. >>>> >>>> According to draft-ietf-ecrit-ecall-11, the Call-Info header field >>>> is used to form a "content-table" of pointers to bodies INVITE >>>> request (and of INVITE response, of INFO request) in headers of >>>> INVITE request (and of INVITE response, of INFO request). >> >> >>>> If the Call-Info header field points to a body which describes the >>>> callers or callee, then Call-Info semantic fits (even though I >>>> would still question usefulness of such Call-Info inclusion). >>>> >>>> If the Call-Info header field points to a body which request an >>>> action in remote UE and which reports to remote UE an outcome of an >>>> action done by the local UE, then Call-Info semantic does not fit. >>>> >>>> Particularly: >>>> >>>> >>>>----------------------------------------------------------------------- >>>>-- >>>>----- >>>> A PSAP or IVS transmits a metadata/control object (see Section >>>>9) by >>>> encoding it per the description in this document and attaching >>>>it to >>>> a SIP message as a MIME body part per [RFC7852]. The body part >>>>is >>>> identified by its MIME content-type ('application/ >>>> emergencyCallData.eCall.control+xml') in the Content-Type header >>>> field of the body part. The body part is assigned a unique >>>> identifier which is listed in a Content-ID header field in the >>>>body >>>> part. The SIP message is marked as containing the >>>>metadata/control >>>> object by adding (or appending to) a Call-Info header field at >>>>the >>>> top level of the SIP message. This Call-Info header field >>>>contains >>>>a >>>> CID URL referencing the body part's unique identifier, and a >>>> 'purpose' parameter identifying the data as an eCall >>>>metadata/control >>>> block per the Emergency Call Additional Data Blocks registry >>>>entry; >>>> the 'purpose' parameter's value is >>>>'emergencyCallData.eCall.control'. >>>> >>>> >>>>----------------------------------------------------------------------- >>>>-- >>>>----- >>>> and >>>> >>>> >>>>----------------------------------------------------------------------- >>>>-- >>>>----- >>>> SIP/2.0 200 OK >>>> To: >>>> >>>><sip:+13145551111@example.com>;tag=3D9fxc= ed >>>>76 >>>>sl >>>> From: Exemplar PSAP >>>> Call-ID: >>>> 3848276298220188511@atlanta.example.com >>>> Call-Info: >>>> =20 >>>>cid:2345678901@atlanta.example.com; >>>> purpose=3DemergencyCallData.eCall.control; >>>> Accept: application/sdp, application/pidf+xml, >>>> application/emergencyCallData.eCall.control+xml, >>>> application/emergencyCallData.eCall.MSD+per >>>> CSeq: 31862 INVITE >>>> Recv-Info: emergencyCallData.eCall.MSD >>>> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >>>> SUBSCRIBE, NOTIFY, UPDATE >>>> Content-Type: multipart/mixed; boundary=3DboundaryX >>>> Content-Length: ... >>>> >>>> --boundaryX >>>> Content-Type: application/sdp >>>> >>>> ...Session Description Protocol (SDP) goes here... >>>> >>>> --boundaryX >>>> Content-Type: application/EmergencyCallData.eCall.control+xml >>>> Content-ID: >>>> 2345678901@atlanta.example.com >>>> Content-Disposition: by-reference;handling=3Doptional >>>> >>>> >>>> >>> =20 >>>>xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>>> >>>> >>>>xmlns:xsi=3D"http://www.w3.o= rg >>>>/2 >>>>001/XMLSchema-instance" >>>> xsi:schemaLocation=3D >>>> =20 >>>>"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >>>> >>>> >>> >>>>ref=3D"1234567890@atlanta.exampl= e. >>>>co >>>>m"/> >>>> >>>> >>>> >>>> --boundaryX-- >>>> >>>> >>>>----------------------------------------------------------------------- >>>>-- >>>>----- >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> -----Original Message----- >>>> From: Ecrit >>>> [mailto:ecrit-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Friday, August 05, 2016 4:43 PM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>> brings no value >>>> >>>> Ivo, >> >> >>>> IIUC, you are saying that the Call-Info that refers to the body is >> >> unnecessary because the recipient will know what to do with the >>>> body even in the absence of the Call-Info. Is that right? >>>> >>>> This assumption mixes up two things: >>>> - understanding a body syntactically >>>> - understanding *why* the body is present and how it should be used. >>>> >>>> Historically, processing of body parts in sip was very poorly >>>>defined. >>>> Initially the only body of interest was SDP, so how one might >>>> process other bodies or body parts was not well considered. >>>> Eventually this started to be a liability, so RFC5621 was published >>>> to clarify it. >>>> >>>> Processing of body parts is governed by a complex interaction >>>> between Content-Type, Content-Disposition, Content-ID. >>>> >>>> So the call-info header indicates the reason that body is being >>>> included. I realize that there is one predominant reason for doing >>>> so, but that is not the only possible reason. (E.g., it might be >>>> included as context in an intended discussion about problems >>>> handling a call in the >>>> past.) >>>> >>>> If all the handling of the call is coded in a special purpose way, >>>> solely for the emergency call path, then alternatives may be of no >>>> concern. But ideally the call will largely be handled via standard >>>> library code that is also used for other call paths and other >>>> message processing. So processing body parts in a "standard" way, >>>> rather than special casing, is desirable. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >>>> > Hello, >>>> > >>>> > >>>> > >>>> > COMMENT: >>>> > >>>> > >>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> > \\\\\\\\ >>>> > >>>> > Inclusion of Call-Info header field with >>>> > purpose=3DemergencyCallData.eCall.MSD or >>>> > purpose=3DemergencyCallData.eCall.control in requests and respons= es >>>>does >>>> > not seem to bring any value. It seems to only waste radio >>>>resources. >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.MSD included >>>>in >>>>the >>>> > initial INVITE request: >>>> > >>>> > - if this is meant to be used by a proxy for routing of the eCall >>>> > emergency call to a PSAP supporting eCall emergency call, then >>>>this >>>> > seems to be redundant to the eCall URN included in the >>>>Request-URI >>>>and >>>> > the Recv-Info header field containing eCall specific info package >>>> > (emergencyCallData.eCall.MSD). >>>> > >>>> > - if this is meant to be used by UAS (i.e. PSAP), then according >>>>to >>>> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that >>>>all >>>> > the bodies of the INVITE request not marked with >>>>Content-Disposition: >>>> > ...; handling=3Doptional are understood. So, >>>> > application/emergencyCallData.eCall.MSD+per MIME body will >>>>anyway be >>>> > found by UAS during the INVITE request processing. >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.control >>>>included >>>>in >>>> > a response to the initial INVITE request >>>> > >>>> > - no routing decisions are done by proxies when receiving a >>>>response >>>> > to the initial INVITE request so this does not seem to have any >>>>value >>>> > for the proxies >>>> > >>>> > - UAC includes Accept with supported MIME types in INVITE >>>>request so >>>> > why would UAS send any MIME body not wished by the UAC? >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.control >>>>included >>>>in >>>> > the INFO request >>>> > >>>> > - no routing decisions are done by proxies when receiving an >>>>in-dialog >>>> > request so this does not seem to have any value for the proxies >>>> > >>>> > - support of info package emergencyCallData.eCall.MSD in the call >>>> > implies that either >>>>application/EmergencyCallData.eCall.control+xml >>>> > MIME body or application/emergencyCallData.eCall.MSD+per MIME >>>>body >>>>is >>>> > included. Again, according to RFC3261 subclause 8.2.3, the UAS >>>>anyway >>>> > needs to check that all the bodies of the INFO request not marked >>>>with >>>> > Content-Disposition: ...; handling=3Doptional are understood. So, >> >> > application/EmergencyCallData.eCall.control+xml MIME body or >> >> > application/emergencyCallData.eCall.MSD+per MIME body will >>anyway be >>>> > found by UAS during the INFO request processing. >>>> > >>>> > >>>>////////////////////////////////////////////////////////////////////// >>>> > //////// >>>> > >>>> > PROPOSED SOLUTION to COMMENT >>>> > >>>> > >>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> > \\\\\\\\ >>>> > >>>> > Remove insertion of Call-Info header field. >>>> > >>>> > >>>>////////////////////////////////////////////////////////////////////// >>>> > //////// >>>> > >>>> > >>>> > >>>> > Kind regards >>>> > >>>> > >>>> > >>>> > Ivo Sedlacek >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Ecrit mailing list >>>> > Ecrit@ietf.org >>>> > >>>> >>>>https://www.ietf.org/mailm >>>>an >>>>/listinfo/ecrit >>>> > >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> >>>> >>>>https://www.ietf.org/mailm >>>>an >>>>/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>>-- >>>Randall Gellens >>>Opinions are personal; facts are suspect; I speak for myself only >>>-------------- Randomly selected tag: --------------- >>>I asked President Reagan what he thought about the IBM PC Jr., >>>and he replied that he didn't believe in abortions >>> --Steve Wozniac >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >Probable-Possible, my black hen, >She lays eggs in the Relative When. >She doesn't lay eggs in the Positive Now >Because she's unable to postulate how. > --Frederick Winsor, "The Space Child's Mother Goose" > [Simon & Schuster 1966], paperback From nobody Thu Aug 11 05:39:47 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 CFF1C12D13D for ; Thu, 11 Aug 2016 05:39:45 -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 sW-dHKDFTNkX for ; Thu, 11 Aug 2016 05:39:44 -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 D40A412D0B5 for ; Thu, 11 Aug 2016 05:39:43 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 04AF62BD97141; Thu, 11 Aug 2016 12:39:39 +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 u7BCdf6X004883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 12:39:41 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 u7BCdep7012879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Aug 2016 14:39:40 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 11 Aug 2016 14:39:40 +0200 From: "Drage, Keith (Nokia - GB)" To: Ivo Sedlacek , Randall Gellens , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8ysOl8HncDiLd0qZ6APr7B+knaBDZU/QgABOF8A= Date: Thu, 11 Aug 2016 12:39:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF45926@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 12:39:46 -0000 Can you clarify whether this is a comment that RFC 7852 is not compliant wi= th RFC 3261 or that draft-ietf-ecrit-ecall is not compliant with RFC 3261? Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 11 August 2016 08:59 To: Randall Gellens; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hello, > Use of Call-Info to identify emergency data blocks is defined in RFC 7852= . RFC 7852 does not change RFC3261 so any usage of Call-Info must be complian= t to RFC3261 definition of the Call-Info. I.e. Call-Info must provide addit= ional information about the caller or callee.=20 This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INV= ITE response and INFO request. In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. Kind regards Ivo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 11 05:43:36 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 EC07012D0E2 for ; Thu, 11 Aug 2016 05:43:35 -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 BfnUubO6pnWf for ; Thu, 11 Aug 2016 05:43:34 -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 AC6F912D0B5 for ; Thu, 11 Aug 2016 05:43:33 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A63684C2832D0; Thu, 11 Aug 2016 12:43: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 u7BChS2O006449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 12:43:28 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 u7BChRXw032689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Aug 2016 14:43:28 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 11 Aug 2016 14:43:06 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Ivo Sedlacek , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR80+YOUrxZW8FyU+CURilMOjGiaBDtM4g Date: Thu, 11 Aug 2016 12:43:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF45947@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 12:43:36 -0000 I fundamentally cannot agree to this statement. I thought we had agreed that the INFO package would be used, and this state= ment is absolutely denying that. Chairs, please intervene with your understanding of the current consensus. Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 10 August 2016 22:39 To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) In reality, there is no separate INFO package negotiation. The endpoints s= upport the data types not because they support the iNFO package, but rather= they support the INFO package and the data types and Call-Info because the= y comply with the draft. At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > I disagree. > > The inclusion of the data element in INFO is nothing to do with RFC=20 > 7852. The data element is included because the use of an appropriate=20 > Info package has been negotiated and used. That Info package=20 > definition and the INFO mechanism itself makes no mention of use of=20 > Call-Info in association with it. > > Further I see no justification for complicating any error handling by=20 > suddenly defining it to be applicable, as it is not necessary. > INFO requests always contain a data element appropriate to the Info=20 > package that is defined for its use - it absolutely does not need a=20 > secondary reference to the package. > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 10 August 2016 18:20 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat;=20 > ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > Hi Keith, > > At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> Unless someone is defining a new usage for Call-Info beyond RFC7852 =20 >> then I have to agree with Ivo. That additional usage is not currently =20 >> defined in draft-ietf-ecrit-ecall, and I would need to understand=20 >> that usage before it is included. >> >> At the moment RFC7852 is only used for the transfer of MSD in=20 >> INVITE requests and 200 (OK) responses, and therefore that is the=20 >> only place where it should appear in association with RFC7852. > > RFC 7852 covers use of Call-Info to point to emergency call data=20 > blocks in any SIP message that is permitted to carry a body. > >> >> Negotiation and transfer of MSD in association with INFO requests=20 >> is an entirely separate transfer mechanism, not covered by =20 >> draft-ietf-ecrit-data-only-ea and therefore it should never appear =20 >> there as though it had been. Inclusion will lead to complete=20 >> confusion as to whether the requirements of the INFO mechanism or=20 >> the requirements of draft-ietf-ecrit-data-only-ea apply, when it=20 >> should be absolutely clear that only the former apply. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >> Sent: 10 August 2016 08:41 >> To: Paul Kyzivat; ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not =20 >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info =20 >> usage brings no value) >> >> Hello, >> >>> The invite response still has a body with content-disposition =20 >>> by-reference. If you remove the reference then its processing is =20 >>> undefined. >> >> If the Call-Info is omitted in INVITE response, then: >> Alt1: a new value could be defined and used in the =20 >> Content-Disposition header field of the =20 >> application/emergencyCallData.eCall.control+xml body; >> or >> Alt2: an existing value could be used in the Content-Disposition =20 >> header field of the application/emergencyCallData.eCall.control+xml >> body; >> or >> Alt3: the Content-Disposition header field can be omitted and thus =20 >> "render" would apply for the =20 >> application/emergencyCallData.eCall.control+xml body according to >> RFC3261 section 13.2.1. >> >> We cannot use the Call-Info in INVITE response as described in >> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request,=20 >> the Call-Info points to the =20 >> application/emergencyCallData.eCall.control+xml body. This body > > contains a delivery report for the MSD sent in INVITE request.=20 > This is >> NOT information about callee as described in RFC3261. >> >> Kind regards >> >> Ivo >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- The idea that=20 > Bill Gates has appeared like a knight in shining armor to lead all=20 > customers out of a mire of technological chaos neatly ignores the fact=20 > that it was he who, by peddling second-rate technology, > led them into it in the first place. --Douglas Adams -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Einstein never accept= ed quantum mechanics because of this element of chance and uncertainty. He = said, "God does not play dice." It seems that Einstein was doubly wrong. The quantum effects of black holes= suggests that not only does God play dice, He sometimes throws them where = they cannot be seen. --Steven Hawking From nobody Thu Aug 11 06:09:19 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 A7E6C12D0C0 for ; Thu, 11 Aug 2016 06:09:17 -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 Qi_Okw-gUP_O for ; Thu, 11 Aug 2016 06:09:14 -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 C060A12B044 for ; Thu, 11 Aug 2016 06:09:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DF8AED73FE7D; Thu, 11 Aug 2016 13:09: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 u7BD9B8P014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Aug 2016 13:09:11 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 u7BD7uHW013496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Aug 2016 15:09:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.217]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 11 Aug 2016 15:08:25 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , Randall Gellens , "R.Jesske@telekom.de" , "Ivo Sedlacek" , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR86RgSZMHjeUNxE+dxrNuHnssvaBDRBIAgAB1cEA= Date: Thu, 11 Aug 2016 13:08:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF4596C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.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.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 13:09:17 -0000 I think I need to state how I see ecrit operating. I see some sort of supporting ecrit "application" in the PSAP and the calli= ng UA. That supporting application initiates two independent data transport= mechanisms within SIP, using RFC 7852 for the initial MSD and the data res= ponse to indicate support of MSD reception, and using RFC 6086 for any subs= equent MSD. SIP itself knows nothing about the relationship between these t= wo mechanisms, only the ecrit "application". It is the ecrit "application" = that performs the combination of the data received using the two data trans= fer mechanisms as appropriate. The MSDs transferred using the two mechanisms following identical syntax an= d coding, but that is merely a matter of convenient definition. As such, use of Call-Info in INFO would be entirely inappropriate, because = INFO does not transfer additional-data according to RFC 7852. Note that RFC 7842 is only used by ecrit in the initial INVITE transaction,= and appearance in subsequent messages of any form would not be expected by= the recipient PSAP. I believe the above is the correct usage of these mechanisms, as opposed to= that put forward by the current draft author. Regards Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 11 August 2016 09:01 To: Randall Gellens; Drage, Keith (Nokia - GB); R.Jesske@telekom.de; Ivo Se= dlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi, >>>I see it as one data transfer mechanism, which has additional=20 >>>restrictions/impositions when used with INFO. INFO has various=20 >>>prohibitions and restrictions and mandates in an attempt to reign in=20 >>>the former freewheeling use of INFO as a generic data transfer=20 >>>mechanism. In our case, we're using INFO only for mid-call updates, >> >> We don't have the authority to say "Well, we only use INFO for this =20 >> special case, so therefore we don't need to follow RFC 6086". > >We are following RFC 6086. Yes, but it seems you only want to do it for =B3cosmetic purpose=B2, becaus= e you still want to use 7852 for INFO. Again, as per RFC 6086, the semantics of the MIMEs shall be described by by= the info package specification. Whether the info package is used for some = =B3special purpose=B2 and/or =B3between a small set of devices" is irreleva= nt. Regards, Christer > >> >> And, most usages of INFO are for a specific purpose. That's the=20 >>whole idea >> of the info package mechanism - to to have a clear scope and=20 >>semantics of >> the usage. >> >>> >>>and only because it seemed at the time to be cleaner than using=20 >>>re-INVITE or UPDATE or OPTIONS or something else. If we diverge into=20 >>>two entirely separate mechanisms, one just for INFO, then we will do=20 >>>a disservice to emergency call processing. >> >> The difference is on the SIP level. As the same MIME types etc are=20 >>used, >> the applications will see no difference. >> >> Regards, >> >> Christer >> >> >> >>> >>>At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> >>>> I fundamentally disagree. We have two different data transfer =20 >>>> mechanisms, and the presence of the data should be clearly =20 >>>> understood from the appropriate transfer mechanism protocol. >>>> >>>> So Call-Info applies when RFC 7852 applies, which is the INVITE=20 >>>> and >>>> 200 (OK) response, and does not when the INFO mechanism is in use. >>>> >>>> Additionally it only applies when it is pointing to data which is =20 >>>> actually attached to the message. >>>> >>>> Keith >>>> >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 >>>>R.Jesske@telekom.de >>>> Sent: 08 August 2016 10:45 >>>> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>>>not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Ivo, >>>> using the ecall urn (urn:service:sos.ecall.automatic) does not =20 >>>> implicitly means using the MSD within the Body. It could be also an =20 >>>> interworked call where all ecall information is included inband =20 >>>> using the In-band modem solution. >>>> >>>> We have to think also on backwards compatibility issues. Thus=20 >>>> when moving PSAP's to SIP imply also that there must exist an =20 >>>> interworking between the old mobile world towards the new mobile =20 >>>> world using SIP. >>>> >>>> Using the Call-Info header would help the PAST to distinguish the =20 >>>> in-band and outband solution. Perhaps it would be worth to define =20 >>>> an additional value for inband data, to identify ecalls coming from =20 >>>> other networks not supporting the MSD Body. >>>> >>>> Best Regards >>>> >>>> Roland. >>>> >>>> >>>> Von: Ecrit >>>> [mailto:ecrit-bounces@ietf.org] Im =20 >>>> Auftrag von Ivo Sedlacek >>>> Gesendet: Montag, 8. August 2016 09:59 >>>> An: Paul Kyzivat; ecrit@ietf.org >>>> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not =20 >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info =20 >>>> usage brings no value) >>>> >>>> Hello, >>>> >>>> According to RFC3261, the Call-Info header field provides =20 >>>> additional information about the caller or callee. >>>> >>>> According to draft-ietf-ecrit-ecall-11, the Call-Info header=20 >>>> field is used to form a "content-table" of pointers to bodies=20 >>>> INVITE request (and of INVITE response, of INFO request) in=20 >>>> headers of INVITE request (and of INVITE response, of INFO request). >> >> >>>> If the Call-Info header field points to a body which describes=20 >>>> the callers or callee, then Call-Info semantic fits (even though I =20 >>>> would still question usefulness of such Call-Info inclusion). >>>> >>>> If the Call-Info header field points to a body which request an =20 >>>> action in remote UE and which reports to remote UE an outcome of an =20 >>>> action done by the local UE, then Call-Info semantic does not fit. >>>> >>>> Particularly: >>>> >>>> >>>>-------------------------------------------------------------------- >>>>--- >>>>-- >>>>----- >>>> A PSAP or IVS transmits a metadata/control object (see Section >>>>9) by >>>> encoding it per the description in this document and attaching=20 >>>>it to >>>> a SIP message as a MIME body part per [RFC7852]. The body=20 >>>>part is >>>> identified by its MIME content-type ('application/ >>>> emergencyCallData.eCall.control+xml') in the Content-Type header >>>> field of the body part. The body part is assigned a unique >>>> identifier which is listed in a Content-ID header field in the=20 >>>>body >>>> part. The SIP message is marked as containing the=20 >>>>metadata/control >>>> object by adding (or appending to) a Call-Info header field at=20 >>>>the >>>> top level of the SIP message. This Call-Info header field=20 >>>>contains a >>>> CID URL referencing the body part's unique identifier, and a >>>> 'purpose' parameter identifying the data as an eCall=20 >>>>metadata/control >>>> block per the Emergency Call Additional Data Blocks registry=20 >>>>entry; >>>> the 'purpose' parameter's value is=20 >>>>'emergencyCallData.eCall.control'. >>>> >>>> >>>>-------------------------------------------------------------------- >>>>--- >>>>-- >>>>----- >>>> and >>>> >>>> >>>>-------------------------------------------------------------------- >>>>--- >>>>-- >>>>----- >>>> SIP/2.0 200 OK >>>> To: >>>> >>>><sip:+13145551111@example.com>;tag=3D9fx >>>>ced >>>>76 >>>>sl >>>> From: Exemplar PSAP >>>> Call-ID: >>>> 3848276298220188511@atlanta.example.com >>>> Call-Info: >>>> =20 >>>>cid:2345678901@atlanta.example.com; >>>> purpose=3DemergencyCallData.eCall.control; >>>> Accept: application/sdp, application/pidf+xml, >>>> application/emergencyCallData.eCall.control+xml, >>>> application/emergencyCallData.eCall.MSD+per >>>> CSeq: 31862 INVITE >>>> Recv-Info: emergencyCallData.eCall.MSD >>>> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >>>> SUBSCRIBE, NOTIFY, UPDATE >>>> Content-Type: multipart/mixed; boundary=3DboundaryX >>>> Content-Length: ... >>>> >>>> --boundaryX >>>> Content-Type: application/sdp >>>> >>>> ...Session Description Protocol (SDP) goes here... >>>> >>>> --boundaryX >>>> Content-Type: application/EmergencyCallData.eCall.control+xml >>>> Content-ID: >>>> 2345678901@atlanta.example.com >>>> Content-Disposition: by-reference;handling=3Doptional >>>> >>>> >>>> >>> =20 >>>>xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>>> >>>> >>>>xmlns:xsi=3D"http://www.w3. >>>>org >>>>/2 >>>>001/XMLSchema-instance" >>>> xsi:schemaLocation=3D >>>> =20 >>>>"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >>>> >>>> >>> >>>>ref=3D"1234567890@atlanta.exampl= e. >>>>co >>>>m"/> >>>> >>>> >>>> >>>> --boundaryX-- >>>> >>>> >>>>-------------------------------------------------------------------- >>>>--- >>>>-- >>>>----- >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> -----Original Message----- >>>> From: Ecrit >>>> [mailto:ecrit-bounces@ietf.org] On =20 >>>> Behalf Of Paul Kyzivat >>>> Sent: Friday, August 05, 2016 4:43 PM >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage =20 >>>> brings no value >>>> >>>> Ivo, >> >> >>>> IIUC, you are saying that the Call-Info that refers to the body=20 >>>> is >> >> unnecessary because the recipient will know what to do with the >>>> body even in the absence of the Call-Info. Is that right? >>>> >>>> This assumption mixes up two things: >>>> - understanding a body syntactically >>>> - understanding *why* the body is present and how it should be used. >>>> >>>> Historically, processing of body parts in sip was very poorly=20 >>>>defined. >>>> Initially the only body of interest was SDP, so how one might >>>> process other bodies or body parts was not well considered. >>>> Eventually this started to be a liability, so RFC5621 was=20 >>>>published >>>> to clarify it. >>>> >>>> Processing of body parts is governed by a complex interaction =20 >>>> between Content-Type, Content-Disposition, Content-ID. >>>> >>>> So the call-info header indicates the reason that body is being =20 >>>> included. I realize that there is one predominant reason for doing =20 >>>> so, but that is not the only possible reason. (E.g., it might be =20 >>>> included as context in an intended discussion about problems =20 >>>> handling a call in the >>>> past.) >>>> >>>> If all the handling of the call is coded in a special purpose=20 >>>> way, solely for the emergency call path, then alternatives may be=20 >>>> of no concern. But ideally the call will largely be handled via=20 >>>> standard library code that is also used for other call paths and=20 >>>> other message processing. So processing body parts in a "standard"=20 >>>> way, rather than special casing, is desirable. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >>>> > Hello, >>>> > >>>> > >>>> > >>>> > COMMENT: >>>> > >>>> > >>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> > \\\\\\\\ >>>> > >>>> > Inclusion of Call-Info header field with >>>> > purpose=3DemergencyCallData.eCall.MSD or >>>> > purpose=3DemergencyCallData.eCall.control in requests and=20 >>>>responses does >>>> > not seem to bring any value. It seems to only waste radio=20 >>>>resources. >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.MSD=20 >>>>included in the >>>> > initial INVITE request: >>>> > >>>> > - if this is meant to be used by a proxy for routing of the eCall >>>> > emergency call to a PSAP supporting eCall emergency call, then=20 >>>>this >>>> > seems to be redundant to the eCall URN included in the=20 >>>>Request-URI and >>>> > the Recv-Info header field containing eCall specific info package >>>> > (emergencyCallData.eCall.MSD). >>>> > >>>> > - if this is meant to be used by UAS (i.e. PSAP), then=20 >>>>according to >>>> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check=20 >>>>that all >>>> > the bodies of the INVITE request not marked with >>>>Content-Disposition: >>>> > ...; handling=3Doptional are understood. So, >>>> > application/emergencyCallData.eCall.MSD+per MIME body will=20 >>>>anyway be >>>> > found by UAS during the INVITE request processing. >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.control >>>>included >>>>in >>>> > a response to the initial INVITE request >>>> > >>>> > - no routing decisions are done by proxies when receiving a=20 >>>>response >>>> > to the initial INVITE request so this does not seem to have=20 >>>>any value >>>> > for the proxies >>>> > >>>> > - UAC includes Accept with supported MIME types in INVITE=20 >>>>request so >>>> > why would UAS send any MIME body not wished by the UAC? >>>> > >>>> > >>>> > >>>> > For Call-Info with purpose=3DemergencyCallData.eCall.control >>>>included >>>>in >>>> > the INFO request >>>> > >>>> > - no routing decisions are done by proxies when receiving an=20 >>>>in-dialog >>>> > request so this does not seem to have any value for the proxies >>>> > >>>> > - support of info package emergencyCallData.eCall.MSD in the call >>>> > implies that either >>>>application/EmergencyCallData.eCall.control+xml >>>> > MIME body or application/emergencyCallData.eCall.MSD+per MIME=20 >>>>body is >>>> > included. Again, according to RFC3261 subclause 8.2.3, the UAS=20 >>>>anyway >>>> > needs to check that all the bodies of the INFO request not=20 >>>>marked with >>>> > Content-Disposition: ...; handling=3Doptional are understood.=20 >>>>So, >> >> > application/EmergencyCallData.eCall.control+xml MIME body or >> >> > application/emergencyCallData.eCall.MSD+per MIME body will >>anyway be >>>> > found by UAS during the INFO request processing. >>>> > >>>> > >>>>////////////////////////////////////////////////////////////////////// >>>> > //////// >>>> > >>>> > PROPOSED SOLUTION to COMMENT >>>> > >>>> > >>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>> > \\\\\\\\ >>>> > >>>> > Remove insertion of Call-Info header field. >>>> > >>>> > >>>>////////////////////////////////////////////////////////////////////// >>>> > //////// >>>> > >>>> > >>>> > >>>> > Kind regards >>>> > >>>> > >>>> > >>>> > Ivo Sedlacek >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Ecrit mailing list >>>> > Ecrit@ietf.org >>>> > >>>> >>>>https://www.ietf.org/ma >>>>ilm >>>>an >>>>/listinfo/ecrit >>>> > >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> >>>> >>>>https://www.ietf.org/ma >>>>ilm >>>>an >>>>/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>>-- >>>Randall Gellens >>>Opinions are personal; facts are suspect; I speak for myself only >>>-------------- Randomly selected tag: --------------- I asked=20 >>>President Reagan what he thought about the IBM PC Jr., and he replied=20 >>>that he didn't believe in abortions >>> --Steve Wozniac >>> >>>_______________________________________________ >>>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: ---------------=20 >Probable-Possible, my black hen, She lays eggs in the Relative When. >She doesn't lay eggs in the Positive Now Because she's unable to=20 >postulate how. > --Frederick Winsor, "The Space Child's Mother Goose" > [Simon & Schuster 1966], paperback From nobody Thu Aug 11 06:51: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 A0D6B12D612 for ; Thu, 11 Aug 2016 06:51:30 -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 59mE9nvesOY1 for ; Thu, 11 Aug 2016 06:51:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 6ECA612D581 for ; Thu, 11 Aug 2016 06:51:28 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-5c-57ac82de03ac Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 10.B9.02553.ED28CA75; Thu, 11 Aug 2016 15:51:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 15:51:10 +0200 From: Ivo Sedlacek To: "Drage, Keith (Nokia - GB)" , Randall Gellens , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR881veOiupPJHTkyMh3h6vs29d6BDwRrQ Date: Thu, 11 Aug 2016 13:51:09 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C4414@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF45926@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF45926@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9UPde05pwg+/bdS0aFz1ltdiw5TiL xYoNB1gtvj/vYnRg8fj7/gOTx5IlP5k87t66xOSx9c5jlgCWKC6blNSczLLUIn27BK6M+1dm sBT85K84M3kZUwPjLN4uRk4OCQETid1X97B0MXJxCAmsZ5To2DyNDcJZwiixdMdZJpAqNgE9 iYlbjrCCJEQENjJKrJz2hBEkISywkFHi4fIYEFtEYBGjxOLlcl2MHEC2kcTiCRwgYRYBVYkX yyewgdi8Ar4SF56fZYRYcIhVYu2b7cwg9ZwCsRLXT9eB1DAKyEpc/dMLNp5ZQFzi1pP5TBCX Ckgs2XOeGcIWlXj5+B8rhK0ksej2ZyaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYwis5CM nYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIycg1t+G+xgfPnc8RCj AAejEg/vguzV4UKsiWXFlbmHGCU4mJVEeNsb1oQL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/ qRguJJCeWJKanZpakFoEk2Xi4JRqYCxnPxbg11sWm/xd70/YxgvZThsVDd/ve1bL9DJip/EL AwMXLbGn95L1DzBWbtlgobn1UsNNHof/gm7HlogLPmJ60LPVU8Trl/Oi82WfGe4c1hd4sftb wie97TPOqqx+cDZ459t3BmbKrY8i7hv5Fu9881hB6OKh/CJpdeNibe2jl2ZfiBF1OazEUpyR aKjFXFScCADE+ZOemAIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 13:51:31 -0000 I identified the problem when reading draft-ietf-ecrit-ecall-11. I have not= followed RFC 7852 closely. If the body referenced in Call-Info in RFC 7852 contains additional informa= tion about callee or caller, then Call-Info usage in RFC 7852 is perfectly = OK. If the body referenced in Call-Info in RFC 7852 contains something unrelate= d to callee or caller, then Call-Info usage in RFC 7852 would suffer the sa= me problem as the two problematic use cases in draft-ietf-ecrit-ecall-11. Kind regards Ivo -----Original Message----- From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com]=20 Sent: Thursday, August 11, 2016 2:40 PM To: Ivo Sedlacek; Randall Gellens; Paul Kyzivat; ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Can you clarify whether this is a comment that RFC 7852 is not compliant wi= th RFC 3261 or that draft-ietf-ecrit-ecall is not compliant with RFC 3261? Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 11 August 2016 08:59 To: Randall Gellens; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hello, > Use of Call-Info to identify emergency data blocks is defined in RFC 7852= . RFC 7852 does not change RFC3261 so any usage of Call-Info must be complian= t to RFC3261 definition of the Call-Info. I.e. Call-Info must provide addit= ional information about the caller or callee.=20 This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INV= ITE response and INFO request. In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. Kind regards Ivo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 11 07:04: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 DEB2912D559 for ; Thu, 11 Aug 2016 07:04:44 -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 Zn_FryfXb01A for ; Thu, 11 Aug 2016 07:04:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A981912D625 for ; Thu, 11 Aug 2016 07:04:38 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-e5-57ac85f49461 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id F2.44.06563.4F58CA75; Thu, 11 Aug 2016 16:04:37 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 16:04:35 +0200 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) Thread-Index: AdHz2FwLK9oifeXtSM6h5CNhXHCw5Q== Date: Thu, 11 Aug 2016 14:04:34 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C4437@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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2K7iu7X1jXhBrcamC0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxukTMxgLOtgqZm3vZGtg/M/SxcjJISFgInHr1wbmLkYuDiGB 9YwSfy7dYYNwljBKPGhsZAepYhPQk5i45QgriC0ioCqx4cxKRpAiYYEORom59/8wQSR6GSV6 LnB3MXIA2XoSc19GgJgsQPWb9jmBVPAK+Ep87z8EVs0oICtx9U8vI4jNLCAucevJfCaIgwQk luw5zwxhi0q8fPyPFcJWklh0+zMTRL2OxILdn9ggbG2JZQtfM0PMF5Q4OfMJywRGoVlIxs5C 0jILScssJC0LGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgSG8sEtv3V3MK5+7XiIUYCD UYmHd0H26nAh1sSy4srcQ4wSHMxKIrztDWvChXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QM FxJITyxJzU5NLUgtgskycXBKNTDqfdw6a6f9rf1vVh+P5PLLtTBo4HqxQJJNzmH9rx/a+ftr ZikXTrcum+n3sq3u+I896XPbJ8q+mjFD1aRq87WwsztMn1WfL7jQ5c0dzNnG+UKAmaVw4yK9 p1xrJpyQ0HxXyLP7VsJRtiP/Dp3xCkkSEjwvw8BVaCG9JH261sbOAxkOjmXHjmkqsRRnJBpq MRcVJwIAtZ3gDWECAAA= Archived-At: Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) 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, 11 Aug 2016 14:04:45 -0000 Hello, I found another potential issue. If a SIP message contains solely one body (i.e. not multipart/mixed body), = then the SIP message cannot contain a Content-ID header field.=20 Content-ID header field is NOT a SIP header field - Content-ID cannot be fo= und in in RFC3261 and Content-ID cannot be found in http://www.iana.org/ass= ignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2=20 Content-ID header field is a MIME multipart/mixed header field. Also, rfc5621 states: ------------ Content-ID URLs allow creating references to body *parts*. ------------ Thus, Figure 10, and Figure 11 (and related procedures) of draft-ietf-ecrit= -ecall-11 use a header field (Content-ID header field) not defined in SIP. Kind regards Ivo From nobody Thu Aug 11 07:24: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 C5CE712D689 for ; Thu, 11 Aug 2016 07:24:58 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 UEfDrh1IcxtX for ; Thu, 11 Aug 2016 07:24:55 -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 2464512D749 for ; Thu, 11 Aug 2016 07:23:40 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with SMTP id XqtXbfdpYlSxsXqtXbhFpW; Thu, 11 Aug 2016 14:23:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XqtWbiXRxTXV7XqtWbDLNc; Thu, 11 Aug 2016 14:23:39 +0000 To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> From: Paul Kyzivat Message-ID: Date: Thu, 11 Aug 2016 10:23:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJEgEy10gs1HHWHQr4VHSmu77PYBrOyxI9t1ZDNN3bcKRZaxF8kdegxiYSEJVjDGLOcYtrUq2z2E2rJ2mmlAfG/mbXegqUBt+RPltJkSQ3HFM9MpRi5d C5yA0WYYbdHybbJRh2EwqAIhz/NWtTSruLfEZ0Szdm0hC6m6kYMPTwVW7K485/pbuEhQ05S1p5Pc+liRBfQxzrLrWIoNEX09v2R6Lx+3IgLki5Hige8P55mj 2eCNK7jLemzCb3YmItNb0yOYiEQld2hIfCvv2lxD3py+UBaGxhDzwHZACBuIJuZj Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 14:24:59 -0000 On 8/10/16 5:38 PM, Randall Gellens wrote: > In reality, there is no separate INFO package negotiation. The > endpoints support the data types not because they support the iNFO > package, but rather they support the INFO package and the data types and > Call-Info because they comply with the draft. You can't do that without violating something. For one thing, when using INFO packages the body part that is the info package must have a content-disposition of "Info-Package". But for the ecall usage the body part must have a content-disposition of "by-reference". Thanks, Paul > At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> I disagree. >> >> The inclusion of the data element in INFO is nothing to do with RFC >> 7852. The data element is included because the use of an appropriate >> Info package has been negotiated and used. That Info package >> definition and the INFO mechanism itself makes no mention of use of >> Call-Info in association with it. >> >> Further I see no justification for complicating any error handling by >> suddenly defining it to be applicable, as it is not necessary. INFO >> requests always contain a data element appropriate to the Info package >> that is defined for its use - it absolutely does not need a secondary >> reference to the package. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 18:20 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >> ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Keith, >> >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>> then I have to agree with Ivo. That additional usage is not currently >>> defined in draft-ietf-ecrit-ecall, and I would need to understand that >>> usage before it is included. >>> >>> At the moment RFC7852 is only used for the transfer of MSD in INVITE >>> requests and 200 (OK) responses, and therefore that is the only place >>> where it should appear in association with RFC7852. >> >> RFC 7852 covers use of Call-Info to point to emergency call data >> blocks in any SIP message that is permitted to carry a body. >> >>> >>> Negotiation and transfer of MSD in association with INFO requests is >>> an entirely separate transfer mechanism, not covered by >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>> there as though it had been. Inclusion will lead to complete confusion >>> as to whether the requirements of the INFO mechanism or the >>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >>> absolutely clear that only the former apply. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >>> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hello, >>> >>>> The invite response still has a body with content-disposition >>>> by-reference. If you remove the reference then its processing is >>>> undefined. >>> >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the >>> Content-Disposition header field of the >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition >>> header field of the application/emergencyCallData.eCall.control+xml >>> body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and thus >>> "render" would apply for the >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>> >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >>> Call-Info points to the >>> application/emergencyCallData.eCall.control+xml body. This body >> > contains a delivery report for the MSD sent in INVITE request. >> This is >>> NOT information about callee as described in RFC3261. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- The idea that >> Bill Gates has appeared like a knight in shining armor to lead all >> customers out of a mire of technological chaos neatly ignores the fact >> that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas Adams > > From nobody Thu Aug 11 07:32: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 AC29612D1E3 for ; Thu, 11 Aug 2016 07:32:02 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 AGuMvsgY3L1K for ; Thu, 11 Aug 2016 07:31:59 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 9ECE312D648 for ; Thu, 11 Aug 2016 07:31:35 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with SMTP id Xr11bOuPNxBKTXr1CbfGCd; Thu, 11 Aug 2016 14:31:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id Xr1BbpLHoXOkgXr1CbKBBI; Thu, 11 Aug 2016 14:31:34 +0000 To: Randall Gellens , Christer Holmberg , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <7594FB04B1934943A5C02806D1A2204B4BBD62DB@ESESSMB208.ericsson.se> From: Paul Kyzivat Message-ID: <41d0757b-d0ba-54d0-c95e-ebcaaca10bc1@alum.mit.edu> Date: Thu, 11 Aug 2016 10:31:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHnB1/bZfXqnUOudjFQKZ5c3B2/GgazaM60+5WVA54GsGaMHONLvWjsgyQswpPzE/+E5JtAq4D9zz4iBRUYZ1xZCG0ANWjSU5gkqFFKw//qnNNrnbPqX NrDdSTuIZQfhPIhXQrhwnW6/7Y7C22v2UR/TF8QmmSfQDv33S7uERJm3OYl5Q53dnme+zFZcLtbINasqgRIltqIwdnmJqDJrEQ2ef/8JsZ7F8kNPH4mNeXBe 8dH1L7sS/O3N0EEguLw9cw0HInjs0ZpFCAjKmqLfnMUzbtJNILeBBQ3N8a2tj0XeL2Ej5a+SCN9o4VOSOcEf4/AJS/D/DZ0jOb5Ar92YK7TSxrZRmrPBU2fk forKFagn Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 14:32:03 -0000 On 8/10/16 5:45 PM, Randall Gellens wrote: > Hi Christer, > > RFC 7852 is not excluded for use in INFO. > > We did agree to not send data in an INFO response, not because it is > harmful to do so, but to avoid argument about legalistic interpretations > of INFO. In our case, INFO is being used exactly as any other SIP > message, not in any special/unique way. It seems that you agreed without understanding the point of the objection. I agree that 7852 isn't excluded from use of INFO. But if it was to be used with INFO then it would be piggybacking on the info usage, not subsumed into it. You would have the INFO, identifying some info package, with the body part defined for use with that info package and content-disposition "Info-Package", and on top of that you would have the call-info with a cid: uri referencing a *different* body part that has content-disposition of (whatever it is, I forget). We discussed that alternative, and people found it to be a hack. So instead we decided to *really* use an info package. Thanks, Paul > I realize that to some, INFO is > the unaccompanied minor of SIP messages: it must be constantly > chaperoned and protected against wanton misuse as a generic transport > mechanism where random data types are sent to unsuspecting endpoints > that don't know how to process them. That's an entirely different > situation than we have. We have endpoints in a limited domain that > exchange a very small number of data types. > > At 6:03 PM +0000 8/10/16, Christer Holmberg wrote: > >> Hi, >> >> Again, as we have discussed before, RFC 7852 does not apply to INFO. >> And, we did agree to not carry the bodies in INFO responses. >> >> And, again, in INFO we won't use the "by-reference" content type, >> which is another example why you can't apply RFC 7852 to INFO. >> >> I DID raise these issues before 7852 was published, but was told it's >> too late to change at that point. So, maybe we need to correct 7852 if >> that is unclear. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens >> Sent: 10 August 2016 20:20 >> To: Drage, Keith (Nokia - GB) ; Ivo Sedlacek >> ; Paul Kyzivat ; >> ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Keith, >> >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>> then I have to agree with Ivo. That additional usage is not currently >>> defined in draft-ietf-ecrit-ecall, and I would need to understand that >>> usage before it is included. >>> >>> At the moment RFC7852 is only used for the transfer of MSD in INVITE >>> requests and 200 (OK) responses, and therefore that is the only place >>> where it should appear in association with RFC7852. >> >> RFC 7852 covers use of Call-Info to point to emergency call data >> blocks in any SIP message that is permitted to carry a body. >> >>> >>> Negotiation and transfer of MSD in association with INFO requests is >>> an entirely separate transfer mechanism, not covered by >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>> there as though it had been. Inclusion will lead to complete confusion >>> as to whether the requirements of the INFO mechanism or the >>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >>> absolutely clear that only the former apply. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >>> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hello, >>> >>>> The invite response still has a body with content-disposition >>>> by-reference. If you remove the reference then its processing is >>>> undefined. >>> >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the >>> Content-Disposition header field of the >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition >>> header field of the application/emergencyCallData.eCall.control+xml >> > body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and thus >>> "render" would apply for the >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>> >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >>> Call-Info points to the >>> application/emergencyCallData.eCall.control+xml body. This body >>> contains a delivery report for the MSD sent in INVITE request. This is >>> NOT information about callee as described in RFC3261. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- The idea that >> Bill Gates has appeared like a knight in shining armor to lead all >> customers out of a mire of technological chaos neatly ignores the fact >> that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas Adams >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From nobody Thu Aug 11 07:36:56 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 2886A12D17B for ; Thu, 11 Aug 2016 07:36:55 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 S3vh-iF-tfJE for ; Thu, 11 Aug 2016 07:36:51 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 C067B12D6A8 for ; Thu, 11 Aug 2016 07:36:09 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with SMTP id Xr4kbGGqp84vjXr5db6QPT; Thu, 11 Aug 2016 14:36:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id Xr5cbQQHNn5jaXr5cb9HMR; Thu, 11 Aug 2016 14:36:09 +0000 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , Randall Gellens , "R.Jesske@telekom.de" , Ivo Sedlacek , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF4596C@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Thu, 11 Aug 2016 10:36:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF4596C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFn7RgeV8fnifV9jgVDovOg0FcPzFDy1t2kERNHnSdXOy3qAIxYpnh2vfSWmOXpeKzMWje2/3x2mEXjLimSlYOCJGC1F1Sz+UEajWCIywof+50553Z5E 3Duvsn7rhRTDYtOZ8WJIr6yAsWvU3HEFTZoNoywPF0zUopHJkvc0+OmFjnkKHi4AyGxt240k1xHlRf7wBGZ9mFa26fjrpAQdKeETlFJRQAEyuZfSwWn+GCoD WqOFogt+LBLy8FQ8HrTURUPxnUxZASRpj4/hViQNaARgzv6R6OoFliF1a2NeerUL8hhnJSYYgVXGjJNwI6foNtCb6nlXizYIG32eWeEh+bwomxkkpJAOyr3D aOqOC59+L+yGM/areNKXoAd75ioavw== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 14:36:55 -0000 +1 On 8/11/16 9:08 AM, Drage, Keith (Nokia - GB) wrote: > I think I need to state how I see ecrit operating. > > I see some sort of supporting ecrit "application" in the PSAP and the calling UA. That supporting application initiates two independent data transport mechanisms within SIP, using RFC 7852 for the initial MSD and the data response to indicate support of MSD reception, and using RFC 6086 for any subsequent MSD. SIP itself knows nothing about the relationship between these two mechanisms, only the ecrit "application". It is the ecrit "application" that performs the combination of the data received using the two data transfer mechanisms as appropriate. > > The MSDs transferred using the two mechanisms following identical syntax and coding, but that is merely a matter of convenient definition. > > As such, use of Call-Info in INFO would be entirely inappropriate, because INFO does not transfer additional-data according to RFC 7852. > > Note that RFC 7842 is only used by ecrit in the initial INVITE transaction, and appearance in subsequent messages of any form would not be expected by the recipient PSAP. > > I believe the above is the correct usage of these mechanisms, as opposed to that put forward by the current draft author. > > Regards > > Keith > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 11 August 2016 09:01 > To: Randall Gellens; Drage, Keith (Nokia - GB); R.Jesske@telekom.de; Ivo Sedlacek; pkyzivat@alum.mit.edu; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > Hi, > >>>> I see it as one data transfer mechanism, which has additional >>>> restrictions/impositions when used with INFO. INFO has various >>>> prohibitions and restrictions and mandates in an attempt to reign in >>>> the former freewheeling use of INFO as a generic data transfer >>>> mechanism. In our case, we're using INFO only for mid-call updates, >>> >>> We don't have the authority to say "Well, we only use INFO for this >>> special case, so therefore we don't need to follow RFC 6086". >> >> We are following RFC 6086. > > > Yes, but it seems you only want to do it for łcosmetic purpose˛, because you still want to use 7852 for INFO. > > Again, as per RFC 6086, the semantics of the MIMEs shall be described by by the info package specification. Whether the info package is used for some łspecial purpose˛ and/or łbetween a small set of devices" is irrelevant. > > Regards, > > Christer > > > >> >>> >>> And, most usages of INFO are for a specific purpose. That's the >>> whole idea >>> of the info package mechanism - to to have a clear scope and >>> semantics of >>> the usage. >>> >>>> >>>> and only because it seemed at the time to be cleaner than using >>>> re-INVITE or UPDATE or OPTIONS or something else. If we diverge into >>>> two entirely separate mechanisms, one just for INFO, then we will do >>>> a disservice to emergency call processing. >>> >>> The difference is on the SIP level. As the same MIME types etc are >>> used, >>> the applications will see no difference. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> >>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> >>>>> I fundamentally disagree. We have two different data transfer >>>>> mechanisms, and the presence of the data should be clearly >>>>> understood from the appropriate transfer mechanism protocol. >>>>> >>>>> So Call-Info applies when RFC 7852 applies, which is the INVITE >>>>> and >>>>> 200 (OK) response, and does not when the INFO mechanism is in use. >>>>> >>>>> Additionally it only applies when it is pointing to data which is >>>>> actually attached to the message. >>>>> >>>>> Keith >>>>> >>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>>> R.Jesske@telekom.de >>>>> Sent: 08 August 2016 10:45 >>>>> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>> not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hi Ivo, >>>>> using the ecall urn (urn:service:sos.ecall.automatic) does not >>>>> implicitly means using the MSD within the Body. It could be also an >>>>> interworked call where all ecall information is included inband >>>>> using the In-band modem solution. >>>>> >>>>> We have to think also on backwards compatibility issues. Thus >>>>> when moving PSAP's to SIP imply also that there must exist an >>>>> interworking between the old mobile world towards the new mobile >>>>> world using SIP. >>>>> >>>>> Using the Call-Info header would help the PAST to distinguish the >>>>> in-band and outband solution. Perhaps it would be worth to define >>>>> an additional value for inband data, to identify ecalls coming from >>>>> other networks not supporting the MSD Body. >>>>> >>>>> Best Regards >>>>> >>>>> Roland. >>>>> >>>>> >>>>> Von: Ecrit >>>>> [mailto:ecrit-bounces@ietf.org] Im >>>>> Auftrag von Ivo Sedlacek >>>>> Gesendet: Montag, 8. August 2016 09:59 >>>>> An: Paul Kyzivat; ecrit@ietf.org >>>>> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hello, >>>>> >>>>> According to RFC3261, the Call-Info header field provides >>>>> additional information about the caller or callee. >>>>> >>>>> According to draft-ietf-ecrit-ecall-11, the Call-Info header >>>>> field is used to form a "content-table" of pointers to bodies >>>>> INVITE request (and of INVITE response, of INFO request) in >>>>> headers of INVITE request (and of INVITE response, of INFO request). >>> >> >>>>> If the Call-Info header field points to a body which describes >>>>> the callers or callee, then Call-Info semantic fits (even though I >>>>> would still question usefulness of such Call-Info inclusion). >>>>> >>>>> If the Call-Info header field points to a body which request an >>>>> action in remote UE and which reports to remote UE an outcome of an >>>>> action done by the local UE, then Call-Info semantic does not fit. >>>>> >>>>> Particularly: >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> --- >>>>> -- >>>>> ----- >>>>> A PSAP or IVS transmits a metadata/control object (see Section >>>>> 9) by >>>>> encoding it per the description in this document and attaching >>>>> it to >>>>> a SIP message as a MIME body part per [RFC7852]. The body >>>>> part is >>>>> identified by its MIME content-type ('application/ >>>>> emergencyCallData.eCall.control+xml') in the Content-Type header >>>>> field of the body part. The body part is assigned a unique >>>>> identifier which is listed in a Content-ID header field in the >>>>> body >>>>> part. The SIP message is marked as containing the >>>>> metadata/control >>>>> object by adding (or appending to) a Call-Info header field at >>>>> the >>>>> top level of the SIP message. This Call-Info header field >>>>> contains a >>>>> CID URL referencing the body part's unique identifier, and a >>>>> 'purpose' parameter identifying the data as an eCall >>>>> metadata/control >>>>> block per the Emergency Call Additional Data Blocks registry >>>>> entry; >>>>> the 'purpose' parameter's value is >>>>> 'emergencyCallData.eCall.control'. >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> --- >>>>> -- >>>>> ----- >>>>> and >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> --- >>>>> -- >>>>> ----- >>>>> SIP/2.0 200 OK >>>>> To: >>>>> >>>>> <sip:+13145551111@example.com>;tag=9fx >>>>> ced >>>>> 76 >>>>> sl >>>>> From: Exemplar PSAP >>>>> Call-ID: >>>>> 3848276298220188511@atlanta.example.com >>>>> Call-Info: >>>>> >>>>> cid:2345678901@atlanta.example.com; >>>>> purpose=emergencyCallData.eCall.control; >>>>> Accept: application/sdp, application/pidf+xml, >>>>> application/emergencyCallData.eCall.control+xml, >>>>> application/emergencyCallData.eCall.MSD+per >>>>> CSeq: 31862 INVITE >>>>> Recv-Info: emergencyCallData.eCall.MSD >>>>> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >>>>> SUBSCRIBE, NOTIFY, UPDATE >>>>> Content-Type: multipart/mixed; boundary=boundaryX >>>>> Content-Length: ... >>>>> >>>>> --boundaryX >>>>> Content-Type: application/sdp >>>>> >>>>> ...Session Description Protocol (SDP) goes here... >>>>> >>>>> --boundaryX >>>>> Content-Type: application/EmergencyCallData.eCall.control+xml >>>>> Content-ID: >>>>> 2345678901@atlanta.example.com >>>>> Content-Disposition: by-reference;handling=optional >>>>> >>>>> >>>>> >>>> >>>>> xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>>>> >>>>> >>>>> xmlns:xsi="http://www.w3. >>>>> org >>>>> /2 >>>>> 001/XMLSchema-instance" >>>>> xsi:schemaLocation= >>>>> >>>>> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >>>>> >>>>> >>>> >>>>> ref="1234567890@atlanta.example. >>>>> co >>>>> m"/> >>>>> >>>>> >>>>> >>>>> --boundaryX-- >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> --- >>>>> -- >>>>> ----- >>>>> >>>>> Kind regards >>>>> >>>>> Ivo >>>>> >>>>> -----Original Message----- >>>>> From: Ecrit >>>>> [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Friday, August 05, 2016 4:43 PM >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>> brings no value >>>>> >>>>> Ivo, >>> >> >>>>> IIUC, you are saying that the Call-Info that refers to the body >>>>> is >>> >> unnecessary because the recipient will know what to do with the >>>>> body even in the absence of the Call-Info. Is that right? >>>>> >>>>> This assumption mixes up two things: >>>>> - understanding a body syntactically >>>>> - understanding *why* the body is present and how it should be used. >>>>> >>>>> Historically, processing of body parts in sip was very poorly >>>>> defined. >>>>> Initially the only body of interest was SDP, so how one might >>>>> process other bodies or body parts was not well considered. >>>>> Eventually this started to be a liability, so RFC5621 was >>>>> published >>>>> to clarify it. >>>>> >>>>> Processing of body parts is governed by a complex interaction >>>>> between Content-Type, Content-Disposition, Content-ID. >>>>> >>>>> So the call-info header indicates the reason that body is being >>>>> included. I realize that there is one predominant reason for doing >>>>> so, but that is not the only possible reason. (E.g., it might be >>>>> included as context in an intended discussion about problems >>>>> handling a call in the >>>>> past.) >>>>> >>>>> If all the handling of the call is coded in a special purpose >>>>> way, solely for the emergency call path, then alternatives may be >>>>> of no concern. But ideally the call will largely be handled via >>>>> standard library code that is also used for other call paths and >>>>> other message processing. So processing body parts in a "standard" >>>>> way, rather than special casing, is desirable. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >>>>> > Hello, >>>>> > >>>>> > >>>>> > >>>>> > COMMENT: >>>>> > >>>>> > >>>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>>> > \\\\\\\\ >>>>> > >>>>> > Inclusion of Call-Info header field with >>>>> > purpose=emergencyCallData.eCall.MSD or >>>>> > purpose=emergencyCallData.eCall.control in requests and >>>>> responses does >>>>> > not seem to bring any value. It seems to only waste radio >>>>> resources. >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.MSD >>>>> included in the >>>>> > initial INVITE request: >>>>> > >>>>> > - if this is meant to be used by a proxy for routing of the eCall >>>>> > emergency call to a PSAP supporting eCall emergency call, then >>>>> this >>>>> > seems to be redundant to the eCall URN included in the >>>>> Request-URI and >>>>> > the Recv-Info header field containing eCall specific info package >>>>> > (emergencyCallData.eCall.MSD). >>>>> > >>>>> > - if this is meant to be used by UAS (i.e. PSAP), then >>>>> according to >>>>> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check >>>>> that all >>>>> > the bodies of the INVITE request not marked with >>>>> Content-Disposition: >>>>> > ...; handling=optional are understood. So, >>>>> > application/emergencyCallData.eCall.MSD+per MIME body will >>>>> anyway be >>>>> > found by UAS during the INVITE request processing. >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.control >>>>> included >>>>> in >>>>> > a response to the initial INVITE request >>>>> > >>>>> > - no routing decisions are done by proxies when receiving a >>>>> response >>>>> > to the initial INVITE request so this does not seem to have >>>>> any value >>>>> > for the proxies >>>>> > >>>>> > - UAC includes Accept with supported MIME types in INVITE >>>>> request so >>>>> > why would UAS send any MIME body not wished by the UAC? >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.control >>>>> included >>>>> in >>>>> > the INFO request >>>>> > >>>>> > - no routing decisions are done by proxies when receiving an >>>>> in-dialog >>>>> > request so this does not seem to have any value for the proxies >>>>> > >>>>> > - support of info package emergencyCallData.eCall.MSD in the call >>>>> > implies that either >>>>> application/EmergencyCallData.eCall.control+xml >>>>> > MIME body or application/emergencyCallData.eCall.MSD+per MIME >>>>> body is >>>>> > included. Again, according to RFC3261 subclause 8.2.3, the UAS >>>>> anyway >>>>> > needs to check that all the bodies of the INFO request not >>>>> marked with >>>>> > Content-Disposition: ...; handling=optional are understood. >>>>> So, >>> >> > application/EmergencyCallData.eCall.control+xml MIME body or >>> >> > application/emergencyCallData.eCall.MSD+per MIME body will >>> anyway be >>>>> > found by UAS during the INFO request processing. >>>>> > >>>>> > >>>>> ////////////////////////////////////////////////////////////////////// >>>>> > //////// >>>>> > >>>>> > PROPOSED SOLUTION to COMMENT >>>>> > >>>>> > >>>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>>> > \\\\\\\\ >>>>> > >>>>> > Remove insertion of Call-Info header field. >>>>> > >>>>> > >>>>> ////////////////////////////////////////////////////////////////////// >>>>> > //////// >>>>> > >>>>> > >>>>> > >>>>> > Kind regards >>>>> > >>>>> > >>>>> > >>>>> > Ivo Sedlacek >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Ecrit mailing list >>>>> > Ecrit@ietf.org >>>>> > >>>>> >>>>> https://www.ietf.org/ma >>>>> ilm >>>>> an >>>>> /listinfo/ecrit >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> >>>>> >>>>> https://www.ietf.org/ma >>>>> ilm >>>>> an >>>>> /listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- I asked >>>> President Reagan what he thought about the IBM PC Jr., and he replied >>>> that he didn't believe in abortions >>>> --Steve Wozniac >>>> >>>> _______________________________________________ >>>> 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: --------------- >> Probable-Possible, my black hen, She lays eggs in the Relative When. >> She doesn't lay eggs in the Positive Now Because she's unable to >> postulate how. >> --Frederick Winsor, "The Space Child's Mother Goose" >> [Simon & Schuster 1966], paperback > > From nobody Thu Aug 11 07:44: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 D1FAD12D1E3 for ; Thu, 11 Aug 2016 07:44:23 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 tlkkfXlz5OYy for ; Thu, 11 Aug 2016 07:44:19 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 145FE12D513 for ; Thu, 11 Aug 2016 07:44:17 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with SMTP id XrDUb6SvnTaLwXrDVbMSf1; Thu, 11 Aug 2016 14:44:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XrDUbTrxljzO0XrDUbgcHZ; Thu, 11 Aug 2016 14:44:17 +0000 To: Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 11 Aug 2016 10:44:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfI6CBMNOrvtl1fdvZGpy1zWiUCwSCzI+/rbYKON/18qLSAt6BO3vxD1k4F0Z8SfiigHCpyIXPq45mzgNswbZaqbot0JPVdbK/nolmL5wo7mB+7RAjkCa NpKrX/6wR7YAI2zxwDUGZC2vvdfvzybOZiXMKae351H4L9l2g6BGJQ7skRPm9e1jAsHxhBy7C7WVUl1urQHSeG+FWyHx+BohO49nA5vurBpkzWdYqiZBQPX1 V8ngz3s1jGwl+BtS2QnlA1PQnN56yRXWFl1/v8Ohznw= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 14:44:24 -0000 On 8/11/16 3:59 AM, Ivo Sedlacek wrote: > Hello, > >> Use of Call-Info to identify emergency data blocks is defined in RFC 7852. > > RFC 7852 does not change RFC3261 so any usage of Call-Info must be compliant to RFC3261 definition of the Call-Info. I.e. Call-Info must provide additional information about the caller or callee. > > This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INVITE response and INFO request. > > In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. Part of your concern will be resolved by ceasing the use of call-info with the INFO messages. Regarding use in INVITE response: I think you are technically correct, though some will consider it nit-picking. To avoid that, simply stop sending ecall data in the INVITE response. Instead, simply wait and send it in an INFO. Thanks, Paul From nobody Thu Aug 11 07:51: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 DD04412D59E for ; Thu, 11 Aug 2016 07:51:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 hzGa9UWsYngl for ; Thu, 11 Aug 2016 07:50:56 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 8D81C12D581 for ; Thu, 11 Aug 2016 07:50:31 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-03v.sys.comcast.net with SMTP id XrJJbQRxl8GkCXrJWb6o9R; Thu, 11 Aug 2016 14:50:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id XrJWbTtcXjzO0XrJWbgdFb; Thu, 11 Aug 2016 14:50:30 +0000 To: ecrit@ietf.org References: <39B5E4D390E9BD4890E2B31079006101164C4437@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> Date: Thu, 11 Aug 2016 10:50:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C4437@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNAYBc5V2po1M+wwh3eVZQPweSbyXE5BZQfdWlMgE+TcKz5AD3yNTS1phxkwGZamvywWPjYe6hhysPMYNWzvj9p4Q//eW6/+CYS31SQFQRQHTCuvX9dk Pc3kJ/RXhavM7U9rIFsxE+2Kjtxo8T12fhmOtouYKPLkEULbiIh2i5ryqji7ctDgWwuO3v/3MR3cvQ== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) 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, 11 Aug 2016 14:51:01 -0000 Hmm. Interesting issue. ISTM the proper solution to that is to define Content-ID as a SIP header field. Of course a work-around is to add a multipart wrapper to the single body part. But that shouldn't be necessary. Thanks, Paul On 8/11/16 10:04 AM, Ivo Sedlacek wrote: > Hello, > > I found another potential issue. > > If a SIP message contains solely one body (i.e. not multipart/mixed body), then the SIP message cannot contain a Content-ID header field. > > Content-ID header field is NOT a SIP header field - Content-ID cannot be found in in RFC3261 and Content-ID cannot be found in http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > Content-ID header field is a MIME multipart/mixed header field. > > Also, rfc5621 states: > ------------ > Content-ID URLs allow creating references to body *parts*. > ------------ > > Thus, Figure 10, and Figure 11 (and related procedures) of draft-ietf-ecrit-ecall-11 use a header field (Content-ID header field) not defined in SIP. > > Kind regards > > Ivo > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Thu Aug 11 07:58: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 EBAAC12D5AD for ; Thu, 11 Aug 2016 07:58:04 -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 w_1snBzFY06z for ; Thu, 11 Aug 2016 07:58:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 19A5812D0B2 for ; Thu, 11 Aug 2016 07:58:00 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-e5-57ac9276624f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 9C.75.02553.6729CA75; Thu, 11 Aug 2016 16:57:59 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.187]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Thu, 11 Aug 2016 16:57:58 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) Thread-Index: AdHz2FwLK9oifeXtSM6h5CNhXHCw5f//7SkA///df9A= Date: Thu, 11 Aug 2016 14:57:58 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164C44A7@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164C4437@ESESSMB301.ericsson.se> <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> In-Reply-To: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7n275pDXhBgd65CwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxbcpqxoLDTBX3r31iaWD8z9jFyMkhIWAi cefjQiCbi0NIYD2jROvUaSwQzhJGiRVvFrCDVLEJ6ElM3HKEFcQWEfCW+PP7GxuILSzQwygx 934hRLyXUaLnAjeEbSXR2HIerIZFQFVi5e35YHN4BXwlrrbeglrQzChx59RTJpAEp4CDxInn T8EWMArISlz90wt2HrOAuMStJ/OZIE4VkFiy5zwzhC0q8fLxP1YIW0li0e3PTBD1OhILdn9i g7C1JZYtfM0MsVhQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxc nJ+nl5dasokRGBMHt/w22MH48rnjIUYBDkYlHt4F2avDhVgTy4orcw8xSnAwK4nwbuhbEy7E m5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBceLPZ1eZUhUm P2v6taJqut0Ck0+Xtlz+O+OUvwnzhy+qd0/ltX17+FbSKy3s8gShLS0lf9VlODjvRJddr/jB vHNte8XV1t2JczY8mcoj8Ghixs3YRZkaKUv+eKoZhT3nYhVM5Y4wPvg07RvXir6JzqcEqsPv H/90Jkknb+Pnex1HtjO5tja+bFRiKc5INNRiLipOBACVy9C9hQIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) 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, 11 Aug 2016 14:58:05 -0000 > ISTM the proper solution to that is to define Content-ID as a SIP header = field. I agree. Actually, we might have this problem already with REFER inviting several pa= rticipants - see Figure 3 of https://tools.ietf.org/html/rfc5368 So, this is something more generic than eCall draft. Kind regards Ivo From nobody Thu Aug 11 10:47: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 81F2E12D8CF for ; Thu, 11 Aug 2016 10:47:40 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 rUyCtarqOM46 for ; Thu, 11 Aug 2016 10:47:38 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 711A812D885 for ; Thu, 11 Aug 2016 10:47:38 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Aug 2016 10:47:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Aug 2016 10:47:31 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , "R.Jesske@telekom.de" , "Ivo Sedlacek" , "pkyzivat@alum.mit.edu" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 17:47:40 -0000 At 8:00 AM +0000 8/11/16, Christer Holmberg wrote: > Hi, > >>>>I see it as one data transfer mechanism, which has additional >>>>restrictions/impositions when used with INFO. INFO has various >>>>prohibitions and restrictions and mandates in an attempt to reign in >>>>the former freewheeling use of INFO as a generic data transfer >>>>mechanism. In our case, we're using INFO only for mid-call updates, >>> >>> We don't have the authority to say "Well, we only use INFO for this >>> special case, so therefore we don't need to follow RFC 6086". >> >>We are following RFC 6086. > > > Yes, but it seems you only want to do it for "cosmetic purpose", because > you still want to use 7852 for INFO. I'd say we're complying for legalistic purposes, but yes. > > Again, as per RFC 6086, the semantics of the MIMEs shall be described by > by the info package specification. And they are. They are also described per RFC 7852. We're using both. RFC 7852 for consistency with non-INFO. > Whether the info package is used for > some "special purpose" and/or "between a small set of devices" is > irrelevant. Fair enough. > > Regards, > > Christer > > > >> >>> >>> And, most usages of INFO are for a specific purpose. That's the whole >>>idea >>> of the info package mechanism - to to have a clear scope and semantics >>>of >>> the usage. >>> >>>> >>>>and only because it seemed at the time to be cleaner than using >>>>re-INVITE or UPDATE or OPTIONS or something else. If we diverge into >>>>two entirely separate mechanisms, one just for INFO, then we will do >>>>a disservice to emergency call processing. >>> >>> The difference is on the SIP level. As the same MIME types etc are >>>used, >>> the applications will see no difference. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> >>>>At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> >>>>> I fundamentally disagree. We have two different data transfer >>>>> mechanisms, and the presence of the data should be clearly >>>>> understood from the appropriate transfer mechanism protocol. >>>>> >>>>> So Call-Info applies when RFC 7852 applies, which is the INVITE and >>>>> 200 (OK) response, and does not when the INFO mechanism is in use. >>>>> >>>>> Additionally it only applies when it is pointing to data which is >>>>> actually attached to the message. >>>>> >>>>> Keith >>>>> >>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>>>R.Jesske@telekom.de >>>>> Sent: 08 August 2016 10:45 >>>>> To: ivo.sedlacek@ericsson.com; pkyzivat@alum.mit.edu; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hi Ivo, >>>>> using the ecall urn (urn:service:sos.ecall.automatic) does not >>>>> implicitly means using the MSD within the Body. It could be also an >>>>> interworked call where all ecall information is included inband >>>>> using the In-band modem solution. >>>>> >>>>> We have to think also on backwards compatibility issues. Thus when >>>>> moving PSAP's to SIP imply also that there must exist an >>>>> interworking between the old mobile world towards the new mobile >>>>> world using SIP. >>>>> >>>>> Using the Call-Info header would help the PAST to distinguish the >>>>> in-band and outband solution. Perhaps it would be worth to define >>>>> an additional value for inband data, to identify ecalls coming from >>>>> other networks not supporting the MSD Body. >>>>> >>>>> Best Regards >>>>> >>>>> Roland. >>>>> >>>>> >>>>> Von: Ecrit > >>>> [mailto:ecrit-bounces@ietf.org] Im >>>>> Auftrag von Ivo Sedlacek >>>>> Gesendet: Montag, 8. August 2016 09:59 >>>>> An: Paul Kyzivat; ecrit@ietf.org > >>>> Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hello, >>>>> >>>>> According to RFC3261, the Call-Info header field provides >>>>> additional information about the caller or callee. >>>>> >>>>> According to draft-ietf-ecrit-ecall-11, the Call-Info header field >>>>> is used to form a "content-table" of pointers to bodies INVITE >>>>> request (and of INVITE response, of INFO request) in headers of >>>>> INVITE request (and of INVITE response, of INFO request). >>> >> >>>>> If the Call-Info header field points to a body which describes the >>>>> callers or callee, then Call-Info semantic fits (even though I >>>>> would still question usefulness of such Call-Info inclusion). >>>>> >>>>> If the Call-Info header field points to a body which request an >>>>> action in remote UE and which reports to remote UE an outcome of an >>>>> action done by the local UE, then Call-Info semantic does not fit. >>>>> >>>>> Particularly: >>>>> >>>>> >>>>>----------------------------------------------------------------------- >>>>>-- >>>>>----- >>>>> A PSAP or IVS transmits a metadata/control object (see Section >>>>>9) by >>>>> encoding it per the description in this document and attaching >>>>>it to >>>>> a SIP message as a MIME body part per [RFC7852]. The body part >>>>>is >>>>> identified by its MIME content-type ('application/ >>>>> emergencyCallData.eCall.control+xml') in the Content-Type header >>>>> field of the body part. The body part is assigned a unique >>>>> identifier which is listed in a Content-ID header field in the >>>>>body >>>>> part. The SIP message is marked as containing the >>>>>metadata/control >>>>> object by adding (or appending to) a Call-Info header field at >>>>>the >>>>> top level of the SIP message. This Call-Info header field >>>>>contains >>>>>a >>>>> CID URL referencing the body part's unique identifier, and a >>>>> 'purpose' parameter identifying the data as an eCall >>>>>metadata/control >>>>> block per the Emergency Call Additional Data Blocks registry >>>>>entry; >>>>> the 'purpose' parameter's value is >>>>>'emergencyCallData.eCall.control'. >>>>> >>>>> >>>>>----------------------------------------------------------------------- >>>>>-- >>>>>----- >>>>> and >>>>> >>>>> >>>>>----------------------------------------------------------------------- >>>>>-- >>>>>----- >>>>> SIP/2.0 200 OK >>>>> To: >>>>> >>>>><sip:+13145551111@example.com>;tag=9fxced >>>>>76 >>>>>sl >>>>> From: Exemplar PSAP >>>>> Call-ID: >>>>> 3848276298220188511@atlanta.example.com >>>>> Call-Info: >>>>> >>>>>cid:2345678901@atlanta.example.com; >>>>> purpose=emergencyCallData.eCall.control; >>>>> Accept: application/sdp, application/pidf+xml, >>>>> application/emergencyCallData.eCall.control+xml, >>>>> application/emergencyCallData.eCall.MSD+per >>>>> CSeq: 31862 INVITE >>>>> Recv-Info: emergencyCallData.eCall.MSD >>>>> Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, >>>>> SUBSCRIBE, NOTIFY, UPDATE >>>>> Content-Type: multipart/mixed; boundary=boundaryX >>>>> Content-Length: ... >>>>> >>>>> --boundaryX >>>>> Content-Type: application/sdp >>>>> >>>>> ...Session Description Protocol (SDP) goes here... >>>>> >>>>> --boundaryX >>>>> Content-Type: application/EmergencyCallData.eCall.control+xml >>>>> Content-ID: >>>>> 2345678901@atlanta.example.com >>>>> Content-Disposition: by-reference;handling=optional > >>>> >>>>> >>>>> >>>> >>>>>xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" >>>>> >>>>> >>>>>xmlns:xsi="http://www.w3.org > >>>>/2 >>>>>001/XMLSchema-instance" >>>>> xsi:schemaLocation= >>>>> >>>>>"urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> >>>>> >>>>> >>>> >>>>>ref="1234567890@atlanta.example. >>>>>co >>>>>m"/> >>>>> >>>>> >>>>> >>>>> --boundaryX-- >>>>> >>>>> >>>>>----------------------------------------------------------------------- >>>>>-- >>>>>----- >>>>> >>>>> Kind regards >>>>> >>>>> Ivo >>>>> >>>>> -----Original Message----- >>>>> From: Ecrit >>>>> [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Friday, August 05, 2016 4:43 PM >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>> brings no value >>>>> >>>>> Ivo, >>> >> >>>>> IIUC, you are saying that the Call-Info that refers to the body is >>> >> unnecessary because the recipient will know what to do with the >>>>> body even in the absence of the Call-Info. Is that right? >>>>> >>>>> This assumption mixes up two things: >>>>> - understanding a body syntactically >>>>> - understanding *why* the body is present and how it should be used. >>>>> >>>>> Historically, processing of body parts in sip was very poorly >>>>>defined. >>>>> Initially the only body of interest was SDP, so how one might >>>>> process other bodies or body parts was not well considered. >>>>> Eventually this started to be a liability, so RFC5621 was published >>>>> to clarify it. >>>>> >>>>> Processing of body parts is governed by a complex interaction >>>>> between Content-Type, Content-Disposition, Content-ID. >>>>> >>>>> So the call-info header indicates the reason that body is being >>>>> included. I realize that there is one predominant reason for doing >>>>> so, but that is not the only possible reason. (E.g., it might be >>>>> included as context in an intended discussion about problems >>>>> handling a call in the >>>>> past.) >>>>> >>>>> If all the handling of the call is coded in a special purpose way, >>>>> solely for the emergency call path, then alternatives may be of no >>>>> concern. But ideally the call will largely be handled via standard >>>>> library code that is also used for other call paths and other >>>>> message processing. So processing body parts in a "standard" way, >>>>> rather than special casing, is desirable. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 8/5/16 7:15 AM, Ivo Sedlacek wrote: >>>>> > Hello, >>>>> > >>>>> > >>>>> > >>>>> > COMMENT: >>>>> > >>>>> > >>>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>>> > \\\\\\\\ >>>>> > >>>>> > Inclusion of Call-Info header field with >>>>> > purpose=emergencyCallData.eCall.MSD or >>>>> > purpose=emergencyCallData.eCall.control in requests and responses >>>>>does >>>>> > not seem to bring any value. It seems to only waste radio >>>>>resources. >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.MSD included >>>>>in >>>>>the >>>>> > initial INVITE request: >>>>> > >>>>> > - if this is meant to be used by a proxy for routing of the eCall >>>>> > emergency call to a PSAP supporting eCall emergency call, then >>>>>this >>>>> > seems to be redundant to the eCall URN included in the >>>>>Request-URI >>>>>and >>>>> > the Recv-Info header field containing eCall specific info package >>>>> > (emergencyCallData.eCall.MSD). >>>>> > >>>>> > - if this is meant to be used by UAS (i.e. PSAP), then according >>>>>to >>>>> > RFC3261 subclause 8.2.3, then the UAS anyway needs to check that >>>>>all >>>>> > the bodies of the INVITE request not marked with >>>>>Content-Disposition: >>>>> > ...; handling=optional are understood. So, > >>>> > application/emergencyCallData.eCall.MSD+per MIME body will >>>>>anyway be >>>>> > found by UAS during the INVITE request processing. >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.control > >>>>included >>>>>in >>>>> > a response to the initial INVITE request >>>>> > >>>>> > - no routing decisions are done by proxies when receiving a >>>>>response >>>>> > to the initial INVITE request so this does not seem to have any >>>>>value >>>>> > for the proxies >>>>> > >>>>> > - UAC includes Accept with supported MIME types in INVITE >>>>>request so >>>>> > why would UAS send any MIME body not wished by the UAC? >>>>> > >>>>> > >>>>> > >>>>> > For Call-Info with purpose=emergencyCallData.eCall.control >>>>>included >>>>>in >>>>> > the INFO request >>>>> > >>>>> > - no routing decisions are done by proxies when receiving an >>>>>in-dialog >>>>> > request so this does not seem to have any value for the proxies >>>>> > >>>>> > - support of info package emergencyCallData.eCall.MSD in the call >>>>> > implies that either >>>>>application/EmergencyCallData.eCall.control+xml >>>>> > MIME body or application/emergencyCallData.eCall.MSD+per MIME >>>>>body >>>>>is >>>>> > included. Again, according to RFC3261 subclause 8.2.3, the UAS >>>>>anyway >>>>> > needs to check that all the bodies of the INFO request not marked >>>>>with >>>>> > Content-Disposition: ...; handling=optional are understood. So, >>> >> > application/EmergencyCallData.eCall.control+xml MIME body or >>> >> > application/emergencyCallData.eCall.MSD+per MIME body will >>>anyway be >>>>> > found by UAS during the INFO request processing. >>>>> > >>>>> > >>>>>////////////////////////////////////////////////////////////////////// >>>>> > //////// >>>>> > >>>>> > PROPOSED SOLUTION to COMMENT >>>>> > >>>>> > >>>>>\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>>>> > \\\\\\\\ >>>>> > >>>>> > Remove insertion of Call-Info header field. >>>>> > >>>>> > >>>>>////////////////////////////////////////////////////////////////////// >>>>> > //////// >>>>> > >>>>> > >>>>> > >>>>> > Kind regards >>>>> > >>>>> > >>>>> > >>>>> > Ivo Sedlacek >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Ecrit mailing list >>>>> > Ecrit@ietf.org >>>>> > >>>>> >>>>>https://www.ietf.org/mailm >>>>>an >>>>>/listinfo/ecrit >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> >>>>> >>>>>https://www.ietf.org/mailm >>>>>an >>>>>/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>>-- >>>>Randall Gellens >>>>Opinions are personal; facts are suspect; I speak for myself only >>>>-------------- Randomly selected tag: --------------- >>>>I asked President Reagan what he thought about the IBM PC Jr., >>>>and he replied that he didn't believe in abortions >>>> --Steve Wozniac >>>> >>>>_______________________________________________ >>>>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: --------------- >>Probable-Possible, my black hen, >>She lays eggs in the Relative When. >>She doesn't lay eggs in the Positive Now >>Because she's unable to postulate how. >> --Frederick Winsor, "The Space Child's Mother Goose" >> [Simon & Schuster 1966], paperback -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A logician saves the life of a space alien and is rewarded with an offer to answer any question. After a thought he asks: What is the best question to ask and the correct answer to it? After a brief panic the alien consults her computer and says: The best question to ask is the one you just did and the correct answer to it is the one I gave. From nobody Thu Aug 11 10: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 499F612D8E1 for ; Thu, 11 Aug 2016 10:50:43 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 XJDth8-QMX4x for ; Thu, 11 Aug 2016 10:50:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BA61E12D8E0 for ; Thu, 11 Aug 2016 10:50:41 -0700 (PDT) Received: from [192.168.0.20] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 11 Aug 2016 10:50:41 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF45947@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45947@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Thu, 11 Aug 2016 10:50:38 -0700 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 11 Aug 2016 17:50:43 -0000 Hi Keith, Yes, we agreed that the draft would define and use an INFO package registration, and it does so. My point is that the endpoints aren't relying on INFO package negotiation, they are compliant with the spec. It's a subtle difference, and not one observable "on the wire." There is an INFO package registration, and the draft requires compliance with INFO RFC. So, all is good. --Randy At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: > I fundamentally cannot agree to this statement. > > I thought we had agreed that the INFO package would be used, and > this statement is absolutely denying that. > > Chairs, please intervene with your understanding of the current consensus. > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 10 August 2016 22:39 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > In reality, there is no separate INFO package negotiation. The > endpoints support the data types not because they support the iNFO > package, but rather they support the INFO package and the data > types and Call-Info because they comply with the draft. > > At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> I disagree. >> >> The inclusion of the data element in INFO is nothing to do with RFC >> 7852. The data element is included because the use of an appropriate >> Info package has been negotiated and used. That Info package >> definition and the INFO mechanism itself makes no mention of use of >> Call-Info in association with it. >> >> Further I see no justification for complicating any error handling by >> suddenly defining it to be applicable, as it is not necessary. >> INFO requests always contain a data element appropriate to the Info >> package that is defined for its use - it absolutely does not need a >> secondary reference to the package. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 18:20 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >> ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Keith, >> >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>> then I have to agree with Ivo. That additional usage is not currently >>> defined in draft-ietf-ecrit-ecall, and I would need to understand >>> that usage before it is included. >>> >>> At the moment RFC7852 is only used for the transfer of MSD in >>> INVITE requests and 200 (OK) responses, and therefore that is the >>> only place where it should appear in association with RFC7852. >> >> RFC 7852 covers use of Call-Info to point to emergency call data >> blocks in any SIP message that is permitted to carry a body. >> >>> >>> Negotiation and transfer of MSD in association with INFO requests >>> is an entirely separate transfer mechanism, not covered by >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>> there as though it had been. Inclusion will lead to complete >>> confusion as to whether the requirements of the INFO mechanism or >>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>> should be absolutely clear that only the former apply. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek > >> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hello, >>> >>>> The invite response still has a body with content-disposition >>>> by-reference. If you remove the reference then its processing is >>>> undefined. >>> >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the >>> Content-Disposition header field of the >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition >>> header field of the application/emergencyCallData.eCall.control+xml >>> body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and thus >>> "render" would apply for the >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>> >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, >>> the Call-Info points to the >>> application/emergencyCallData.eCall.control+xml body. This body >> > contains a delivery report for the MSD sent in INVITE request. >> This is >>> NOT information about callee as described in RFC3261. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- The idea that >> Bill Gates has appeared like a knight in shining armor to lead all >> customers out of a mire of technological chaos neatly ignores the fact >> that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas Adams > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Einstein > never accepted quantum mechanics because of this element of chance > and uncertainty. He said, "God does not play dice." > It seems that Einstein was doubly wrong. The quantum effects of > black holes suggests that not only does God play dice, He sometimes > throws them where they cannot be seen. --Steven Hawking -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is very dangerous to be right when the established authorities are wrong. --Voltaire From nobody Thu Aug 11 17:47:58 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 D5A5312D67E for ; Thu, 11 Aug 2016 17:47:56 -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 JWzlWVYCZdY1 for ; Thu, 11 Aug 2016 17:47: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 AF77C12D67C for ; Thu, 11 Aug 2016 17:47:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 91D38E6501947; Fri, 12 Aug 2016 00:47:47 +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 u7C0lqfq002630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2016 00:47:52 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 u7C0kg4U011635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Aug 2016 02:47:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 12 Aug 2016 02:47:41 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Ivo Sedlacek , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8/jzxTW+oYWQU0eOVzCG5EzX9aBEe9Fg Date: Fri, 12 Aug 2016 00:47:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF4EFB6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45947@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 12 Aug 2016 00:47:57 -0000 To be honest, I believe you are making what you desire fit the INFO mechani= sm where it touchs, thus you have a concept of making something look like I= nfo, but which is not actually specified according to RFC 6086. Ecrit does not need to provide procedures that are already in RFC 6086, so = all it needs to say is that the xxx info package is mandatory for support o= n all ecrit calls in accordance with RFC 6086, and that covers the package = negotiation. Further I do not believe you need to add to the Info usage with add ons tha= t only seem to be there because they were in the previous version of your d= ocument, and are irrelevant for correct operation, such as the usage of a C= all-Info header field. They lead to future deployment and interoperability = problems which noone needs on an emergency call. Regards Keith -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 11 August 2016 18:51 To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Keith, Yes, we agreed that the draft would define and use an INFO package registra= tion, and it does so. My point is that the endpoints aren't relying on INF= O package negotiation, they are compliant with the spec. It's a subtle dif= ference, and not one observable "on the wire." There is an INFO package re= gistration, and the draft requires compliance with INFO RFC. So, all is go= od. --Randy At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: > I fundamentally cannot agree to this statement. > > I thought we had agreed that the INFO package would be used, and this=20 > statement is absolutely denying that. > > Chairs, please intervene with your understanding of the current consensu= s. > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 10 August 2016 22:39 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat;=20 > ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > In reality, there is no separate INFO package negotiation. The=20 > endpoints support the data types not because they support the iNFO=20 > package, but rather they support the INFO package and the data types=20 > and Call-Info because they comply with the draft. > > At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >> I disagree. >> >> The inclusion of the data element in INFO is nothing to do with RFC =20 >> 7852. The data element is included because the use of an appropriate =20 >> Info package has been negotiated and used. That Info package =20 >> definition and the INFO mechanism itself makes no mention of use of =20 >> Call-Info in association with it. >> >> Further I see no justification for complicating any error handling=20 >> by suddenly defining it to be applicable, as it is not necessary. >> INFO requests always contain a data element appropriate to the Info =20 >> package that is defined for its use - it absolutely does not need a =20 >> secondary reference to the package. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 18:20 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; =20 >> ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not =20 >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info =20 >> usage brings no value) >> >> Hi Keith, >> >> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> Unless someone is defining a new usage for Call-Info beyond=20 >>> RFC7852 then I have to agree with Ivo. That additional usage is not=20 >>> currently defined in draft-ietf-ecrit-ecall, and I would need to=20 >>> understand that usage before it is included. >>> >>> At the moment RFC7852 is only used for the transfer of MSD in =20 >>> INVITE requests and 200 (OK) responses, and therefore that is the =20 >>> only place where it should appear in association with RFC7852. >> >> RFC 7852 covers use of Call-Info to point to emergency call data =20 >> blocks in any SIP message that is permitted to carry a body. >> >>> >>> Negotiation and transfer of MSD in association with INFO requests =20 >>> is an entirely separate transfer mechanism, not covered by =20 >>> draft-ietf-ecrit-data-only-ea and therefore it should never appear =20 >>> there as though it had been. Inclusion will lead to complete =20 >>> confusion as to whether the requirements of the INFO mechanism or =20 >>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it =20 >>> should be absolutely clear that only the former apply. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo=20 >>> Sedlacek > >> Sent: 10 August 2016 08:41 >>> To: Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-=20 >>> Call-Info usage brings no value) >>> >>> Hello, >>> >>>> The invite response still has a body with content-disposition =20 >>>> by-reference. If you remove the reference then its processing is =20 >>>> undefined. >>> >>> If the Call-Info is omitted in INVITE response, then: >>> Alt1: a new value could be defined and used in the >>> Content-Disposition header field of the >>> application/emergencyCallData.eCall.control+xml body; >>> or >>> Alt2: an existing value could be used in the Content-Disposition >>> header field of the application/emergencyCallData.eCall.control+xml >>> body; >>> or >>> Alt3: the Content-Disposition header field can be omitted and=20 >>>thus >>> "render" would apply for the >>> application/emergencyCallData.eCall.control+xml body according to >>> RFC3261 section 13.2.1. >>> >>> We cannot use the Call-Info in INVITE response as described in >>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, =20 >>> the Call-Info points to the =20 >>> application/emergencyCallData.eCall.control+xml body. This body >> > contains a delivery report for the MSD sent in INVITE request. >> This is >>> NOT information about callee as described in RFC3261. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- The idea that =20 >> Bill Gates has appeared like a knight in shining armor to lead all =20 >> customers out of a mire of technological chaos neatly ignores the=20 >> fact that it was he who, by peddling second-rate technology, >> led them into it in the first place. --Douglas Adam= s > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Einstein never=20 > accepted quantum mechanics because of this element of chance and=20 > uncertainty. He said, "God does not play dice." > It seems that Einstein was doubly wrong. The quantum effects of black=20 > holes suggests that not only does God play dice, He sometimes throws=20 > them where they cannot be seen. --Steven Hawking -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is very dangerous = to be right when the established authorities are wrong. --Voltaire From nobody Fri Aug 12 04:09: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 1F01912D9BE for ; Fri, 12 Aug 2016 04:09:10 -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 hficVb3_t5X4 for ; Fri, 12 Aug 2016 04:09:08 -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 99CD512D0ED for ; Fri, 12 Aug 2016 04:09:08 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DD9C58EEEFC89; Fri, 12 Aug 2016 11:09:03 +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 u7CB95Xi030058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2016 11:09:05 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u7CB7tPx023116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Aug 2016 13:09:04 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 12 Aug 2016 13:08:25 +0200 From: "Drage, Keith (Nokia - GB)" To: Ivo Sedlacek , Randall Gellens , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8ysOl8HncDiLd0qZ6APr7B+knaBDZU/QgABOF8D///OQgIABg/Pg Date: Fri, 12 Aug 2016 11:08:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF5135E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF45926@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B31079006101164C4414@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164C4414@ESESSMB301.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.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 12 Aug 2016 11:09:10 -0000 RFC 7852 defines a general mechanism for adding a message body referenced b= y Call-Info, and provides no constraint on what those message bodies are. I= t creates a registry " Emergency Call Data Types" for listing these. It then goes on to define several specific additional data types of which t= he ones currently identified are as follows: +----------------+--------------+------------+ | Token | Data About | Reference | +----------------+--------------+------------+ | ProviderInfo | The Call | RFC 7852 | | ServiceInfo | The Call | RFC 7852 | | DeviceInfo | The Call | RFC 7852 | | SubscriberInfo | The Call | RFC 7852 | | Comment | The Call | RFC 7852 | +----------------+--------------+------------+ Obviously these will need to be reviewed and judgement applied as to whethe= r they relate to the sender of the Call-Info header field. Regards Keith -----Original Message----- From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]=20 Sent: 11 August 2016 14:51 To: Drage, Keith (Nokia - GB); Randall Gellens; Paul Kyzivat; ecrit@ietf.or= g Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) I identified the problem when reading draft-ietf-ecrit-ecall-11. I have not= followed RFC 7852 closely. If the body referenced in Call-Info in RFC 7852 contains additional informa= tion about callee or caller, then Call-Info usage in RFC 7852 is perfectly = OK. If the body referenced in Call-Info in RFC 7852 contains something unrelate= d to callee or caller, then Call-Info usage in RFC 7852 would suffer the sa= me problem as the two problematic use cases in draft-ietf-ecrit-ecall-11. Kind regards Ivo -----Original Message----- From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com]=20 Sent: Thursday, August 11, 2016 2:40 PM To: Ivo Sedlacek; Randall Gellens; Paul Kyzivat; ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Can you clarify whether this is a comment that RFC 7852 is not compliant wi= th RFC 3261 or that draft-ietf-ecrit-ecall is not compliant with RFC 3261? Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 11 August 2016 08:59 To: Randall Gellens; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hello, > Use of Call-Info to identify emergency data blocks is defined in RFC 7852= . RFC 7852 does not change RFC3261 so any usage of Call-Info must be complian= t to RFC3261 definition of the Call-Info. I.e. Call-Info must provide addit= ional information about the caller or callee.=20 This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INV= ITE response and INFO request. In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. Kind regards Ivo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 12 06:48:39 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 3135812D50C for ; Fri, 12 Aug 2016 06:48: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 mlEVTqfvlfhc for ; Fri, 12 Aug 2016 06:48:36 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 8630A12D190 for ; Fri, 12 Aug 2016 06:48:35 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-02v.sys.comcast.net with SMTP id YCp8b242Z1zBdYCp8b1baM; Fri, 12 Aug 2016 13:48:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id YCp7b6VLrMO8xYCp7bSHy3; Fri, 12 Aug 2016 13:48:34 +0000 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <98e3314b-e8ca-7a58-142e-4ec9a454ee44@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C42AF@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF45926@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B31079006101164C4414@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF5135E@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <50ad5316-d926-1bdd-c7ca-2cf9f573a121@alum.mit.edu> Date: Fri, 12 Aug 2016 09:48:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF5135E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJwCGC6PLUr/6aQLOiXkDe0xoSbC3o0pjckLofe7wB8oQl3L33RktGyHk+Hf0GLRC0asjbe1hcsoyh3llv/47i29zBHdPyRcFu0PQldvEJxqiySTbFgn SU0ZLqDFl1Z3FWpFAY9K8neWXqilcVD5913ydVznDwQQybdK8nGZE8gm2UBfjVHx3N/UqumgJ289cNT37cj7/u4TJx2gGaSn5mrxxa+r8il6g4EYN+3HyWvt FtBP035ckbrXFUgbXbOTEyq3XRhYCT4/yOjQWXFiDQt8Sx7/BXbMys5xB/Pc5UZB Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 12 Aug 2016 13:48:38 -0000 On 8/12/16 7:08 AM, Drage, Keith (Nokia - GB) wrote: > RFC 7852 defines a general mechanism for adding a message body referenced by Call-Info, and provides no constraint on what those message bodies are. It creates a registry " Emergency Call Data Types" for listing these. > > It then goes on to define several specific additional data types of which the ones currently identified are as follows: > > +----------------+--------------+------------+ > | Token | Data About | Reference | > +----------------+--------------+------------+ > | ProviderInfo | The Call | RFC 7852 | > | ServiceInfo | The Call | RFC 7852 | > | DeviceInfo | The Call | RFC 7852 | > | SubscriberInfo | The Call | RFC 7852 | > | Comment | The Call | RFC 7852 | > +----------------+--------------+------------+ > > Obviously these will need to be reviewed and judgement applied as to whether they relate to the sender of the Call-Info header field. I don't think we need to get too carried away here. Clearly at least *some* of this stuff is related to the sender. IMO that justifies using call-info. And note that call-info is explicitly permitted to provide info about the callee when used in responses. Thanks, Paul > Regards > > Keith > > -----Original Message----- > From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > Sent: 11 August 2016 14:51 > To: Drage, Keith (Nokia - GB); Randall Gellens; Paul Kyzivat; ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > I identified the problem when reading draft-ietf-ecrit-ecall-11. I have not followed RFC 7852 closely. > > If the body referenced in Call-Info in RFC 7852 contains additional information about callee or caller, then Call-Info usage in RFC 7852 is perfectly OK. > If the body referenced in Call-Info in RFC 7852 contains something unrelated to callee or caller, then Call-Info usage in RFC 7852 would suffer the same problem as the two problematic use cases in draft-ietf-ecrit-ecall-11. > > Kind regards > > Ivo > > -----Original Message----- > From: Drage, Keith (Nokia - GB) [mailto:keith.drage@nokia.com] > Sent: Thursday, August 11, 2016 2:40 PM > To: Ivo Sedlacek; Randall Gellens; Paul Kyzivat; ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > Can you clarify whether this is a comment that RFC 7852 is not compliant with RFC 3261 or that draft-ietf-ecrit-ecall is not compliant with RFC 3261? > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 11 August 2016 08:59 > To: Randall Gellens; Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) > > Hello, > >> Use of Call-Info to identify emergency data blocks is defined in RFC 7852. > > RFC 7852 does not change RFC3261 so any usage of Call-Info must be compliant to RFC3261 definition of the Call-Info. I.e. Call-Info must provide additional information about the caller or callee. > > This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INVITE response and INFO request. > > In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261. > > Kind regards > > Ivo > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Aug 12 12:50: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 2CEE212DA93 for ; Fri, 12 Aug 2016 12:50:05 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 BUwhR2MS4-QP for ; Fri, 12 Aug 2016 12:50:03 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5212DA91 for ; Fri, 12 Aug 2016 12:50:03 -0700 (PDT) Received: from [192.168.1.25] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 12 Aug 2016 12:50:02 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> References: <39B5E4D390E9BD4890E2B31079006101164C4437@ESESSMB301.ericsson.se> <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Aug 2016 12:49:57 -0700 To: Paul Kyzivat , 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-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) 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, 12 Aug 2016 19:50:05 -0000 Seems like RFC 7852 should have added Content-ID as a SIP header. At 10:50 AM -0400 8/11/16, Paul Kyzivat wrote: > Hmm. Interesting issue. > > ISTM the proper solution to that is to define Content-ID as a SIP > header field. > > Of course a work-around is to add a multipart wrapper to the single > body part. But that shouldn't be necessary. > > Thanks, > Paul > > On 8/11/16 10:04 AM, Ivo Sedlacek wrote: >> Hello, >> >> I found another potential issue. >> >> If a SIP message contains solely one body (i.e. not >> multipart/mixed body), then the SIP message cannot contain a >> Content-ID header field. >> >> Content-ID header field is NOT a SIP header field - Content-ID >> cannot be found in in RFC3261 and Content-ID cannot be found in >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 >> Content-ID header field is a MIME multipart/mixed header field. >> >> Also, rfc5621 states: >> ------------ >> Content-ID URLs allow creating references to body *parts*. >> ------------ >> >> Thus, Figure 10, and Figure 11 (and related procedures) of >> draft-ietf-ecrit-ecall-11 use a header field (Content-ID header >> field) not defined in SIP. >> >> Kind regards >> >> Ivo >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Associate yourself with people of good quality, for it is better to be alone than in bad company. --Booker T. Washington From nobody Fri Aug 12 13:13: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 654FB12D1B2 for ; Fri, 12 Aug 2016 13:13: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 PiR2qKJw382V for ; Fri, 12 Aug 2016 13:13:02 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7D12B01B for ; Fri, 12 Aug 2016 13:13:02 -0700 (PDT) Received: from [192.168.1.25] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 12 Aug 2016 13:13:01 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF4EFB6@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45947@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF4EFB6@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Fri, 12 Aug 2016 13:12:53 -0700 To: "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , Paul Kyzivat , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 12 Aug 2016 20:13:04 -0000 Hi Keith, The main aspect is sending data in INVITE and the response. Using INFO is a secondary mechanism that is only used in a subset of calls. So, we have use the RFC 7852 mechanism. When we use INFO, use still use RFC 7852, with additional aspects to comply with rules for using INFO. --Randy At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: > To be honest, I believe you are making what you desire fit the INFO > mechanism where it touchs, thus you have a concept of making > something look like Info, but which is not actually specified > according to RFC 6086. > > Ecrit does not need to provide procedures that are already in RFC > 6086, so all it needs to say is that the xxx info package is > mandatory for support on all ecrit calls in accordance with RFC > 6086, and that covers the package negotiation. > > Further I do not believe you need to add to the Info usage with add > ons that only seem to be there because they were in the previous > version of your document, and are irrelevant for correct operation, > such as the usage of a Call-Info header field. They lead to future > deployment and interoperability problems which noone needs on an > emergency call. > > Regards > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 11 August 2016 18:51 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hi Keith, > > Yes, we agreed that the draft would define and use an INFO package > registration, and it does so. My point is that the endpoints > aren't relying on INFO package negotiation, they are compliant with > the spec. It's a subtle difference, and not one observable "on the > wire." There is an INFO package registration, and the draft > requires compliance with INFO RFC. So, all is good. > > --Randy > > At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: > >> I fundamentally cannot agree to this statement. >> >> I thought we had agreed that the INFO package would be used, and this >> statement is absolutely denying that. >> >> Chairs, please intervene with your understanding of the current consensus. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 22:39 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >> ecrit@ietf.org >> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> In reality, there is no separate INFO package negotiation. The >> endpoints support the data types not because they support the iNFO >> package, but rather they support the INFO package and the data types >> and Call-Info because they comply with the draft. >> >> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> I disagree. >>> >>> The inclusion of the data element in INFO is nothing to do with RFC >>> 7852. The data element is included because the use of an appropriate >>> Info package has been negotiated and used. That Info package >>> definition and the INFO mechanism itself makes no mention of use of >>> Call-Info in association with it. >>> >>> Further I see no justification for complicating any error handling >>> by suddenly defining it to be applicable, as it is not necessary. >>> INFO requests always contain a data element appropriate to the Info >>> package that is defined for its use - it absolutely does not need a >>> secondary reference to the package. >>> >>> Keith >>> >>> -----Original Message----- > >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 18:20 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > >> usage brings no value) >>> >>> Hi Keith, >>> >>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> Unless someone is defining a new usage for Call-Info beyond >>>> RFC7852 then I have to agree with Ivo. That additional usage is not >>>> currently defined in draft-ietf-ecrit-ecall, and I would need to >>>> understand that usage before it is included. >>>> >>>> At the moment RFC7852 is only used for the transfer of MSD in >>>> INVITE requests and 200 (OK) responses, and therefore that is the >>>> only place where it should appear in association with RFC7852. >>> >>> RFC 7852 covers use of Call-Info to point to emergency call data >>> blocks in any SIP message that is permitted to carry a body. >>> >>>> >>>> Negotiation and transfer of MSD in association with INFO requests >>>> is an entirely separate transfer mechanism, not covered by >>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>> there as though it had been. Inclusion will lead to complete >>>> confusion as to whether the requirements of the INFO mechanism or >>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>> should be absolutely clear that only the former apply. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>> Sedlacek >> >> Sent: 10 August 2016 08:41 >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>> Call-Info usage brings no value) >>>> >>>> Hello, >>>> >>>>> The invite response still has a body with content-disposition >>>>> by-reference. If you remove the reference then its processing is >>>>> undefined. >>>> >>>> If the Call-Info is omitted in INVITE response, then: >>>> Alt1: a new value could be defined and used in the >>>> Content-Disposition header field of the >>>> application/emergencyCallData.eCall.control+xml body; >>>> or >>>> Alt2: an existing value could be used in the Content-Disposition >>>> header field of the application/emergencyCallData.eCall.control+xml >>>> body; >>>> or >>>> Alt3: the Content-Disposition header field can be omitted and >>>>thus >>>> "render" would apply for the >>>> application/emergencyCallData.eCall.control+xml body according to >>>> RFC3261 section 13.2.1. >>>> >>>> We cannot use the Call-Info in INVITE response as described in >>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, >>>> the Call-Info points to the >>>> application/emergencyCallData.eCall.control+xml body. This body >>> > contains a delivery report for the MSD sent in INVITE request. >>> This is >>>> NOT information about callee as described in RFC3261. >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- The idea that >>> Bill Gates has appeared like a knight in shining armor to lead all >>> customers out of a mire of technological chaos neatly ignores the >>> fact that it was he who, by peddling second-rate technology, >>> led them into it in the first place. --Douglas Adams >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- Einstein never > > accepted quantum mechanics because of this element of chance and >> uncertainty. He said, "God does not play dice." >> It seems that Einstein was doubly wrong. The quantum effects of black >> holes suggests that not only does God play dice, He sometimes throws >> them where they cannot be seen. --Steven Hawking > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- It is very > dangerous to be right when the established authorities > are wrong. --Voltaire -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Misery loves company, but company does not reciprocate. From nobody Sun Aug 14 22:59: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 5011F12D59E for ; Sun, 14 Aug 2016 22:59:57 -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 nhv6jsksT3Vf for ; Sun, 14 Aug 2016 22:59:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3F7F412B076 for ; Sun, 14 Aug 2016 22:59:55 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-71-57b15a561d00 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 08.E3.04209.65A51B75; Mon, 15 Aug 2016 07:59:53 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 07:59:50 +0200 From: Ivo Sedlacek To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR9NXwajCXcRwjtESw3qlTJgR2h6BJinJA Date: Mon, 15 Aug 2016 05:59:50 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164D649C@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45947@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF4EFB6@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdRjcyamO4wYY1qhaNi56yWmzYcpzF YsWGA6wW3593MTqwePx9/4HJY8mSn0wed29dYvLYeucxSwBLFJdNSmpOZllqkb5dAlfGxHXX mQv2+Fb8e/mBrYGx3baLkYNDQsBEYu1Cny5GLg4hgfWMEgcfL2SGcJYwSixoPcrSxcjJwSag JzFxyxFWkISIwEZGiQd7JrOAOMICKxklJq/+xARSJSKwilHiy0JxCNtI4vztx2DdLAKqEi9a HoHZvAK+Ep/XLWGCWHGAXWLp32csIHdwChhLXJiUDFLDKCArcfVPLyOIzSwgLnHryXyw+RIC AhJL9pxnhrBFJV4+/scKYStK7DzbzgxRryOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVFkFpKx s5C0zELSMgtJywJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv1R2Ml984HmIU 4GBU4uFdsHFDuBBrYllxZe4hRgkOZiUR3v2BG8OFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/ VAwXEkhPLEnNTk0tSC2CyTJxcEo1MKYvv2i+yFLmreqcQHtP962RRvKi4l7XF5zwzmxe/Zqr 2Wv+dkWLTV++xz7dK92l619QHC3QZtTT9MDa5WnUgsvXYsTiZHiu6c40NAhbtoDVen2ebpV8 f4fvPKV98tILdmlGS+/ZdtVRd6v9/pzze+ZrbawUMy5Y7ZFj/dhen7vdf1rJ63UWSizFGYmG WsxFxYkA9txvx5kCAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 05:59:57 -0000 Several people expressed a view that solely info package definition is requ= ired and Call-Info is not needed in INFO.=20 This is my view as well. Kind regards Ivo Sedlacek -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: Friday, August 12, 2016 10:13 PM To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Keith, The main aspect is sending data in INVITE and the response. Using INFO is = a secondary mechanism that is only used in a subset of calls.=20 So, we have use the RFC 7852 mechanism. When we use INFO, use still use RF= C 7852, with additional aspects to comply with rules for using INFO. --Randy At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: > To be honest, I believe you are making what you desire fit the INFO=20 > mechanism where it touchs, thus you have a concept of making something=20 > look like Info, but which is not actually specified according to RFC=20 > 6086. > > Ecrit does not need to provide procedures that are already in RFC=20 > 6086, so all it needs to say is that the xxx info package is mandatory=20 > for support on all ecrit calls in accordance with RFC 6086, and that=20 > covers the package negotiation. > > Further I do not believe you need to add to the Info usage with add=20 > ons that only seem to be there because they were in the previous=20 > version of your document, and are irrelevant for correct operation,=20 > such as the usage of a Call-Info header field. They lead to future=20 > deployment and interoperability problems which noone needs on an=20 > emergency call. > > Regards > > Keith > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: 11 August 2016 18:51 > To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat;=20 > ecrit@ietf.org > Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not=20 > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info=20 > usage brings no value) > > Hi Keith, > > Yes, we agreed that the draft would define and use an INFO package=20 > registration, and it does so. My point is that the endpoints aren't=20 > relying on INFO package negotiation, they are compliant with the spec. =20 > It's a subtle difference, and not one observable "on the wire." There=20 > is an INFO package registration, and the draft requires compliance=20 > with INFO RFC. So, all is good. > > --Randy > > At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: > >> I fundamentally cannot agree to this statement. >> >> I thought we had agreed that the INFO package would be used, and=20 >> this statement is absolutely denying that. >> >> Chairs, please intervene with your understanding of the current consen= sus. >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 10 August 2016 22:39 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; =20 >> ecrit@ietf.org >> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not =20 >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info =20 >> usage brings no value) >> >> In reality, there is no separate INFO package negotiation. The =20 >> endpoints support the data types not because they support the iNFO =20 >> package, but rather they support the INFO package and the data types =20 >> and Call-Info because they comply with the draft. >> >> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> I disagree. >>> >>> The inclusion of the data element in INFO is nothing to do with=20 >>> RFC 7852. The data element is included because the use of an=20 >>> appropriate Info package has been negotiated and used. That Info=20 >>> package definition and the INFO mechanism itself makes no mention=20 >>> of use of Call-Info in association with it. >>> >>> Further I see no justification for complicating any error=20 >>> handling by suddenly defining it to be applicable, as it is not neces= sary. >>> INFO requests always contain a data element appropriate to the=20 >>> Info package that is defined for its use - it absolutely does not=20 >>> need a secondary reference to the package. >>> >>> Keith >>> >>> -----Original Message----- > >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 18:20 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; =20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-=20 >>> Call-Info > >> usage brings no value) >>> >>> Hi Keith, >>> >>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> Unless someone is defining a new usage for Call-Info beyond >>>> RFC7852 then I have to agree with Ivo. That additional usage is=20 >>>> not currently defined in draft-ietf-ecrit-ecall, and I would need=20 >>>> to understand that usage before it is included. >>>> >>>> At the moment RFC7852 is only used for the transfer of MSD in =20 >>>> INVITE requests and 200 (OK) responses, and therefore that is the =20 >>>> only place where it should appear in association with RFC7852. >>> >>> RFC 7852 covers use of Call-Info to point to emergency call data =20 >>> blocks in any SIP message that is permitted to carry a body. >>> >>>> >>>> Negotiation and transfer of MSD in association with INFO=20 >>>> requests is an entirely separate transfer mechanism, not covered=20 >>>> by draft-ietf-ecrit-data-only-ea and therefore it should never=20 >>>> appear there as though it had been. Inclusion will lead to=20 >>>> complete confusion as to whether the requirements of the INFO=20 >>>> mechanism or the requirements of draft-ietf-ecrit-data-only-ea=20 >>>> apply, when it should be absolutely clear that only the former apply= . >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo =20 >>>> Sedlacek >> >> Sent: 10 August 2016 08:41 >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage =20 >>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- =20 >>>> Call-Info usage brings no value) >>>> >>>> Hello, >>>> >>>>> The invite response still has a body with content-disposition =20 >>>>> by-reference. If you remove the reference then its processing is =20 >>>>> undefined. >>>> >>>> If the Call-Info is omitted in INVITE response, then: >>>> Alt1: a new value could be defined and used in the >>>> Content-Disposition header field of the >>>> application/emergencyCallData.eCall.control+xml body; >>>> or >>>> Alt2: an existing value could be used in the Content-Disposition >>>> header field of the application/emergencyCallData.eCall.control+xml >>>> body; >>>> or >>>> Alt3: the Content-Disposition header field can be omitted and=20 >>>>thus >>>> "render" would apply for the >>>> application/emergencyCallData.eCall.control+xml body according to >>>> RFC3261 section 13.2.1. >>>> >>>> We cannot use the Call-Info in INVITE response as described in >>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE=20 >>>> request, the Call-Info points to the =20 >>>> application/emergencyCallData.eCall.control+xml body. This body >>> > contains a delivery report for the MSD sent in INVITE request. >>> This is >>>> NOT information about callee as described in RFC3261. >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself o= nly >>> -------------- Randomly selected tag: --------------- The idea=20 >>> that Bill Gates has appeared like a knight in shining armor to lead=20 >>> all customers out of a mire of technological chaos neatly ignores=20 >>> the fact that it was he who, by peddling second-rate technology, >>> led them into it in the first place. --Douglas Ad= ams >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- Einstein=20 >> never > > accepted quantum mechanics because of this element of chance and >> uncertainty. He said, "God does not play dice." >> It seems that Einstein was doubly wrong. The quantum effects of=20 >> black holes suggests that not only does God play dice, He sometimes=20 >> throws them where they cannot be seen. --Steven Hawking > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- It is very=20 > dangerous to be right when the established authorities > are wrong. --Voltaire -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Misery loves company,= but company does not reciprocate. From nobody Sun Aug 14 23:24: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 B3BDA12B029 for ; Sun, 14 Aug 2016 23:24:32 -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 mfXPuJUgiAvA for ; Sun, 14 Aug 2016 23:24:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4309212B00C for ; Sun, 14 Aug 2016 23:24:29 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-3e-57b1601cb337 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id A5.C6.04209.C1061B75; Mon, 15 Aug 2016 08:24:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 08:24:27 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAMNJ+oAASFKCgAFSmG+AAboa2YAD4U8A Date: Mon, 15 Aug 2016 06:24:26 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.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.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6F0FD3C9D03E504D996F66C7F5FF1997@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7h65MwsZwgwmLJS0aFz1ltdiw5TiL xYoNB1gtvj/vYnRg8fj7/gOTx5IlP5k87t66xOSx9c5jlgCWKC6blNSczLLUIn27BK6M80tm sRbM86s483glUwPjc9suRk4OCQETib5pT9hAbCGB9YwSm7bEdzFyAdlLGCW6bnxk72Lk4GAT sJDo/qcNUiMicJdRYtdmbxBbWGAho8SFByIQ8UWMEouXy0HYeRJPjx1jBGllEVCVmDDFHCTM K2AlMefgCWaIVe9YJE7frwAp4RQwlrgwKRkkzCggJvH91BomEJtZQFzi1pP5TBBXCkgs2XOe GcIWlXj5+B8riC0qoCfx/etsqLiixM6z7cwQvXoSN6ZOYYOwrSVal16FmqktsWzha2aIcwQl Ts58wjKBUWwWknWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIE Rt7BLb9VdzBefuN4iFGAg1GJh3fBxg3hQqyJZcWVuYcYJTiYlUR4NaI3hgvxpiRWVqUW5ccX leakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgTPqmXtj8Nk6wlXtJnaZe8J5f G3z6ZKKLulU8/r24Zu6skLn5cXqVoJCVhT4rg/l95lmHVv2aKyu9UcJy2eFszXkOdeeM1MSL S66Ica/KNz+k4rjuZ9Sf9zOWzVq0zuLeGaFwz7tqfBtip7/pMz2tcPd+lvI8FscTtfrun5fO rJp2vnXyG5ulSizFGYmGWsxFxYkA844/argCAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 06:24:33 -0000 Hi, I don=B9t know what is meant by =B3secondary mechanism=B2. When you use INF= O, there is one, only one, and nothing but one mechanism - info package. Whether INFO as such is only used in a subset of calls doesn=B9t really matter. WHEN it=B9s used, it has to be used as specified. Regards, Christer On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens" wrote: >Hi Keith, > >The main aspect is sending data in INVITE and the response. Using >INFO is a secondary mechanism that is only used in a subset of calls. >So, we have use the RFC 7852 mechanism. When we use INFO, use still >use RFC 7852, with additional aspects to comply with rules for using >INFO. > >--Randy > >At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: > >> To be honest, I believe you are making what you desire fit the INFO >> mechanism where it touchs, thus you have a concept of making >> something look like Info, but which is not actually specified >> according to RFC 6086. >> >> Ecrit does not need to provide procedures that are already in RFC >> 6086, so all it needs to say is that the xxx info package is >> mandatory for support on all ecrit calls in accordance with RFC >> 6086, and that covers the package negotiation. >> >> Further I do not believe you need to add to the Info usage with add >> ons that only seem to be there because they were in the previous >> version of your document, and are irrelevant for correct operation, >> such as the usage of a Call-Info header field. They lead to future >> deployment and interoperability problems which noone needs on an >> emergency call. >> >> Regards >> >> Keith >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 11 August 2016 18:51 >> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>ecrit@ietf.org >> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Keith, >> >> Yes, we agreed that the draft would define and use an INFO package >> registration, and it does so. My point is that the endpoints >> aren't relying on INFO package negotiation, they are compliant with >> the spec. It's a subtle difference, and not one observable "on the >> wire." There is an INFO package registration, and the draft >> requires compliance with INFO RFC. So, all is good. >> >> --Randy >> >> At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: >> >>> I fundamentally cannot agree to this statement. >>> >>> I thought we had agreed that the INFO package would be used, and this >>> statement is absolutely denying that. >>> >>> Chairs, please intervene with your understanding of the current >>>consensus. >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 22:39 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>> ecrit@ietf.org >>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> In reality, there is no separate INFO package negotiation. The >>> endpoints support the data types not because they support the iNFO >>> package, but rather they support the INFO package and the data types >>> and Call-Info because they comply with the draft. >>> >>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> I disagree. >>>> >>>> The inclusion of the data element in INFO is nothing to do with >>>>RFC=20 >>>> 7852. The data element is included because the use of an appropriate >>>> Info package has been negotiated and used. That Info package >>>> definition and the INFO mechanism itself makes no mention of use of >>>> Call-Info in association with it. >>>> >>>> Further I see no justification for complicating any error handling >>>> by suddenly defining it to be applicable, as it is not necessary. >>>> INFO requests always contain a data element appropriate to the Info >>>> package that is defined for its use - it absolutely does not need a >>>> secondary reference to the package. >>>> >>>> Keith >>>> >>>> -----Original Message----- >> >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 10 August 2016 18:20 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>not=20 >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> >> usage brings no value) >>>> >>>> Hi Keith, >>>> >>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> Unless someone is defining a new usage for Call-Info beyond >>>>> RFC7852 then I have to agree with Ivo. That additional usage is not >>>>> currently defined in draft-ietf-ecrit-ecall, and I would need to >>>>> understand that usage before it is included. >>>>> >>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>> INVITE requests and 200 (OK) responses, and therefore that is the >>>>> only place where it should appear in association with RFC7852. >>>> >>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>> blocks in any SIP message that is permitted to carry a body. >>>> >>>>> >>>>> Negotiation and transfer of MSD in association with INFO >>>>>requests=20 >>>>> is an entirely separate transfer mechanism, not covered by >>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>> there as though it had been. Inclusion will lead to complete >>>>> confusion as to whether the requirements of the INFO mechanism or >>>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>> should be absolutely clear that only the former apply. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>> Sedlacek >>> >> Sent: 10 August 2016 08:41 >>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>> Call-Info usage brings no value) >>>>> >>>>> Hello, >>>>> >>>>>> The invite response still has a body with content-disposition >>>>>> by-reference. If you remove the reference then its processing is >>>>>> undefined. >>>>> >>>>> If the Call-Info is omitted in INVITE response, then: >>>>> Alt1: a new value could be defined and used in the >>>>> Content-Disposition header field of the >>>>> application/emergencyCallData.eCall.control+xml body; >>>>> or >>>>> Alt2: an existing value could be used in the Content-Disposition >>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>> body; >>>>> or >>>>> Alt3: the Content-Disposition header field can be omitted and >>>>>thus >>>>> "render" would apply for the >>>>> application/emergencyCallData.eCall.control+xml body according to >>>>> RFC3261 section 13.2.1. >>>>> >>>>> We cannot use the Call-Info in INVITE response as described in >>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>request,=20 >>>>> the Call-Info points to the >>>>> application/emergencyCallData.eCall.control+xml body. This body >>>> > contains a delivery report for the MSD sent in INVITE request. >>>> This is >>>>> NOT information about callee as described in RFC3261. >>>>> >>>>> Kind regards >>>>> >>>>> Ivo >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- The idea >>>>that=20 >>>> Bill Gates has appeared like a knight in shining armor to lead all >>>> customers out of a mire of technological chaos neatly ignores the >>>> fact that it was he who, by peddling second-rate technology, >>>> led them into it in the first place. --Douglas >>>>Adams >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself >>>only >>> -------------- Randomly selected tag: --------------- Einstein never >> > accepted quantum mechanics because of this element of chance and >>> uncertainty. He said, "God does not play dice." >>> It seems that Einstein was doubly wrong. The quantum effects of black >>> holes suggests that not only does God play dice, He sometimes throws >>> them where they cannot be seen. --Steven Hawking >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- It is very >> dangerous to be right when the established authorities >> are wrong. --Voltaire > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >Misery loves company, but company does not reciprocate. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 15 02: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 8B96512D103 for ; Mon, 15 Aug 2016 02:16:48 -0700 (PDT) X-Quarantine-ID: <9KXms61WwT4Q> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 9KXms61WwT4Q for ; Mon, 15 Aug 2016 02:16:46 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 27DB212B059 for ; Mon, 15 Aug 2016 02:16:46 -0700 (PDT) Received: from [10.79.0.197] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 02:16:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 15 Aug 2016 02:16:40 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 09:16:48 -0000 Hi Christer, I don't think anyone is suggesting that INFO be used without conforming to its specification. --Randy At 6:24 AM +0000 8/15/16, Christer Holmberg wrote: > Hi, > > I don't know what is meant by "secondary mechanism". When you use INFO, > there is one, only one, and nothing but one mechanism - info package. > > Whether INFO as such is only used in a subset of calls doesn't really > matter. WHEN it's used, it has to be used as specified. > > Regards, > > Christer > > > On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens" > wrote: > >>Hi Keith, >> >>The main aspect is sending data in INVITE and the response. Using >>INFO is a secondary mechanism that is only used in a subset of calls. >>So, we have use the RFC 7852 mechanism. When we use INFO, use still >>use RFC 7852, with additional aspects to comply with rules for using >>INFO. >> >>--Randy >> >>At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: >> >>> To be honest, I believe you are making what you desire fit the INFO >>> mechanism where it touchs, thus you have a concept of making >>> something look like Info, but which is not actually specified >>> according to RFC 6086. >>> >>> Ecrit does not need to provide procedures that are already in RFC >>> 6086, so all it needs to say is that the xxx info package is >>> mandatory for support on all ecrit calls in accordance with RFC >>> 6086, and that covers the package negotiation. >>> >>> Further I do not believe you need to add to the Info usage with add >>> ons that only seem to be there because they were in the previous >>> version of your document, and are irrelevant for correct operation, >>> such as the usage of a Call-Info header field. They lead to future >>> deployment and interoperability problems which noone needs on an >>> emergency call. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 11 August 2016 18:51 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>ecrit@ietf.org >>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hi Keith, >>> >>> Yes, we agreed that the draft would define and use an INFO package >>> registration, and it does so. My point is that the endpoints >>> aren't relying on INFO package negotiation, they are compliant with >>> the spec. It's a subtle difference, and not one observable "on the >>> wire." There is an INFO package registration, and the draft >>> requires compliance with INFO RFC. So, all is good. >>> >>> --Randy >>> >>> At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: >>> >>>> I fundamentally cannot agree to this statement. >>>> >>>> I thought we had agreed that the INFO package would be used, and this >>>> statement is absolutely denying that. >>>> >>>> Chairs, please intervene with your understanding of the current >>>>consensus. >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 10 August 2016 22:39 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> In reality, there is no separate INFO package negotiation. The >>>> endpoints support the data types not because they support the iNFO >>>> package, but rather they support the INFO package and the data types > >>> and Call-Info because they comply with the draft. >>>> >>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >>> >>>>> I disagree. >>>>> >>>>> The inclusion of the data element in INFO is nothing to do with >>>>>RFC >>>>> 7852. The data element is included because the use of an appropriate >>>>> Info package has been negotiated and used. That Info package >>>>> definition and the INFO mechanism itself makes no mention of use of >>>>> Call-Info in association with it. >>>>> >>>>> Further I see no justification for complicating any error handling >>>>> by suddenly defining it to be applicable, as it is not necessary. >>>>> INFO requests always contain a data element appropriate to the Info >>>>> package that is defined for its use - it absolutely does not need a >>>>> secondary reference to the package. >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>> >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 10 August 2016 18:20 >>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> >> usage brings no value) >>>>> >>>>> Hi Keith, >>>>> >>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>> >>>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>> RFC7852 then I have to agree with Ivo. That additional usage is not >>>>>> currently defined in draft-ietf-ecrit-ecall, and I would need to >>>>>> understand that usage before it is included. >>>>>> >>>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>> INVITE requests and 200 (OK) responses, and therefore that is the >>>>>> only place where it should appear in association with RFC7852. >>>>> >>>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>>> blocks in any SIP message that is permitted to carry a body. >>>>> >>>>>> >>>>>> Negotiation and transfer of MSD in association with INFO >>>>>>requests >>>>>> is an entirely separate transfer mechanism, not covered by >>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>>> there as though it had been. Inclusion will lead to complete >>>>>> confusion as to whether the requirements of the INFO mechanism or >>>>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>> should be absolutely clear that only the former apply. >>>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>>> Sedlacek >>>> >> Sent: 10 August 2016 08:41 >>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>> Call-Info usage brings no value) >>>>>> >>>>>> Hello, >>>>>> >>>>>>> The invite response still has a body with content-disposition >>>>>>> by-reference. If you remove the reference then its processing is >>>>>>> undefined. >>>>>> >>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>> Alt1: a new value could be defined and used in the >>>>>> Content-Disposition header field of the >>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>> or >>>>>> Alt2: an existing value could be used in the Content-Disposition >>>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>>> body; >>>>>> or >>>>>> Alt3: the Content-Disposition header field can be omitted and >>>>>>thus >>>>>> "render" would apply for the >>>>>> application/emergencyCallData.eCall.control+xml body according to >>>>>> RFC3261 section 13.2.1. >>>>>> >>>>>> We cannot use the Call-Info in INVITE response as described in >>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>>request, >>>>>> the Call-Info points to the >>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>> > contains a delivery report for the MSD sent in INVITE request. > >>>> This is >>>>>> NOT information about callee as described in RFC3261. > >>>>> >>>>>> Kind regards >>>>>> >>>>>> Ivo >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself >>>>>only >>>>> -------------- Randomly selected tag: --------------- The idea >>>>>that >>>>> Bill Gates has appeared like a knight in shining armor to lead all >>>>> customers out of a mire of technological chaos neatly ignores the >>>>> fact that it was he who, by peddling second-rate technology, >>>>> led them into it in the first place. --Douglas >>>>>Adams >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- Einstein never >>> > accepted quantum mechanics because of this element of chance and >>>> uncertainty. He said, "God does not play dice." >>>> It seems that Einstein was doubly wrong. The quantum effects of black >>>> holes suggests that not only does God play dice, He sometimes throws >>>> them where they cannot be seen. --Steven Hawking >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- It is very >>> dangerous to be right when the established authorities >>> are wrong. --Voltaire >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>Misery loves company, but company does not reciprocate. >> >>_______________________________________________ >>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: --------------- Gossip is when you hear something you like about someone you don't. --Earl Wilson From nobody Mon Aug 15 02:33: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 82FD312B02B for ; Mon, 15 Aug 2016 02:33:40 -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 EImrJauW_n0x for ; Mon, 15 Aug 2016 02:33:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 CF18D12D108 for ; Mon, 15 Aug 2016 02:33:34 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-86-57b18c6c434b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id B1.5B.02493.C6C81B75; Mon, 15 Aug 2016 11:33:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 11:33:13 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR9tXA85cDq5XcSUuo+cj+thItjKBJwmlg Date: Mon, 15 Aug 2016 09:33:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC05DB1@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.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_7594FB04B1934943A5C02806D1A2204B4BC05DB1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7jW5Oz8Zwgyf/LC0aFz1ltdiw5TiL xYoNB1gtvj/vYnRg8fj7/gOTx5IlP5k87t66xOSx9c5jlgCWKC6blNSczLLUIn27BK6M6ftf MxecamCqWHXrJ1MD47dbjF2MnBwSAiYSLXM2s3YxcnEICaxnlNj9aBEThLOEUWLF25XsXYwc HGwCFhLd/7RB4iIC9xglfn/9xA7iCAssZpTYtaKVBSID1LHw10WwuSICRhIdLZPYQGwWAVWJ 7R0gOzg5eAV8JR7NngK14jirxLPbLWAJTqCGgw19YA2MAmIS30+tYQKxmQXEJZq+rGSFOFZA Ysme88wQtqjEy8f/WEHOYxbIl2j9lwgxX1Di5MwnLBMYhWYh6Z6FUDULSRVEiYHEl/e3oWxt iWULXzND2PoS3e9PMyGLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGFcHt/y22sF4 8LnjIUYBDkYlHt4FGzeEC7EmlhVX5h5ilOBgVhLhle7aGC7Em5JYWZValB9fVJqTWnyIUZqD RUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBUTXiwAEFFgvGSXaCM2V/XOIs76l+01OlLLbS PFnv5hLX/kcNbe+6VjfesP35fVdKl3NAoKemhZ7Nh9zXutoPP0WYxH+V+vbywFyf7H+rrwVf cNqXpiw0x/n3sYPMXHzZy6/sMVJSW3tV6Ewx07O27MM9R3R7Jpr/4t6Wtc7kk6Gx+5Vpy7s3 KLEUZyQaajEXFScCAAkSfcSnAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 09:33:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC05DB1ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, No, but you also want to somehow mix it with other mechanisms (well, parts = of other mechanisms, actually). Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD15/=FD08/=FD2016 12:16 To: Christer Holmberg; Drage, Keith = (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; ecrit@ietf.or= g Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings n= o value) Hi Christer, I don't think anyone is suggesting that INFO be used without conforming to its specification. --Randy At 6:24 AM +0000 8/15/16, Christer Holmberg wrote: > Hi, > > I don't know what is meant by "secondary mechanism". When you use INFO, > there is one, only one, and nothing but one mechanism - info package. > > Whether INFO as such is only used in a subset of calls doesn't really > matter. WHEN it's used, it has to be used as specified. > > Regards, > > Christer > > > On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens" > wrote: > >>Hi Keith, >> >>The main aspect is sending data in INVITE and the response. Using >>INFO is a secondary mechanism that is only used in a subset of calls. >>So, we have use the RFC 7852 mechanism. When we use INFO, use still >>use RFC 7852, with additional aspects to comply with rules for using >>INFO. >> >>--Randy >> >>At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: >> >>> To be honest, I believe you are making what you desire fit the INFO >>> mechanism where it touchs, thus you have a concept of making >>> something look like Info, but which is not actually specified >>> according to RFC 6086. >>> >>> Ecrit does not need to provide procedures that are already in RFC >>> 6086, so all it needs to say is that the xxx info package is >>> mandatory for support on all ecrit calls in accordance with RFC >>> 6086, and that covers the package negotiation. >>> >>> Further I do not believe you need to add to the Info usage with add >>> ons that only seem to be there because they were in the previous >>> version of your document, and are irrelevant for correct operation, >>> such as the usage of a Call-Info header field. They lead to future >>> deployment and interoperability problems which noone needs on an >>> emergency call. >>> >>> Regards >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 11 August 2016 18:51 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>ecrit@ietf.org >>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hi Keith, >>> >>> Yes, we agreed that the draft would define and use an INFO package >>> registration, and it does so. My point is that the endpoints >>> aren't relying on INFO package negotiation, they are compliant with >>> the spec. It's a subtle difference, and not one observable "on the >>> wire." There is an INFO package registration, and the draft >>> requires compliance with INFO RFC. So, all is good. >>> >>> --Randy >>> >>> At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: >>> >>>> I fundamentally cannot agree to this statement. >>>> >>>> I thought we had agreed that the INFO package would be used, and th= is >>>> statement is absolutely denying that. >>>> >>>> Chairs, please intervene with your understanding of the current >>>>consensus. >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 10 August 2016 22:39 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> In reality, there is no separate INFO package negotiation. The >>>> endpoints support the data types not because they support the iNFO >>>> package, but rather they support the INFO package and the data types > >>> and Call-Info because they comply with the draft. >>>> >>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: > >>> >>>>> I disagree. >>>>> >>>>> The inclusion of the data element in INFO is nothing to do with >>>>>RFC >>>>> 7852. The data element is included because the use of an appropriat= e >>>>> Info package has been negotiated and used. That Info package >>>>> definition and the INFO mechanism itself makes no mention of use of >>>>> Call-Info in association with it. >>>>> >>>>> Further I see no justification for complicating any error handlin= g >>>>> by suddenly defining it to be applicable, as it is not necessary. >>>>> INFO requests always contain a data element appropriate to the Inf= o >>>>> package that is defined for its use - it absolutely does not need a >>>>> secondary reference to the package. >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>> >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 10 August 2016 18:20 >>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> >> usage brings no value) >>>>> >>>>> Hi Keith, >>>>> >>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>> >>>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>> RFC7852 then I have to agree with Ivo. That additional usage is n= ot >>>>>> currently defined in draft-ietf-ecrit-ecall, and I would need to >>>>>> understand that usage before it is included. >>>>>> >>>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>> INVITE requests and 200 (OK) responses, and therefore that is the >>>>>> only place where it should appear in association with RFC7852. >>>>> >>>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>>> blocks in any SIP message that is permitted to carry a body. >>>>> >>>>>> >>>>>> Negotiation and transfer of MSD in association with INFO >>>>>>requests >>>>>> is an entirely separate transfer mechanism, not covered by >>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>>> there as though it had been. Inclusion will lead to complete >>>>>> confusion as to whether the requirements of the INFO mechanism or >>>>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>> should be absolutely clear that only the former apply. >>>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>>> Sedlacek >>>> >> Sent: 10 August 2016 08:41 >>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>> Call-Info usage brings no value) >>>>>> >>>>>> Hello, >>>>>> >>>>>>> The invite response still has a body with content-disposition >>>>>>> by-reference. If you remove the reference then its processing is >>>>>>> undefined. >>>>>> >>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>> Alt1: a new value could be defined and used in the >>>>>> Content-Disposition header field of the >>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>> or >>>>>> Alt2: an existing value could be used in the Content-Dispositio= n >>>>>> header field of the application/emergencyCallData.eCall.control+x= ml >>>>>> body; >>>>>> or >>>>>> Alt3: the Content-Disposition header field can be omitted and >>>>>>thus >>>>>> "render" would apply for the >>>>>> application/emergencyCallData.eCall.control+xml body according to >>>>>> RFC3261 section 13.2.1. >>>>>> >>>>>> We cannot use the Call-Info in INVITE response as described in >>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>>request, >>>>>> the Call-Info points to the >>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>> > contains a delivery report for the MSD sent in INVITE request. > >>>> This is >>>>>> NOT information about callee as described in RFC3261. > >>>>> >>>>>> Kind regards >>>>>> >>>>>> Ivo >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for mysel= f >>>>>only >>>>> -------------- Randomly selected tag: --------------- The idea >>>>>that >>>>> Bill Gates has appeared like a knight in shining armor to lead all >>>>> customers out of a mire of technological chaos neatly ignores the >>>>> fact that it was he who, by peddling second-rate technology, >>>>> led them into it in the first place. --Douglas >>>>>Adams >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- Einstein neve= r >>> > accepted quantum mechanics because of this element of chance and >>>> uncertainty. He said, "God does not play dice." >>>> It seems that Einstein was doubly wrong. The quantum effects of bla= ck >>>> holes suggests that not only does God play dice, He sometimes throws >>>> them where they cannot be seen. --Steven Hawking >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself on= ly >>> -------------- Randomly selected tag: --------------- It is very >>> dangerous to be right when the established authorities >>> are wrong. --Voltaire >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>Misery loves company, but company does not reciprocate. >> >>_______________________________________________ >>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: --------------- Gossip is when you hear something you like about someone you don't. --Earl Wilson --_000_7594FB04B1934943A5C02806D1A2204B4BC05DB1ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

No, but you also want to somehow mix it with other mechanisms (well, parts = of other mechanisms, actually).

Regards,

Christer

Sent from my Windows Phone
From: Randall Gellens
Sent: =FD15= /=FD08/=FD2016 12:16
To: Christer Holmberg; Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul  Kyziv= at; ecrit@ietf.org
Subject: Re: [= Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned  with RF= C3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no  v= alue)

Hi Christer,

I don't think anyone is suggesting that INFO be used without
conforming to its specification.

--Randy

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

>  Hi,
>
>  I don't know what is meant by "secondary mechanism". W= hen you use INFO,
>  there is one, only one, and nothing but one mechanism - info pac= kage.
>
>  Whether INFO as such is only used in a subset of calls doesn't r= eally
>  matter. WHEN it's used, it has to be used as specified.
>
>  Regards,
>
>  Christer
>
>
>  On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens"= ;
>  <ecrit-bounces@ietf.org on behalf of rg+ietf@randy.pensiv= e.org> wrote:
>
>>Hi Keith,
>>
>>The main aspect is sending data in INVITE and the response.  U= sing
>>INFO is a secondary mechanism that is only used in a subset of call= s.
>>So, we have use the RFC 7852 mechanism.  When we use INFO, use= still
>>use RFC 7852, with additional aspects to comply with rules for usin= g
>>INFO.
>>
>>--Randy
>>
>>At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote:
>>
>>>   To be honest, I believe you are making what you de= sire fit the INFO
>>>  mechanism where it touchs, thus you have a concept of ma= king
>>>  something look like Info, but which is not actually spec= ified
>>>  according to RFC 6086.
>>>
>>>   Ecrit does not need to provide procedures that are= already in RFC
>>>  6086, so all it needs to say is that the xxx info packag= e is
>>>  mandatory for support on all ecrit calls in accordance w= ith RFC
>>>  6086, and that covers the package negotiation.
>>>
>>>   Further I do not believe you need to add to the In= fo usage with add
>>>  ons that only seem to be there because they were in the = previous
>>>  version of your document, and are irrelevant for correct= operation,
>>>  such as the usage of a Call-Info header field. They lead= to future
>>>  deployment and interoperability problems which noone nee= ds on an
>>>  emergency call.
>>>
>>>   Regards
>>>
>>>   Keith
>>>
>>>   -----Original Message-----
>>>   From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]
>>>   Sent: 11 August 2016 18:51
>>>   To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul = Kyzivat;
>>>ecrit@ietf.org
>>>   Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Ca= ll-Info usage not
>>>  aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-= Call-Info
>>>  usage brings no value)
>>>
>>>   Hi Keith,
>>>
>>>   Yes, we agreed that the draft would define and use= an INFO package
>>>  registration, and it does so.  My point is that the= endpoints
>>>  aren't relying on INFO package negotiation, they are com= pliant with
>>>  the spec.  It's a subtle difference, and not one ob= servable "on the
>>>  wire."  There is an INFO package registration,= and the draft
>>>  requires compliance with INFO RFC.  So, all is good= .
>>>
>>>   --Randy
>>>
>>>   At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) = Drage wrote:
>>>
>>>>    I fundamentally cannot agree to this sta= tement.
>>>>
>>>>    I thought we had agreed that the INFO pa= ckage would be used, and this
>>>>   statement is absolutely denying that.
>>>>
>>>>    Chairs, please intervene with your under= standing of the current
>>>>consensus.
>>>>
>>>>    Keith
>>>>
>>>>    -----Original Message-----
>>>>    From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>    Sent: 10 August 2016 22:39
>>>>    To: Drage, Keith (Nokia - GB); Ivo Sedla= cek; Paul Kyzivat;
>>>>   ecrit@ietf.org
>>>>    Subject: RE: [Ecrit] draft-ietf-ecrit-ec= all-11- Call-Info usage not
>>>>   aligned with RFC3261 (was RE: draft-ietf-ecrit= -ecall-11- Call-Info
>>>>   usage brings no value)
>>>>
>>>>    In reality, there is no separate INFO pa= ckage negotiation.  The
>>>>   endpoints support the data types not because t= hey support the iNFO
>>>>   package, but rather they support the INFO pack= age and the data types
>   >>>  and Call-Info because they comply with = the draft.
>>>>
>>>>    At 5:29 PM +0000 8/10/16, Keith (Nok= ia - GB) Drage wrote:
>   >>>
>>>>>     I disagree.
>>>>>
>>>>>     The inclusion of the data elem= ent in INFO is nothing to do with
>>>>>RFC
>>>>>   7852. The data element is included because= the use of an appropriate
>>>>>   Info package has been negotiated and used.= That Info package
>>>>>   definition and the INFO mechanism itself m= akes no mention of use of
>>>>>   Call-Info in association with it.
>>>>>
>>>>>     Further I see no justification= for complicating any error handling
>>>>>   by  suddenly defining it to be applic= able, as it is not necessary.
>>>>>    INFO requests always contain a data = element appropriate to the Info
>>>>>   package that is defined for its use - it a= bsolutely does not need a
>>>>>   secondary reference to the package.
>>>>>
>>>>>     Keith
>>>>>
>>>>>     -----Original Message-----
>>>    >>   From: Randall Gellens [= mailto:rg+ietf@randy.p= ensive.org]
>>>>>     Sent: 10 August 2016 18:20
>>>>>     To: Drage, Keith (Nokia - GB);= Ivo Sedlacek; Paul Kyzivat;
>>>>>   ecrit@ietf.org
>>>>>     Subject: Re: [Ecrit] draft-iet= f-ecrit-ecall-11- Call-Info usage
>>>>>not
>>>>>   aligned with RFC3261 (was RE: draft-ietf-e= crit-ecall-11- Call-Info
>>>    >> usage brings no value)
>>>>>
>>>>>     Hi Keith,
>>>>>
>>>>>     At 3:11 PM +0000 8/10/16, = Keith (Nokia - GB) Drage wrote:
>>>>>
>>>>>>      Unless someone is de= fining a new usage for Call-Info beyond
>>>>>>   RFC7852  then I have to agree wit= h Ivo. That additional usage is not
>>>>>>   currently  defined in draft-ietf-= ecrit-ecall, and I would need to
>>>>>>   understand  that  usage befo= re it is included.
>>>>>>
>>>>>>      At the moment RFC785= 2 is only used for the transfer of MSD in
>>>>>>   INVITE  requests and 200 (OK) res= ponses, and therefore that is the
>>>>>>   only place  where it should appea= r in association with RFC7852.
>>>>>
>>>>>     RFC 7852 covers use of Call-In= fo to point to emergency call data
>>>>>   blocks in any SIP message that is permitte= d to carry a body.
>>>>>
>>>>>>
>>>>>>      Negotiation and tran= sfer of MSD in association with INFO
>>>>>>requests
>>>>>>   is  an entirely separate transfer= mechanism, not covered by
>>>>>>   draft-ietf-ecrit-data-only-ea and ther= efore it should never appear
>>>>>>   there as though it had been. Inclusion= will lead to complete
>>>>>>   confusion  as to whether the requ= irements of the INFO mechanism or
>>>>>>   the  requirements of draft-ietf-e= crit-data-only-ea apply, when it
>>>>>>   should be  absolutely clear that = only the former apply.
>>>>>>
>>>>>>      Regards
>>>>>>
>>>>>>      Keith
>>>>>>
>>>>>>      -----Original Messag= e-----
>>>>>>      From: Ecrit [mailto:ecrit-bounces@ietf.org] On Be= half Of Ivo
>>>>>>   Sedlacek
>>>>     >>   Sent: 10 Augu= st 2016 08:41
>>>>>>      To: Paul Kyzivat; ec= rit@ietf.org
>>>>>>      Subject: Re: [Ecrit]= draft-ietf-ecrit-ecall-11- Call-Info usage
>>>>>>   not  aligned with RFC3261 (was RE= : draft-ietf-ecrit-ecall-11-
>>>>>>   Call-Info  usage brings no value)=
>>>>>>
>>>>>>      Hello,
>>>>>>
>>>>>>>      The invite respo= nse still has a body with content-disposition
>>>>>>>   by-reference. If you remove the re= ference then its processing is
>>>>>>>   undefined.
>>>>>>
>>>>>>      If the Call-Info is = omitted in INVITE response, then:
>>>>>>      Alt1: a new value co= uld be defined and used in the
>>>>>>    Content-Disposition header field= of the
>>>>>>    application/emergencyCallData.eC= all.control+xml body;
>>>>>>  or
>>>>>>      Alt2: an existing va= lue could be used in the Content-Disposition
>>>>>>    header field of the application/= emergencyCallData.eCall.control+xml
>>>>>>     body;
>>>>>>  or
>>>>>>      Alt3: the Content-Di= sposition header field can be omitted and
>>>>>>thus
>>>>>>    "render" would apply f= or the
>>>>>>    application/emergencyCallData.eC= all.control+xml body according to
>>>>>>     RFC3261 section 13.2.1. >>>>>>
>>>>>>      We cannot use the Ca= ll-Info in INVITE response as described in
>>>>>>     draft-ietf-ecrit-ecall-11 = - in the response to the INVITE
>>>>>>request,
>>>>>>   the  Call-Info points to the
>>>>>>   application/emergencyCallData.eCall.co= ntrol+xml body. This body
>>>>>      > contains a delivery= report for the MSD sent in INVITE request.
>   >>>>   This is
>>>>>>     NOT information about call= ee as described in RFC3261.
>   >>>>>
>>>>>>      Kind regards
>>>>>>
>>>>>>      Ivo
>>>>>>
>>>>>>
>>>>>>      ____________________= ___________________________
>>>>>>      Ecrit mailing list >>>>>>      Ecrit@ietf.org
>>>>>>      https://www.ietf.org/mailman/listinfo/e= crit
>>>>>>
>>>>>>      ____________________= ___________________________
>>>>>>      Ecrit mailing list >>>>>>      Ecrit@ietf.org
>>>>>>      https://www.ietf.org/mailman/listinfo/e= crit
>>>>>
>>>>>
>>>>>     --
>>>>>     Randall Gellens
>>>>>     Opinions are personal; &n= bsp;  facts are suspect;    I speak for myself
>>>>>only
>>>>>     -------------- Randomly select= ed tag: --------------- The idea
>>>>>that
>>>>>   Bill Gates has appeared like a knight in s= hining armor to lead all
>>>>>   customers out of a mire of technological c= haos neatly ignores the
>>>>>   fact  that it was he who, by peddling= second-rate technology,
>>>>>     led them into it in the first = place.           &nb= sp;        --Douglas
>>>>>Adams
>>>>
>>>>
>>>>    --
>>>>    Randall Gellens
>>>>    Opinions are personal;   = facts are suspect;    I speak for myself
>>>>only
>>>>    -------------- Randomly selected tag: --= ------------- Einstein never
>>>    > accepted quantum mechanics because of t= his element of chance and
>>>>   uncertainty. He said, "God does not play = dice."
>>>>    It seems that Einstein was doubly wrong.= The quantum effects of black
>>>>   holes suggests that not only does God play dic= e, He sometimes throws
>>>>   them where they cannot be seen.  --Steven= Hawking
>>>
>>>
>>>   --
>>>   Randall Gellens
>>>   Opinions are personal;    facts are= suspect;    I speak for myself only
>>>   -------------- Randomly selected tag: ------------= --- It is very
>>>  dangerous to be right when the established authorities >>>   are wrong.      &nbs= p;            &= nbsp;       --Voltaire
>>
>>
>>--
>>Randall Gellens
>>Opinions are personal;    facts are suspect; &n= bsp;  I speak for myself only
>>-------------- Randomly selected tag: ---------------
>>Misery loves company, but company does not reciprocate.
>>
>>_______________________________________________
>>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: ---------------
Gossip is when you hear something you like about someone you don't.
    --Earl Wilson
 --_000_7594FB04B1934943A5C02806D1A2204B4BC05DB1ESESSMB209erics_-- From nobody Mon Aug 15 03:31:34 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 EE77A12D790 for ; Mon, 15 Aug 2016 03:31:32 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 LkfAuJjv9U0d for ; Mon, 15 Aug 2016 03:31:30 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA5A12D7CD for ; Mon, 15 Aug 2016 03:31:30 -0700 (PDT) Received: from [10.79.0.197] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 03:31:28 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC05DB1@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> , <7594FB04B1934943A5C02806D1A2204B4BC05DB1@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 15 Aug 2016 03:31:23 -0700 To: Christer Holmberg , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 10:31:33 -0000 Hi Christer, Yes, we want the mechanism to be consistent. --Randy At 9:33 AM +0000 8/15/16, Christer Holmberg wrote: > Hi, > > No, but you also want to somehow mix it with other mechanisms > (well, parts of other mechanisms, actually). > > Regards, > > Christer > > Sent from my Windows Phone > > From: Randall Gellens > Sent: 15/08/2016 12:16 > To: Christer Holmberg; > Drage, Keith (Nokia - GB); > Ivo Sedlacek; > Paul Kyzivat; > ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info > usage brings no value) > > Hi Christer, > > I don't think anyone is suggesting that INFO be used without > conforming to its specification. > > --Randy > > At 6:24 AM +0000 8/15/16, Christer Holmberg wrote: > >> Hi, >> >> I don't know what is meant by "secondary mechanism". When you use INFO, >> there is one, only one, and nothing but one mechanism - info package. >> >> Whether INFO as such is only used in a subset of calls doesn't really >> matter. WHEN it's used, it has to be used as specified. >> >> Regards, >> >> Christer >> >> >> On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens" >> wrote: >> >>>Hi Keith, >>> >>>The main aspect is sending data in INVITE and the response. Using >>>INFO is a secondary mechanism that is only used in a subset of calls. >>>So, we have use the RFC 7852 mechanism. When we use INFO, use still >>>use RFC 7852, with additional aspects to comply with rules for using >>>INFO. >>> >>>--Randy >>> >>>At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: >>> >>>> To be honest, I believe you are making what you desire fit the INFO >>>> mechanism where it touchs, thus you have a concept of making >>>> something look like Info, but which is not actually specified >>>> according to RFC 6086. >>>> >>>> Ecrit does not need to provide procedures that are already in RFC >>>> 6086, so all it needs to say is that the xxx info package is >>>> mandatory for support on all ecrit calls in accordance with RFC >>>> 6086, and that covers the package negotiation. >>>> >>>> Further I do not believe you need to add to the Info usage with add >>>> ons that only seem to be there because they were in the previous >>>> version of your document, and are irrelevant for correct operation, >>>> such as the usage of a Call-Info header field. They lead to future >>>> deployment and interoperability problems which noone needs on an >>>> emergency call. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Randall Gellens >>>> [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 11 August 2016 18:51 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>ecrit@ietf.org >>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Keith, >>>> >>>> Yes, we agreed that the draft would define and use an INFO package >>>> registration, and it does so. My point is that the endpoints >>>> aren't relying on INFO package negotiation, they are compliant with >>>> the spec. It's a subtle difference, and not one observable "on the >>>> wire." There is an INFO package registration, and the draft >>>> requires compliance with INFO RFC. So, all is good. >>>> >>>> --Randy >>>> >>>> At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: > >>> >>>>> I fundamentally cannot agree to this statement. >>>>> >>>>> I thought we had agreed that the INFO package would be used, and this >>>>> statement is absolutely denying that. >>>>> >>>>> Chairs, please intervene with your understanding of the current >>>>>consensus. >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Randall Gellens >>>>> [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 10 August 2016 22:39 >>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>> ecrit@ietf.org >>>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> In reality, there is no separate INFO package negotiation. The >>>>> endpoints support the data types not because they support the iNFO >>>>> package, but rather they support the INFO package and the data types >> >>> and Call-Info because they comply with the draft. >>>>> >>>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> >>>>>> I disagree. >>>>>> >>>>>> The inclusion of the data element in INFO is nothing to do with >>>>>>RFC >>>>>> 7852. The data element is included because the use of an appropriate >>>>>> Info package has been negotiated and used. That Info package >>>>>> definition and the INFO mechanism itself makes no mention of use of >>>>>> Call-Info in association with it. >>>>>> >>>>>> Further I see no justification for complicating any error handling >>>>>> by suddenly defining it to be applicable, as it is not necessary. >>>>>> INFO requests always contain a data element appropriate to the Info >>>>>> package that is defined for its use - it absolutely does not need a >>>>>> secondary reference to the package. >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>> >> From: Randall Gellens >>>> [mailto:rg+ietf@randy.pensive.org] >>>>>> Sent: 10 August 2016 18:20 >>>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>>> ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>>not >>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> >> usage brings no value) >>>>>> >>>>>> Hi Keith, >>>>>> >>>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>>> >>>>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>>> RFC7852 then I have to agree with Ivo. That additional usage is not >>>>>>> currently defined in draft-ietf-ecrit-ecall, and I would need to >>>>>>> understand that usage before it is included. >>>>>>> >>>>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>>> INVITE requests and 200 (OK) responses, and therefore that is the >>>>>>> only place where it should appear in association with RFC7852. >>>>>> >>>>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>>>> blocks in any SIP message that is permitted to carry a body. >>>>>> >>>>>>> >>>>>>> Negotiation and transfer of MSD in association with INFO >>>>>>>requests >>>>>>> is an entirely separate transfer mechanism, not covered by >>>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>>>> there as though it had been. Inclusion will lead to complete >>>>>>> confusion as to whether the requirements of the INFO mechanism or >>>>>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>>> should be absolutely clear that only the former apply. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ecrit >>>>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>> On Behalf Of Ivo >>>>>>> Sedlacek >>>>> >> Sent: 10 August 2016 08:41 >>>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>>> Call-Info usage brings no value) > >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>>> The invite response still has a body with content-disposition >>>>>>>> by-reference. If you remove the reference then its processing is >>>>>>>> undefined. >>>>>>> >>>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>>> Alt1: a new value could be defined and used in the >>>>>>> Content-Disposition header field of the >>>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>>> or >>>>>>> Alt2: an existing value could be used in the Content-Disposition >>>>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>>>> body; >>>>>>> or >>>>>>> Alt3: the Content-Disposition header field can be omitted and >>>>>>>thus >>>>>>> "render" would apply for the >>>>>>> application/emergencyCallData.eCall.control+xml body according to >>>>>>> RFC3261 section 13.2.1. >>>>>>> >>>>>>> We cannot use the Call-Info in INVITE response as described in >>>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>>>request, >>>>>>> the Call-Info points to the >>>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>>> > contains a delivery report for the MSD sent in INVITE request. >> >>>> This is >>>>>>> NOT information about callee as described in RFC3261. >> >>>>> >>>>>>> Kind regards >>>>>>> >>>>>>> Ivo >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for myself >>>>>>only >>>>>> -------------- Randomly selected tag: --------------- The idea >>>>>>that >>>>>> Bill Gates has appeared like a knight in shining armor to lead all >>>>>> customers out of a mire of technological chaos neatly ignores the >>>>>> fact that it was he who, by peddling second-rate technology, >>>>>> led them into it in the first place. --Douglas >>>>>>Adams >>>>> >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself >>>>>only >>>>> -------------- Randomly selected tag: --------------- Einstein never >>>> > accepted quantum mechanics because of this element of chance and >>>>> uncertainty. He said, "God does not play dice." >>>>> It seems that Einstein was doubly wrong. The quantum effects of black >>>>> holes suggests that not only does God play dice, He sometimes throws >>>>> them where they cannot be seen. --Steven Hawking >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- It is very >>>> dangerous to be right when the established authorities >>>> are wrong. --Voltaire >>> >>> >>>-- >>>Randall Gellens >>>Opinions are personal; facts are suspect; I speak for myself only >>>-------------- Randomly selected tag: --------------- >>>Misery loves company, but company does not reciprocate. >>> >>>_______________________________________________ >>>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: --------------- > Gossip is when you hear something you like about someone you don't. > --Earl Wilson -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have learned To spell hors d'oeuvres Which still grates on Some people's n'oeuvres. -- Warren Knox From nobody Mon Aug 15 03:39:47 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 6A3B512D916 for ; Mon, 15 Aug 2016 03:39:46 -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 aRio3Mrseh7K for ; Mon, 15 Aug 2016 03:39:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 CDE5212D90F for ; Mon, 15 Aug 2016 03:39:41 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-27-57b19bec5622 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id F2.34.02493.CEB91B75; Mon, 15 Aug 2016 12:39:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 12:39:38 +0200 From: Christer Holmberg To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "Paul Kyzivat" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR9uAwbfI3tvs7YUa0YQSg9pSJJaBJ5r4A Date: Mon, 15 Aug 2016 10:39:38 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC05DB1@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.5.160527 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+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7hO6b2RvDDW7OErBoXPSU1WLDluMs Fis2HGC1+P68i9GBxePv+w9MHkuW/GTyuHvrEpPH1juPWQJYorhsUlJzMstSi/TtErgynk3p ZSx4nFXxc0YncwPj2pAuRk4OCQETiU/9dxm7GLk4hATWM0pMXdzFDOEsYZS48/oQaxcjBweb gIVE9z9tkLiIwH1GiT3TzzGBdAsLLGWUaDksBpFYxiix+8khFpCEiICRRNf0z4wgNouAqsS0 tuesIDavgJXE5R2tUOt62SQWPn4AtoETqOHQLUGQGkYBMYnvp9aALWAWEJe49WQ+E8SpAhJL 9pxnhrBFJV4+/gc2U1RAT+L719nMIGMkBJQkpm1Ng2jVkViw+xMbhG0t8ffNCxYIW1ti2cLX zBDnCEqcnPmEZQKj2Cwk22YhaZ+FpH0WkvZZSNoXMLKuYhQtTi0uzk03MtJLLcpMLi7Oz9PL Sy3ZxAiMwINbflvtYDz43PEQowAHoxIP74KNG8KFWBPLiitzDzFKcDArifD2Td4YLsSbklhZ lVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTChiPJ9mj61dk9zd//XSV fSmnZjDLq/VeZrnfzhrZm/or+3EnMoSoPM2OZ+1S7xD2+Li4877j/mWlNSoG8w/XC13Uay1e s6zb9ZUz5zVJN+/AEzLLk5lWusnkxZx+ub5acFfM1BkLp+0zeTbHxDjP/tgFn5ZIyX1FueWv 9ApKegNrZD85z617p8RSnJFoqMVcVJwIAGWxwPq8AgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 10:39:46 -0000 Hi, The mechanisms are not consistent, and just adding a Call-Info header is not going to make them consistent. Regards, Christer On 15/08/16 13:31, "Randall Gellens" wrote: >Hi Christer, > >Yes, we want the mechanism to be consistent. > >--Randy > >At 9:33 AM +0000 8/15/16, Christer Holmberg wrote: > >> Hi, >> >> No, but you also want to somehow mix it with other mechanisms >> (well, parts of other mechanisms, actually). >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> >> From: Randall Gellens >> Sent: 15/08/2016 12:16 >> To: Christer Holmberg; >> Drage, Keith (Nokia - GB); >> Ivo Sedlacek; >> Paul Kyzivat; >> ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >> usage brings no value) >> >> Hi Christer, >> >> I don't think anyone is suggesting that INFO be used without >> conforming to its specification. >> >> --Randy >> >> At 6:24 AM +0000 8/15/16, Christer Holmberg wrote: >> >>> Hi, >>> >>> I don't know what is meant by "secondary mechanism". When you use >>>INFO, >>> there is one, only one, and nothing but one mechanism - info package. >>> >>> Whether INFO as such is only used in a subset of calls doesn't really >>> matter. WHEN it's used, it has to be used as specified. >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens" >>> >>>wrote: >>> >>>>Hi Keith, >>>> >>>>The main aspect is sending data in INVITE and the response. Using >>>>INFO is a secondary mechanism that is only used in a subset of calls. >>>>So, we have use the RFC 7852 mechanism. When we use INFO, use still >>>>use RFC 7852, with additional aspects to comply with rules for using >>>>INFO. >>>> >>>>--Randy >>>> >>>>At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> To be honest, I believe you are making what you desire fit the >>>>>INFO >>>>> mechanism where it touchs, thus you have a concept of making >>>>> something look like Info, but which is not actually specified >>>>> according to RFC 6086. >>>>> >>>>> Ecrit does not need to provide procedures that are already in RFC >>>>> 6086, so all it needs to say is that the xxx info package is >>>>> mandatory for support on all ecrit calls in accordance with RFC >>>>> 6086, and that covers the package negotiation. >>>>> >>>>> Further I do not believe you need to add to the Info usage with >>>>>add >>>>> ons that only seem to be there because they were in the previous >>>>> version of your document, and are irrelevant for correct operation, >>>>> such as the usage of a Call-Info header field. They lead to future >>>>> deployment and interoperability problems which noone needs on an >>>>> emergency call. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Randall Gellens >>>>> [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 11 August 2016 18:51 >>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>>ecrit@ietf.org >>>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hi Keith, >>>>> >>>>> Yes, we agreed that the draft would define and use an INFO package >>>>> registration, and it does so. My point is that the endpoints >>>>> aren't relying on INFO package negotiation, they are compliant with >>>>> the spec. It's a subtle difference, and not one observable "on the >>>>> wire." There is an INFO package registration, and the draft >>>>> requires compliance with INFO RFC. So, all is good. >>>>> >>>>> --Randy >>>>> >>>>> At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote: >> >>> >>>>>> I fundamentally cannot agree to this statement. >>>>>> >>>>>> I thought we had agreed that the INFO package would be used, >>>>>>and this >>>>>> statement is absolutely denying that. >>>>>> >>>>>> Chairs, please intervene with your understanding of the current >>>>>>consensus. >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>>>> From: Randall Gellens >>>>>> [mailto:rg+ietf@randy.pensive.org] >>>>>> Sent: 10 August 2016 22:39 >>>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>>> ecrit@ietf.org >>>>>> Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>>not >>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>>Call-Info >>>>>> usage brings no value) >>>>>> >>>>>> In reality, there is no separate INFO package negotiation. The >>>>>> endpoints support the data types not because they support the >>>>>>iNFO >>>>>> package, but rather they support the INFO package and the data >>>>>>types >>> >>> and Call-Info because they comply with the draft. >>>>>> >>>>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>> >>>>>>> I disagree. >>>>>>> >>>>>>> The inclusion of the data element in INFO is nothing to do >>>>>>>with >>>>>>>RFC >>>>>>> 7852. The data element is included because the use of an >>>>>>>appropriate >>>>>>> Info package has been negotiated and used. That Info package >>>>>>> definition and the INFO mechanism itself makes no mention of >>>>>>>use of >>>>>>> Call-Info in association with it. >>>>>>> >>>>>>> Further I see no justification for complicating any error >>>>>>>handling >>>>>>> by suddenly defining it to be applicable, as it is not >>>>>>>necessary. >>>>>>> INFO requests always contain a data element appropriate to the >>>>>>>Info >>>>>>> package that is defined for its use - it absolutely does not >>>>>>>need a >>>>>>> secondary reference to the package. >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> -----Original Message----- >>>>> >> From: Randall Gellens >>>>> [mailto:rg+ietf@randy.pensive.org] >>>>>>> Sent: 10 August 2016 18:20 >>>>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>>>> ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info >>>>>>>usage >>>>>>>not >>>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>>>Call-Info >>>>> >> usage brings no value) >>>>>>> >>>>>>> Hi Keith, >>>>>>> >>>>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>>>> >>>>>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>>>> RFC7852 then I have to agree with Ivo. That additional usage >>>>>>>>is not >>>>>>>> currently defined in draft-ietf-ecrit-ecall, and I would need >>>>>>>>to >>>>>>>> understand that usage before it is included. >>>>>>>> >>>>>>>> At the moment RFC7852 is only used for the transfer of MSD >>>>>>>>in >>>>>>>> INVITE requests and 200 (OK) responses, and therefore that is >>>>>>>>the >>>>>>>> only place where it should appear in association with RFC7852. >>>>>>> >>>>>>> RFC 7852 covers use of Call-Info to point to emergency call >>>>>>>data >>>>>>> blocks in any SIP message that is permitted to carry a body. >>>>>>> >>>>>>>> >>>>>>>> Negotiation and transfer of MSD in association with INFO >>>>>>>>requests >>>>>>>> is an entirely separate transfer mechanism, not covered by >>>>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never >>>>>>>>appear >>>>>>>> there as though it had been. Inclusion will lead to complete >>>>>>>> confusion as to whether the requirements of the INFO >>>>>>>>mechanism or >>>>>>>> the requirements of draft-ietf-ecrit-data-only-ea apply, when >>>>>>>>it >>>>>>>> should be absolutely clear that only the former apply. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ecrit >>>>>>>> [mailto:ecrit-bounces@ietf.org] >>>>>>>> On Behalf Of Ivo >>>>>>>> Sedlacek >>>>>> >> Sent: 10 August 2016 08:41 >>>>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info >>>>>>>>usage >>>>>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>>>> Call-Info usage brings no value) >> >>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>>> The invite response still has a body with >>>>>>>>>content-disposition >>>>>>>>> by-reference. If you remove the reference then its processing >>>>>>>>>is >>>>>>>>> undefined. >>>>>>>> >>>>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>>>> Alt1: a new value could be defined and used in the >>>>>>>> Content-Disposition header field of the >>>>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>>>> or >>>>>>>> Alt2: an existing value could be used in the >>>>>>>>Content-Disposition >>>>>>>> header field of the >>>>>>>>application/emergencyCallData.eCall.control+xml >>>>>>>> body; >>>>>>>> or >>>>>>>> Alt3: the Content-Disposition header field can be omitted >>>>>>>>and >>>>>>>>thus >>>>>>>> "render" would apply for the >>>>>>>> application/emergencyCallData.eCall.control+xml body >>>>>>>>according to >>>>>>>> RFC3261 section 13.2.1. >>>>>>>> >>>>>>>> We cannot use the Call-Info in INVITE response as described >>>>>>>>in >>>>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>>>>request, >>>>>>>> the Call-Info points to the >>>>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>>>> > contains a delivery report for the MSD sent in INVITE >>>>>>>request. >>> >>>> This is >>>>>>>> NOT information about callee as described in RFC3261. >>> >>>>> >>>>>>>> Kind regards >>>>>>>> >>>>>>>> Ivo >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>https://www.ietf.org/m >>>>>>>>ailman/listinfo/ecrit >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>https://www.ietf.org/m >>>>>>>>ailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Randall Gellens >>>>>>> Opinions are personal; facts are suspect; I speak for >>>>>>>myself >>>>>>>only >>>>>>> -------------- Randomly selected tag: --------------- The idea >>>>>>>that >>>>>>> Bill Gates has appeared like a knight in shining armor to lead >>>>>>>all >>>>>>> customers out of a mire of technological chaos neatly ignores >>>>>>>the >>>>>>> fact that it was he who, by peddling second-rate technology, >>>>>>> led them into it in the first place. >>>>>>>--Douglas >>>>>>>Adams >>>>>> >>>>>> >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for >>>>>>myself >>>>>>only >>>>>> -------------- Randomly selected tag: --------------- Einstein >>>>>>never >>>>> > accepted quantum mechanics because of this element of chance >>>>>and >>>>>> uncertainty. He said, "God does not play dice." >>>>>> It seems that Einstein was doubly wrong. The quantum effects of >>>>>>black >>>>>> holes suggests that not only does God play dice, He sometimes >>>>>>throws >>>>>> them where they cannot be seen. --Steven Hawking >>>>> >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for >>>>>myself only >>>>> -------------- Randomly selected tag: --------------- It is very >>>>> dangerous to be right when the established authorities >>>>> are wrong. --Voltaire >>>> >>>> >>>>-- >>>>Randall Gellens >>>>Opinions are personal; facts are suspect; I speak for myself only >>>>-------------- Randomly selected tag: --------------- >>>>Misery loves company, but company does not reciprocate. >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www.ietf.org/mailm >>>>an/listinfo/ecrit >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> Gossip is when you hear something you like about someone you don't. >> --Earl Wilson > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >I have learned >To spell hors d'oeuvres >Which still grates on >Some people's n'oeuvres. > -- Warren Knox From nobody Mon Aug 15 03:45: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 6362512D984 for ; Mon, 15 Aug 2016 03:44:59 -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 vTTLXG_lFZ6Q for ; Mon, 15 Aug 2016 03:44:57 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3EAEF12D981 for ; Mon, 15 Aug 2016 03:44:57 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-fa-57b19d26bb95 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 9A.E3.02553.62D91B75; Mon, 15 Aug 2016 12:44:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 12:44:54 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) Thread-Index: AdHz2FwLK9oifeXtSM6h5CNhXHCw5f//7SkAgAHl/4CABFIWgA== Date: Mon, 15 Aug 2016 10:44:53 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164C4437@ESESSMB301.ericsson.se> <3b670133-e961-9554-c857-5861733947fd@alum.mit.edu> 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.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3B4F3D2F4B387D4A80CBB6B9C691E29B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7q6763I3hBk+eaVk0LnrKarFiwwFW i+/PuxgdmD3+vv/A5LFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZcxdZ16wVKjiwqpe5gbG 13xdjJwcEgImEod2tLJ2MXJxCAmsZ5TYungDE4SzhFFi7ZvNbF2MHBxsAhYS3f+0QRpEBKok Pp27zwZSIyzQwyixaM5tZohEL6NEzwVuCNtJYvf8O2BxFgFVidnbvrKD2LwCVhKTdsyEWrCG UeJCz2MmkASngLHEy9eT2UBsRgExie+n1oDFmQXEJW49mc8EcaqAxJI955khbFGJl4//sYLY ogJ6Et+/zmYGOVRCQEli2tY0iFY9iRtTp7BB2NYST079YoawtSWWLXzNDHGPoMTJmU9YJjCK zUKybRaS9llI2mchaZ+FpH0BI+sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMBYO7jlt8EO xpfPHQ8xCnAwKvHwLti4IVyINbGsuDL3EKMEB7OSCG/f5I3hQrwpiZVVqUX58UWlOanFhxil OViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhi9FFS/ngp2sFi74Ofa8DKTKBsFx7QfPkxz 9FmOxQou2HHngswK16mGx4/N2i93RW3O8un25cfzt++sbU0161v25eOc+v5zbLM9NliK7Gf7 xB9T0vbHd/vHZKcmxlnxUc4zbWYlPps463NRXVKEfVqHWV5z3kTz6UnhF+MMawxb5r7Nvb9B dr0SS3FGoqEWc1FxIgCkMPXcsQIAAA== Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Content-ID cannot be included when SIP message has solely one body (i.e. no multipart/...) 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, 15 Aug 2016 10:44:59 -0000 Hi, I think it=B9s better to do it in a separate SIPCORE draft, as it=B9s also needed for non-ECRIT cases. Regards, Christer On 12/08/16 22:49, "Ecrit on behalf of Randall Gellens" wrote: >Seems like RFC 7852 should have added Content-ID as a SIP header. > >At 10:50 AM -0400 8/11/16, Paul Kyzivat wrote: > >> Hmm. Interesting issue. >> >> ISTM the proper solution to that is to define Content-ID as a SIP >> header field. >> >> Of course a work-around is to add a multipart wrapper to the single >> body part. But that shouldn't be necessary. >> >> Thanks, >> Paul >> >> On 8/11/16 10:04 AM, Ivo Sedlacek wrote: >>> Hello, >>> >>> I found another potential issue. >>> >>> If a SIP message contains solely one body (i.e. not >>> multipart/mixed body), then the SIP message cannot contain a >>> Content-ID header field. >>> >>> Content-ID header field is NOT a SIP header field - Content-ID >>> cannot be found in in RFC3261 and Content-ID cannot be found in >>>=20 >>>http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip- >>>parameters-2 >>> Content-ID header field is a MIME multipart/mixed header field. >>> >>> Also, rfc5621 states: >>> ------------ >>> Content-ID URLs allow creating references to body *parts*. >>> ------------ >>> >>> Thus, Figure 10, and Figure 11 (and related procedures) of >>> draft-ietf-ecrit-ecall-11 use a header field (Content-ID header >>> field) not defined in SIP. >>> >>> Kind regards >>> >>> Ivo >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >Associate yourself with people of good quality, for it is better to be >alone than in bad company. --Booker T. Washington > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 15 12:29: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 D7DBD12D500 for ; Mon, 15 Aug 2016 12:29:49 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 zBQlwBP0s05w for ; Mon, 15 Aug 2016 12:29:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E99E312D135 for ; Mon, 15 Aug 2016 12:29:47 -0700 (PDT) Received: from [10.79.0.197] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 12:29:46 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Mon, 15 Aug 2016 12:23:02 -0700 To: Paul Kyzivat , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" , Brian Rosen 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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 19:29:50 -0000 Hi Paul, The draft says that when data is sent in INFO, the body part's Content-Disposition is set to "Info-Package" (to be compliant with the INFO spec). Content-Disposition was created a long time ago to bring some order to the wild and wooly world of body parts. Content-Disposition allows an implementation that receives a random body part to have some idea of what to do with it even if it doesn't understand it. In our case, we're dealing with a limited usage where the end points are conformant to the spec and understand the eCall MSD (or VEDS for car-crash) or metadata/control body part. They don't need the Content-Disposition value for guidance. So, I don't see any conflict with using "Info-Package" when the data arrives via INFO and "by-reference" in other cases. Call-Info identifies the data type, and this is the same regardless of how the data arrives. --Randy At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: > On 8/10/16 5:38 PM, Randall Gellens wrote: >> In reality, there is no separate INFO package negotiation. The >> endpoints support the data types not because they support the iNFO >> package, but rather they support the INFO package and the data types and >> Call-Info because they comply with the draft. > > You can't do that without violating something. > > For one thing, when using INFO packages the body part that is the > info package must have a content-disposition of "Info-Package". But > for the ecall usage the body part must have a content-disposition > of "by-reference". > > Thanks, > Paul > >> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> I disagree. >>> >>> The inclusion of the data element in INFO is nothing to do with RFC >>> 7852. The data element is included because the use of an appropriate >>> Info package has been negotiated and used. That Info package >>> definition and the INFO mechanism itself makes no mention of use of >>> Call-Info in association with it. >>> >>> Further I see no justification for complicating any error handling by >>> suddenly defining it to be applicable, as it is not necessary. INFO >>> requests always contain a data element appropriate to the Info package >>> that is defined for its use - it absolutely does not need a secondary >>> reference to the package. >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 18:20 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>> usage brings no value) >>> >>> Hi Keith, >>> >>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>>> then I have to agree with Ivo. That additional usage is not currently >>>> defined in draft-ietf-ecrit-ecall, and I would need to understand that >>>> usage before it is included. >>>> >>>> At the moment RFC7852 is only used for the transfer of MSD in INVITE >>>> requests and 200 (OK) responses, and therefore that is the only place >>>> where it should appear in association with RFC7852. >>> >>> RFC 7852 covers use of Call-Info to point to emergency call data >>> blocks in any SIP message that is permitted to carry a body. >>> >>>> >>>> Negotiation and transfer of MSD in association with INFO requests is >>>> an entirely separate transfer mechanism, not covered by >>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>> there as though it had been. Inclusion will lead to complete confusion >>>> as to whether the requirements of the INFO mechanism or the >>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be >>>> absolutely clear that only the former apply. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek >>>> Sent: 10 August 2016 08:41 >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hello, >>>> >>>>> The invite response still has a body with content-disposition >>>>> by-reference. If you remove the reference then its processing is >>>>> undefined. >>>> >>>> If the Call-Info is omitted in INVITE response, then: >>>> Alt1: a new value could be defined and used in the >>>> Content-Disposition header field of the >>>> application/emergencyCallData.eCall.control+xml body; >>>> or >>>> Alt2: an existing value could be used in the Content-Disposition >>>> header field of the application/emergencyCallData.eCall.control+xml >>>> body; >>>> or >>>> Alt3: the Content-Disposition header field can be omitted and thus >>>> "render" would apply for the >>>> application/emergencyCallData.eCall.control+xml body according to >>>> RFC3261 section 13.2.1. >>>> >>>> We cannot use the Call-Info in INVITE response as described in >>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the >>>> Call-Info points to the >>>> application/emergencyCallData.eCall.control+xml body. This body >>> > contains a delivery report for the MSD sent in INVITE request. >>> This is >>>> NOT information about callee as described in RFC3261. >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- The idea that >>> Bill Gates has appeared like a knight in shining armor to lead all >>> customers out of a mire of technological chaos neatly ignores the fact >>> that it was he who, by peddling second-rate technology, >>> led them into it in the first place. --Douglas Adams -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Who tells the stories of a culture really governs human behavior. It used to be the parent, the school, the church, the community. Now it's a handful of global conglomerates that have nothing to tell, but a great deal to sell. --George Gerbner, dean of Annenberg School of Communication From nobody Mon Aug 15 12:57:02 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 98CB912D76B for ; Mon, 15 Aug 2016 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 hpl9JAQjzFGq for ; Mon, 15 Aug 2016 12:56:59 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id CA9F812D768 for ; Mon, 15 Aug 2016 12:56:58 -0700 (PDT) X-AuditID: 12074412-1c3ff70000000931-76-57b21e897140 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 94.51.02353.98E12B75; Mon, 15 Aug 2016 15:56:57 -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 u7FJus6j010289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Aug 2016 15:56:55 -0400 To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" , Brian Rosen References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> From: Paul Kyzivat Message-ID: <6f18e9cf-d1f1-ad53-8091-b50705d3f70e@alum.mit.edu> Date: Mon, 15 Aug 2016 15:56:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqNsptync4MdhK4tpJy8zWzQuespq 0btyHqvFhi3HWSy+P+9idGD1+PX1KpvHkiU/mTx2NDxn9rh76xKTx9Y7j1kCWKO4bFJSczLL Uov07RK4Mg7OW8pecNO5Yu2jmawNjIdMuxg5OSQETCS+bFjPDGILCWxllOi/W9fFyAVkP2WS WLyglxUkISywkFHiwgMRkISIwB9GiTNv3jJCVC1hk1iz6zRYO5uAlsScQ/9ZQGxeAXuJeZcO g8VZBFQlXq7oBpskKpAmMf1wPyNEjaDEyZlPwOo5BYwk9rX+BLOZBWwl7szdzQxhy0tsfzuH eQIj3ywkLbOQlM1CUraAkXkVo1xiTmmubm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRkjg Cu1gXH9S7hCjAAejEg/vCYZN4UKsiWXFlbmHGCU5mJREeWdO3BguxJeUn1KZkVicEV9UmpNa fIhRgoNZSYSXTwaonDclsbIqtSgfJiXNwaIkzvtzsbqfkEB6YklqdmpqQWoRTFaGg0NJgpcZ GKFCgkWp6akVaZk5JQhpJg5OkOE8QMNfy4IMLy5IzC3OTIfIn2JUlBLn/QiSEABJZJTmwfXC EssrRnGgV4R5H4JU8QCTElz3K6DBTECD9aU3gAwuSURISTUwaq+y2hhyyEToDmfKfMHEU9IV Fh6XNdvkNvpurHrBu/7Bt3rx19uPdm8xSd33QetC9As2P+lS75x7fCGeBz7O3211ewVb9eLS KvU15/bNX/bmwFk+mTbTM/e8FxcrLf71ujl7T0lzVc67pT88Vq/SbmLVUHuV/cy28OC71Brz 1C5L16dLlB15lViKMxINtZiLihMBt77GagcDAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 19:57:02 -0000 On 8/15/16 3:23 PM, Randall Gellens wrote: > Hi Paul, > > The draft says that when data is sent in INFO, the body part's > Content-Disposition is set to "Info-Package" (to be compliant with the > INFO spec). The examples show that. But I don't find any text saying to do that. And if there was, it would seem to be in conflict with RFC7852: ... The 'by-reference' disposition type of RFC 5621 [RFC5621] allows a SIP message to contain a reference to the body part, and the SIP User Agent (UA) processes the body part according to the reference. This is the case for a Call-Info header field containing a CID URL. It isn't entirely clear if this was intended to be normative or not. > Content-Disposition was created a long time ago to bring > some order to the wild and wooly world of body parts. I know. I was actively involved. > Content-Disposition allows an implementation that receives a random body > part to have some idea of what to do with it even if it doesn't > understand it. In our case, we're dealing with a limited usage where > the end points are conformant to the spec and understand the eCall MSD > (or VEDS for car-crash) or metadata/control body part. They don't need > the Content-Disposition value for guidance. So, I don't see any > conflict with using "Info-Package" when the data arrives via INFO and > "by-reference" in other cases. Call-Info identifies the data type, and > this is the same regardless of how the data arrives. When you say this you constrain how implementation can be done. It should be possible to build a sip stack that has generic logic for processing bodies and body parts. For each body part it then needs to figure out what it is that governs what determines how each part is to be processed. This is complicated, especially since both Content-Type and Content-Disposition are themselves optional, and the defaults when they aren't present are context sensitive. You have introduced an ambiguity about whether the processing of this body part is governed by a "handler" for the info-package, or by a handler for the call-info header. Perhaps this won't be a problem - maybe they will both handle it. But it is ill-defined. The alternative is that there is no general framework for this - that special code, driven by the specific R-URI, handles all the body handling. If you do this the result is likely to be very fragile. E.g., it might break if there happens to be another body part present for some orthogonal feature of the request. (Perhaps there is another call-info with a different purpose, with another cid: referencing another body part. This could arise based on STIR.) Thanks, Paul > --Randy > > At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: > >> On 8/10/16 5:38 PM, Randall Gellens wrote: >>> In reality, there is no separate INFO package negotiation. The >>> endpoints support the data types not because they support the iNFO >>> package, but rather they support the INFO package and the data types >>> and >>> Call-Info because they comply with the draft. >> >> You can't do that without violating something. >> >> For one thing, when using INFO packages the body part that is the >> info package must have a content-disposition of "Info-Package". But >> for the ecall usage the body part must have a content-disposition of >> "by-reference". >> >> Thanks, >> Paul >> >>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> I disagree. >>>> >>>> The inclusion of the data element in INFO is nothing to do with RFC >>>> 7852. The data element is included because the use of an appropriate >>>> Info package has been negotiated and used. That Info package >>>> definition and the INFO mechanism itself makes no mention of use of >>>> Call-Info in association with it. >>>> >>>> Further I see no justification for complicating any error handling by >>>> suddenly defining it to be applicable, as it is not necessary. INFO >>>> requests always contain a data element appropriate to the Info package >>>> that is defined for its use - it absolutely does not need a secondary >>>> reference to the package. >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 10 August 2016 18:20 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Keith, >>>> >>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>>>> then I have to agree with Ivo. That additional usage is not >>>>> currently >>>>> defined in draft-ietf-ecrit-ecall, and I would need to understand >>>>> that >>>>> usage before it is included. >>>>> >>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>> INVITE >>>>> requests and 200 (OK) responses, and therefore that is the only >>>>> place >>>>> where it should appear in association with RFC7852. >>>> >>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>> blocks in any SIP message that is permitted to carry a body. >>>> >>>>> >>>>> Negotiation and transfer of MSD in association with INFO >>>>> requests is >>>>> an entirely separate transfer mechanism, not covered by >>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>> there as though it had been. Inclusion will lead to complete >>>>> confusion >>>>> as to whether the requirements of the INFO mechanism or the >>>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>> should be >>>>> absolutely clear that only the former apply. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>> Sedlacek >>>>> Sent: 10 August 2016 08:41 >>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hello, >>>>> >>>>>> The invite response still has a body with content-disposition >>>>>> by-reference. If you remove the reference then its processing is >>>>>> undefined. >>>>> >>>>> If the Call-Info is omitted in INVITE response, then: >>>>> Alt1: a new value could be defined and used in the >>>>> Content-Disposition header field of the >>>>> application/emergencyCallData.eCall.control+xml body; >>>>> or >>>>> Alt2: an existing value could be used in the Content-Disposition >>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>> body; >>>>> or >>>>> Alt3: the Content-Disposition header field can be omitted and thus >>>>> "render" would apply for the >>>>> application/emergencyCallData.eCall.control+xml body according to >>>>> RFC3261 section 13.2.1. >>>>> >>>>> We cannot use the Call-Info in INVITE response as described in >>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>> request, the >>>>> Call-Info points to the >>>>> application/emergencyCallData.eCall.control+xml body. This body >>>> > contains a delivery report for the MSD sent in INVITE request. >>>> This is >>>>> NOT information about callee as described in RFC3261. >>>>> >>>>> Kind regards >>>>> >>>>> Ivo >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>> only >>>> -------------- Randomly selected tag: --------------- The idea that >>>> Bill Gates has appeared like a knight in shining armor to lead all >>>> customers out of a mire of technological chaos neatly ignores the fact >>>> that it was he who, by peddling second-rate technology, >>>> led them into it in the first place. --Douglas >>>> Adams > > From nobody Mon Aug 15 14:05:57 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 1A6C312D13F for ; Mon, 15 Aug 2016 14:05:55 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 E6pcpxyec8g6 for ; Mon, 15 Aug 2016 14:05:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 87F4412B02A for ; Mon, 15 Aug 2016 14:05:50 -0700 (PDT) Received: from [10.79.0.197] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 15 Aug 2016 14:05:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <6f18e9cf-d1f1-ad53-8091-b50705d3f70e@alum.mit.edu> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <6f18e9cf-d1f1-ad53-8091-b50705d3f70e@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Mon, 15 Aug 2016 14:05:44 -0700 To: Paul Kyzivat , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" , Brian Rosen 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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 21:05:55 -0000 Hi Paul, Thanks for clarifying your point/concern. I now understand the issue better, and am discussing possible solutions with Brian. We'll send an update to the list. By the way, the text does explicitly say in Section 6: When data is being carried in an INFO request message, the body part also carries a Content-Disposition header field set to "Info- Package". --Randy At 3:56 PM -0400 8/15/16, Paul Kyzivat wrote: > On 8/15/16 3:23 PM, Randall Gellens wrote: >> Hi Paul, >> >> The draft says that when data is sent in INFO, the body part's >> Content-Disposition is set to "Info-Package" (to be compliant with the >> INFO spec). > > The examples show that. But I don't find any text saying to do that. > > And if there was, it would seem to be in conflict with RFC7852: > > ... The 'by-reference' disposition type of RFC 5621 [RFC5621] > allows a SIP message to contain a reference to the body part, and the > SIP User Agent (UA) processes the body part according to the > reference. This is the case for a Call-Info header field containing > a CID URL. > > It isn't entirely clear if this was intended to be normative or not. > >> Content-Disposition was created a long time ago to bring >> some order to the wild and wooly world of body parts. > > I know. I was actively involved. > >> Content-Disposition allows an implementation that receives a random body >> part to have some idea of what to do with it even if it doesn't >> understand it. In our case, we're dealing with a limited usage where >> the end points are conformant to the spec and understand the eCall MSD >> (or VEDS for car-crash) or metadata/control body part. They don't need >> the Content-Disposition value for guidance. So, I don't see any >> conflict with using "Info-Package" when the data arrives via INFO and >> "by-reference" in other cases. Call-Info identifies the data type, and >> this is the same regardless of how the data arrives. > > When you say this you constrain how implementation can be done. It > should be possible to build a sip stack that has generic logic for > processing bodies and body parts. For each body part it then needs > to figure out what it is that governs what determines how each part > is to be processed. This is complicated, especially since both > Content-Type and Content-Disposition are themselves optional, and > the defaults when they aren't present are context sensitive. > > You have introduced an ambiguity about whether the processing of > this body part is governed by a "handler" for the info-package, or > by a handler for the call-info header. Perhaps this won't be a > problem - maybe they will both handle it. But it is ill-defined. > > The alternative is that there is no general framework for this - > that special code, driven by the specific R-URI, handles all the > body handling. If you do this the result is likely to be very > fragile. E.g., it might break if there happens to be another body > part present for some orthogonal feature of the request. (Perhaps > there is another call-info with a different purpose, with another > cid: referencing another body part. This could arise based on STIR.) > > Thanks, > Paul > >> --Randy >> >> At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: >> >>> On 8/10/16 5:38 PM, Randall Gellens wrote: >>>> In reality, there is no separate INFO package negotiation. The >>>> endpoints support the data types not because they support the iNFO >>>> package, but rather they support the INFO package and the data types >>>> and >>>> Call-Info because they comply with the draft. >>> >>> You can't do that without violating something. >>> >>> For one thing, when using INFO packages the body part that is the >>> info package must have a content-disposition of "Info-Package". But >>> for the ecall usage the body part must have a content-disposition of >>> "by-reference". >>> >>> Thanks, >>> Paul >>> >>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> I disagree. >>>>> >>>>> The inclusion of the data element in INFO is nothing to do with RFC >>>>> 7852. The data element is included because the use of an appropriate >>>>> Info package has been negotiated and used. That Info package >>>>> definition and the INFO mechanism itself makes no mention of use of >>>>> Call-Info in association with it. >>>>> >>>>> Further I see no justification for complicating any error handling by >>>>> suddenly defining it to be applicable, as it is not necessary. INFO >>>>> requests always contain a data element appropriate to the Info package >>>>> that is defined for its use - it absolutely does not need a secondary >>>>> reference to the package. >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 10 August 2016 18:20 >>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hi Keith, >>>>> >>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>> >>>>>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>>>>> then I have to agree with Ivo. That additional usage is not >>>>>> currently >>>>>> defined in draft-ietf-ecrit-ecall, and I would need to understand >>>>>> that >>>>>> usage before it is included. >>>>>> >>>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>> INVITE >>>>>> requests and 200 (OK) responses, and therefore that is the only >>>>>> place >>>>>> where it should appear in association with RFC7852. >>>>> >>>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>>> blocks in any SIP message that is permitted to carry a body. >>>>> >>>>>> >>>>>> Negotiation and transfer of MSD in association with INFO >>>>>> requests is >>>>>> an entirely separate transfer mechanism, not covered by >>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>>> there as though it had been. Inclusion will lead to complete >>>>>> confusion >>>>>> as to whether the requirements of the INFO mechanism or the >>>>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>> should be >>>>>> absolutely clear that only the former apply. >>>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>>> Sedlacek >>>>>> Sent: 10 August 2016 08:41 >>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>>> usage brings no value) >>>>>> >>>>>> Hello, >>>>>> >>>>>>> The invite response still has a body with content-disposition >>>>>>> by-reference. If you remove the reference then its processing is >>>>>>> undefined. >>>>>> >>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>> Alt1: a new value could be defined and used in the >>>>>> Content-Disposition header field of the >>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>> or >>>>>> Alt2: an existing value could be used in the Content-Disposition >>>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>>> body; >>>>>> or >>>>>> Alt3: the Content-Disposition header field can be omitted and thus >>>>>> "render" would apply for the >>>>>> application/emergencyCallData.eCall.control+xml body according to >>>>>> RFC3261 section 13.2.1. >>>>>> >>>>>> We cannot use the Call-Info in INVITE response as described in >>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>> request, the >>>>>> Call-Info points to the >>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>> > contains a delivery report for the MSD sent in INVITE request. >>>>> This is >>>>>> NOT information about callee as described in RFC3261. >>>>>> >>>>>> Kind regards >>>>>> >>>>>> Ivo >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself >>>>> only >>>>> -------------- Randomly selected tag: --------------- The idea that >>>>> Bill Gates has appeared like a knight in shining armor to lead all >>>>> customers out of a mire of technological chaos neatly ignores the fact >>>>> that it was he who, by peddling second-rate technology, >>>>> led them into it in the first place. --Douglas >>>>> Adams -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Every successful person has had failures but repeated failure is no guarantee of eventual success. From nobody Mon Aug 15 14:12:56 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 7698012D1E3 for ; Mon, 15 Aug 2016 14:12:55 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 wxZmbYisK1Sh for ; Mon, 15 Aug 2016 14:12:54 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 2F11112B050 for ; Mon, 15 Aug 2016 14:12:54 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-03v.sys.comcast.net with SMTP id ZPBMbX2oYzd8UZPBlbfFRb; Mon, 15 Aug 2016 21:12:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-08v.sys.comcast.net with SMTP id ZPBkbKhEKOOA6ZPBkbkPo7; Mon, 15 Aug 2016 21:12:53 +0000 To: Randall Gellens , "Drage, Keith (Nokia - GB)" , Ivo Sedlacek , "ecrit@ietf.org" , Brian Rosen References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <6f18e9cf-d1f1-ad53-8091-b50705d3f70e@alum.mit.edu> From: Paul Kyzivat Message-ID: <328258f4-b9d6-35c8-8e27-5ddcc0b3a324@alum.mit.edu> Date: Mon, 15 Aug 2016 17:12:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIvL9/nBJf0fIG1OQjnS7yban2Un/cJ8PKOsO1T8fwCgpqQbvHTg6GXrq76L2SIubcjWrqtrptXDsGBWVpvFBt5UCBwnCdm7uiZiV7OJubcV8mRicVT8 uKmwB7dNL/XV6ummqipcsbB4lacKhMkf1eeo8KleJhcXkX4OnJcxj5itFrrjzHN4zJAeg4onJHajjMT6w30p+RSNh1zJPjB7SGFC67D3iBNQ/83UMQVV1C3/ E0dNLA13Hkrqk7pY2anVOVrSVweTfbdsFHYNl33NFUsNdsek/Y0UijzPBE1r8YrNZik8d+05Zm5rMgAkT4XxuNRf9TGkKqf9r+2LUEKSDvk= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 15 Aug 2016 21:12:55 -0000 On 8/15/16 5:05 PM, Randall Gellens wrote: > Hi Paul, > > Thanks for clarifying your point/concern. I now understand the issue > better, and am discussing possible solutions with Brian. We'll send an > update to the list. By the way, the text does explicitly say in Section 6: > > When data is being carried in an INFO request message, the body part > also carries a Content-Disposition header field set to "Info- > Package". Ah. Then my search for "Info-Package" didn't find this because it was split across lines. :-( Sorry, Paul > --Randy > > At 3:56 PM -0400 8/15/16, Paul Kyzivat wrote: > >> On 8/15/16 3:23 PM, Randall Gellens wrote: >>> Hi Paul, >>> >>> The draft says that when data is sent in INFO, the body part's >>> Content-Disposition is set to "Info-Package" (to be compliant with the >>> INFO spec). >> >> The examples show that. But I don't find any text saying to do that. >> >> And if there was, it would seem to be in conflict with RFC7852: >> >> ... The 'by-reference' disposition type of RFC 5621 [RFC5621] >> allows a SIP message to contain a reference to the body part, and the >> SIP User Agent (UA) processes the body part according to the >> reference. This is the case for a Call-Info header field containing >> a CID URL. >> >> It isn't entirely clear if this was intended to be normative or not. >> >>> Content-Disposition was created a long time ago to bring >>> some order to the wild and wooly world of body parts. >> >> I know. I was actively involved. >> >>> Content-Disposition allows an implementation that receives a random >>> body >>> part to have some idea of what to do with it even if it doesn't >>> understand it. In our case, we're dealing with a limited usage where >>> the end points are conformant to the spec and understand the eCall MSD >>> (or VEDS for car-crash) or metadata/control body part. They don't need >>> the Content-Disposition value for guidance. So, I don't see any >>> conflict with using "Info-Package" when the data arrives via INFO and >>> "by-reference" in other cases. Call-Info identifies the data type, and >>> this is the same regardless of how the data arrives. >> >> When you say this you constrain how implementation can be done. It >> should be possible to build a sip stack that has generic logic for >> processing bodies and body parts. For each body part it then needs to >> figure out what it is that governs what determines how each part is to >> be processed. This is complicated, especially since both Content-Type >> and Content-Disposition are themselves optional, and the defaults when >> they aren't present are context sensitive. >> >> You have introduced an ambiguity about whether the processing of this >> body part is governed by a "handler" for the info-package, or by a >> handler for the call-info header. Perhaps this won't be a problem - >> maybe they will both handle it. But it is ill-defined. >> >> The alternative is that there is no general framework for this - that >> special code, driven by the specific R-URI, handles all the body >> handling. If you do this the result is likely to be very fragile. >> E.g., it might break if there happens to be another body part present >> for some orthogonal feature of the request. (Perhaps there is another >> call-info with a different purpose, with another cid: referencing >> another body part. This could arise based on STIR.) >> >> Thanks, >> Paul >> >>> --Randy >>> >>> At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: >>> >>>> On 8/10/16 5:38 PM, Randall Gellens wrote: >>>>> In reality, there is no separate INFO package negotiation. The >>>>> endpoints support the data types not because they support the iNFO >>>>> package, but rather they support the INFO package and the data types >>>>> and >>>>> Call-Info because they comply with the draft. >>>> >>>> You can't do that without violating something. >>>> >>>> For one thing, when using INFO packages the body part that is the >>>> info package must have a content-disposition of "Info-Package". But >>>> for the ecall usage the body part must have a content-disposition of >>>> "by-reference". >>>> >>>> Thanks, >>>> Paul >>>> >>>>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>> >>>>>> I disagree. >>>>>> >>>>>> The inclusion of the data element in INFO is nothing to do with >>>>>> RFC >>>>>> 7852. The data element is included because the use of an >>>>>> appropriate >>>>>> Info package has been negotiated and used. That Info package >>>>>> definition and the INFO mechanism itself makes no mention of use of >>>>>> Call-Info in association with it. >>>>>> >>>>>> Further I see no justification for complicating any error >>>>>> handling by >>>>>> suddenly defining it to be applicable, as it is not necessary. INFO >>>>>> requests always contain a data element appropriate to the Info >>>>>> package >>>>>> that is defined for its use - it absolutely does not need a >>>>>> secondary >>>>>> reference to the package. >>>>>> >>>>>> Keith >>>>>> >>>>>> -----Original Message----- >>>>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>>> Sent: 10 August 2016 18:20 >>>>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>>>> ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>> not >>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>>> usage brings no value) >>>>>> >>>>>> Hi Keith, >>>>>> >>>>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>>>> >>>>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>>> RFC7852 >>>>>>> then I have to agree with Ivo. That additional usage is not >>>>>>> currently >>>>>>> defined in draft-ietf-ecrit-ecall, and I would need to understand >>>>>>> that >>>>>>> usage before it is included. >>>>>>> >>>>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>>> INVITE >>>>>>> requests and 200 (OK) responses, and therefore that is the only >>>>>>> place >>>>>>> where it should appear in association with RFC7852. >>>>>> >>>>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>>>> blocks in any SIP message that is permitted to carry a body. >>>>>> >>>>>>> >>>>>>> Negotiation and transfer of MSD in association with INFO >>>>>>> requests is >>>>>>> an entirely separate transfer mechanism, not covered by >>>>>>> draft-ietf-ecrit-data-only-ea and therefore it should never >>>>>>> appear >>>>>>> there as though it had been. Inclusion will lead to complete >>>>>>> confusion >>>>>>> as to whether the requirements of the INFO mechanism or the >>>>>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>>> should be >>>>>>> absolutely clear that only the former apply. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>>>> Sedlacek >>>>>>> Sent: 10 August 2016 08:41 >>>>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info >>>>>>> usage not >>>>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>>>>> Call-Info >>>>>>> usage brings no value) >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>>> The invite response still has a body with content-disposition >>>>>>>> by-reference. If you remove the reference then its processing is >>>>>>>> undefined. >>>>>>> >>>>>>> If the Call-Info is omitted in INVITE response, then: >>>>>>> Alt1: a new value could be defined and used in the >>>>>>> Content-Disposition header field of the >>>>>>> application/emergencyCallData.eCall.control+xml body; >>>>>>> or >>>>>>> Alt2: an existing value could be used in the Content-Disposition >>>>>>> header field of the >>>>>>> application/emergencyCallData.eCall.control+xml >>>>>>> body; >>>>>>> or >>>>>>> Alt3: the Content-Disposition header field can be omitted and >>>>>>> thus >>>>>>> "render" would apply for the >>>>>>> application/emergencyCallData.eCall.control+xml body according to >>>>>>> RFC3261 section 13.2.1. >>>>>>> >>>>>>> We cannot use the Call-Info in INVITE response as described in >>>>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE >>>>>>> request, the >>>>>>> Call-Info points to the >>>>>>> application/emergencyCallData.eCall.control+xml body. This body >>>>>> > contains a delivery report for the MSD sent in INVITE request. >>>>>> This is >>>>>>> NOT information about callee as described in RFC3261. >>>>>>> >>>>>>> Kind regards >>>>>>> >>>>>>> Ivo >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for myself >>>>>> only >>>>>> -------------- Randomly selected tag: --------------- The idea >>>>>> that >>>>>> Bill Gates has appeared like a knight in shining armor to lead all >>>>>> customers out of a mire of technological chaos neatly ignores >>>>>> the fact >>>>>> that it was he who, by peddling second-rate technology, >>>>>> led them into it in the first place. --Douglas >>>>>> Adams > > From nobody Mon Aug 15 23:12: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 B72C912D1B7 for ; Mon, 15 Aug 2016 23:12: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 t8LZim1MWuaY for ; Mon, 15 Aug 2016 23:12:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 45BFA12B058 for ; Mon, 15 Aug 2016 23:12:13 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-2b-57b2aebb8281 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 96.6C.04209.BBEA2B75; Tue, 16 Aug 2016 08:12:12 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0301.000; Tue, 16 Aug 2016 08:12:11 +0200 From: Ivo Sedlacek To: Randall Gellens , Paul Kyzivat , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR9ytksuBagQcu4kOGDPlB08UiQaBLGvvA Date: Tue, 16 Aug 2016 06:12:10 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF44F0A@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <949EF20990823C4C85C18D59AA11AD8BADF45136@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7pe6edZvCDTony1lMO3mZ2aJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB5LFnyk8ljR8NzZo+7ty4xeWy985glgDWKyyYlNSez LLVI3y6BK+PQwX6mgvt2FXc77rM0MD4x7GLk5JAQMJFo7zrL1MXIxSEksJ5RYvXr7ywQzhJG iX1PL7OCVLEJ6ElM3HKEFSQhInCDUeL49B1gLcICixkldq1oZYHIALUs/HWREaRFRMBIYsrG FcwgNouAqsS7NRvB4rwCvhKbOs+yQu1gk1iz6zRYESdQw77WnywgNqOArMTVP71gDcwC4hK3 nsxngrhWQGLJnvPMELaoxMvH/1ghbEWJnWfbmSHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gm MIrMQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMKoObvmtuoPx 8hvHQ4wCHIxKPLwKzJvChVgTy4orcw8xSnAwK4nwTloJFOJNSaysSi3Kjy8qzUktPsQozcGi JM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cAorBxdcchjR4pz9kybOSZFzjNnTPw8bW2d1KFC hW3LzJuaVszbenLetUj+hwYTsx047spxh1V5szNUr8p/F9u+4G5q5mtm4VVyjhu4/O4maPHk 6jCYb91mtOh0jH6v44zmSv1Tm3eddnx7U9zT4HBi+uGN8zLqQ2/2PF116XqeoP7fs0GrsnYp sRRnJBpqMRcVJwIA/6Fb06YCAAA= Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 16 Aug 2016 06:12:17 -0000 Hello, > Content-Disposition allows an implementation that receives a random body = part to have some idea of what to do with it even if it doesn't understand = it. =20 As the UE understands the eCall info package, the UE knows the semantic of = the bodies associated (by Content-Disposition: info-package) with the eCall= info package.=20 So, there is no need to have a Call-Info in INFO request. Please remove Call-Info from the INFO request. Kind regards Ivo Sedlacek -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: Monday, August 15, 2016 9:23 PM To: Paul Kyzivat; Drage, Keith (Nokia - GB); Ivo Sedlacek; ecrit@ietf.org; = Brian Rosen Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Paul, The draft says that when data is sent in INFO, the body part's Content-Disp= osition is set to "Info-Package" (to be compliant with the INFO spec). Con= tent-Disposition was created a long time ago to bring some order to the wil= d and wooly world of body parts.=20 Content-Disposition allows an implementation that receives a random body pa= rt to have some idea of what to do with it even if it doesn't understand it= . In our case, we're dealing with a limited usage where the end points are= conformant to the spec and understand the eCall MSD (or VEDS for car-crash= ) or metadata/control body part. They don't need the Content-Disposition v= alue for guidance. So, I don't see any conflict with using "Info-Package" = when the data arrives via INFO and "by-reference" in other cases. Call-Inf= o identifies the data type, and this is the same regardless of how the data= arrives. --Randy At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: > On 8/10/16 5:38 PM, Randall Gellens wrote: >> In reality, there is no separate INFO package negotiation. The =20 >> endpoints support the data types not because they support the iNFO =20 >> package, but rather they support the INFO package and the data types=20 >> and Call-Info because they comply with the draft. > > You can't do that without violating something. > > For one thing, when using INFO packages the body part that is the=20 > info package must have a content-disposition of "Info-Package". But=20 > for the ecall usage the body part must have a content-disposition of=20 > "by-reference". > > Thanks, > Paul > >> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >> >>> I disagree. >>> >>> The inclusion of the data element in INFO is nothing to do with=20 >>> RFC 7852. The data element is included because the use of an=20 >>> appropriate Info package has been negotiated and used. That Info=20 >>> package definition and the INFO mechanism itself makes no mention=20 >>> of use of Call-Info in association with it. >>> >>> Further I see no justification for complicating any error handling=20 >>> by suddenly defining it to be applicable, as it is not necessary.=20 >>> INFO requests always contain a data element appropriate to the Info=20 >>> package that is defined for its use - it absolutely does not need a=20 >>> secondary reference to the package. >>> >>> Keith >>> >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 10 August 2016 18:20 >>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; =20 >>> ecrit@ietf.org >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-=20 >>> Call-Info usage brings no value) >>> >>> Hi Keith, >>> >>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> Unless someone is defining a new usage for Call-Info beyond RFC7852 >>>> then I have to agree with Ivo. That additional usage is not currentl= y >>>> defined in draft-ietf-ecrit-ecall, and I would need to understand th= at >>>> usage before it is included. >>>> >>>> At the moment RFC7852 is only used for the transfer of MSD in INVIT= E >>>> requests and 200 (OK) responses, and therefore that is the only plac= e >>>> where it should appear in association with RFC7852. >>> >>> RFC 7852 covers use of Call-Info to point to emergency call data =20 >>> blocks in any SIP message that is permitted to carry a body. >>> >>>> >>>> Negotiation and transfer of MSD in association with INFO requests i= s >>>> an entirely separate transfer mechanism, not covered by >>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>> there as though it had been. Inclusion will lead to complete confusi= on >>>> as to whether the requirements of the INFO mechanism or the >>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it should = be >>>> absolutely clear that only the former apply. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlac= ek >>>> Sent: 10 August 2016 08:41 >>>> To: Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hello, >>>> >>>>> The invite response still has a body with content-disposition >>>>> by-reference. If you remove the reference then its processing is >>>>> undefined. >>>> >>>> If the Call-Info is omitted in INVITE response, then: >>>> Alt1: a new value could be defined and used in the >>>> Content-Disposition header field of the >>>> application/emergencyCallData.eCall.control+xml body; >>>> or >>>> Alt2: an existing value could be used in the Content-Disposition >>>> header field of the application/emergencyCallData.eCall.control+xml >>>> body; >>>> or >>>> Alt3: the Content-Disposition header field can be omitted and thus >>>> "render" would apply for the >>>> application/emergencyCallData.eCall.control+xml body according to >>>> RFC3261 section 13.2.1. >>>> >>>> We cannot use the Call-Info in INVITE response as described in >>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, t= he >>>> Call-Info points to the >>>> application/emergencyCallData.eCall.control+xml body. This body >>> > contains a delivery report for the MSD sent in INVITE request. >>> This is >>>> NOT information about callee as described in RFC3261. >>>> >>>> Kind regards >>>> >>>> Ivo >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself on= ly >>> -------------- Randomly selected tag: --------------- The idea=20 >>> that Bill Gates has appeared like a knight in shining armor to lead=20 >>> all customers out of a mire of technological chaos neatly ignores=20 >>> the fact that it was he who, by peddling second-rate technology, >>> led them into it in the first place. --Douglas Ada= ms -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Who tells the stories= of a culture really governs human behavior. It used to be the parent, the= school, the church, the community. Now it's a handful of global conglomer= ates that have nothing to tell, but a great deal to sell. --George Gerbner, dean of Annenberg School of Communication From nobody Tue Aug 16 06:53: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 67CE012D0FC for ; Tue, 16 Aug 2016 06:53:25 -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 oM0DD-NhDTos for ; Tue, 16 Aug 2016 06:53:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 465C012B061 for ; Tue, 16 Aug 2016 06:53:23 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-f7-57b31acf3f59 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 9D.05.06563.FCA13B75; Tue, 16 Aug 2016 15:53:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Tue, 16 Aug 2016 15:53:18 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Thread-Index: AQHR98WLx8Ll/YIPOkOZUiRwk50JBA== Date: Tue, 16 Aug 2016 13:53:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.17] Content-Type: multipart/mixed; boundary="_004_D3D8F619CB5Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUyM2K7ge5Fqc3hBudm6Fo0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN/Lf7EXnDWs+HTuInsD41etLkZODgkBE4mL5/+xdjFycQgJ rGeUOHXmIguEs4RRYtWspUxdjBwcbAIWEt3/tEEaRARUJTacWckIEhYWcJNYdt0ExBQRcJd4 vKAKokJP4k7nCXaQMAtQ9YHP4iAmr4CVxOEzbiAVQgLZEv+uL2AFsTkFrCV6r7exgdiMAmIS 30+tYQKxmQXEJW49mc8EcaSIxMOLp9kgbFGJl4//gfWKAm36/nU2M8h4CQFFieX9chCtkRJ9 aycwg9i8AoISJ2c+YZnAKDILydRZSMpmISmDiMdLvH20kRnCNpB4f24+lK0tsWzhayhbX2Lj l7OMELa1xOV765gw1ehKHDl/jB3CVpRo297MBmGvYJRYtqJiFtDVIL19P9hgSqZ0P2RfwMi3 ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwvg9u+a27g3H1a8dDjAIcjEo8vArMm8KFWBPL iitzDzGqAM15tGH1BUYplrz8vFQlEd7DopvDhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QM FxJITyxJzU5NLUgtgskycXBKNTByTrloeWCT0buvB5lE/20RKwt50+PEvPz8Rke/MosZ+r0B ibZOrveVgsTuV/1+I1X4eDvz8dILF2bsyDderPWKR9Bi8ofAvH8ZwixxWQfWp+tMUX75SSz9 98W15TM99tZ055a6qleYMARIK5V84DvderSgXzB2edDE4vW6EpJqMoyKc55ITlRiKc5INNRi LipOBAAGTEQ09wIAAA== Archived-At: Subject: [Ecrit] FW: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 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, 16 Aug 2016 13:53:25 -0000 --_004_D3D8F619CB5Fchristerholmbergericssoncom_ Content-Type: multipart/alternative; boundary="_000_D3D8F619CB5Fchristerholmbergericssoncom_" --_000_D3D8F619CB5Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, We submitted a draft to SIPCORE, which defines the usage of the Content-ID = header field for SIP. Please provide any questions/comments/input on the SIPCORE list. Regards, Christer From: sipcore > o= n behalf of Christer Holmberg > Date: Tuesday 16 August 2016 at 16:50 To: "sipcore@ietf.org" > Subject: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00 Hi, When a SIP message contains a multipart/mixed body, individual body parts c= an be associated with a Content-ID header field and header fields of the SI= P message can refer to those body parts. Note that the Content-ID is not a = SIP header field in such cases, but a MIME header field related to the indi= vidual body part. However, in ECRIT it was identified that there are cases where a request wi= th a single message body also needs a Content-ID header field as header fie= lds of SIP message needs to refer to the body =96 in which Content-ID it ne= eds to become a SIP header field. Later, it was also realised that there exist non-ECRIT cases where it is al= so needed. Please see the draft for examples. We have submitted a draft, which gives description of the problem and defin= es the Content-ID header field for SIP. For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: Indiv= idual repo) Regards, Christer & Ivo --_000_D3D8F619CB5Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3F28786E6EEC9E4688A098F03178C03B@ericsson.com> Content-Transfer-Encoding: quoted-printable
FYI,

We submitted a draft to SIPCORE, which defines the usage of the Conten= t-ID header field for SIP.

Please provide any questions/comments/input on the SIPCORE list.

Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Tuesday 16 August 2016 at 16:= 50
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] Draft new: draft= -holmberg-sipcore-content-id-00


Hi,

When a SIP message contains a multipart/mixed body, individual body pa= rts can be associated with a Content-ID header field and header fields of t= he SIP message can refer to those body parts. Note that the Content-ID is n= ot a SIP header field in such cases, but a MIME header field related to the individual body part.

However, in ECRIT it was identified that there are cases where a reque= st with a single message body also needs a Content-ID header field as heade= r fields of SIP message needs to refer to the body =96 in which Content-ID = it needs to become a SIP header field.

Later, it was also realised that there exist non-ECRIT cases where it = is also needed.

Please see the draft for examples.

We have submitted a draft, which gives description of the problem and = defines the Content-ID header field for SIP.

For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: Individ= ual repo)

Regards,

Christer & Ivo
 --_000_D3D8F619CB5Fchristerholmbergericssoncom_-- --_004_D3D8F619CB5Fchristerholmbergericssoncom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Tue, 16 Aug 2016 13:53:18 GMT"; modification-date="Tue, 16 Aug 2016 13:53:18 GMT" Content-ID: <2E0D2F9E71D1F242AD150A246ACF59AA@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== --_004_D3D8F619CB5Fchristerholmbergericssoncom_-- From nobody Tue Aug 16 06:58:20 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 AFF0B12B039 for ; Tue, 16 Aug 2016 06:58:19 -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 8GSNF9-11vc0 for ; Tue, 16 Aug 2016 06:58:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 78F8412B034 for ; Tue, 16 Aug 2016 06:58:17 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-a3-57b31bf79270 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 08.E2.02553.7FB13B75; Tue, 16 Aug 2016 15:58:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Tue, 16 Aug 2016 15:58:14 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR8Vma5y1Wib8L4km9GhsYSMsy2qA+zzqAgAAZxgCAAaXegIAAG4qAgAEGegCAAMNJ+oAASFKCgAD3LoCABpz7AIAAtV4AgAC1nYA= Date: Tue, 16 Aug 2016 13:58:13 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <892CF9CCD4ABDA45BAFE17B68125A94A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7tO536c3hBpO+GVtMO3mZ2aJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB5LFnyk8ljR8NzZo+7ty4xeWy985glgDWKyyYlNSez LLVI3y6BK+PzleiCJseKT9uuMjYw9pt0MXJySAiYSPRPfMsCYgsJrGeU2Nef2cXIBWQvYZQ4 P+8uWxcjBwebgIVE9z9tkLiIwA1GiePTdzCBNAgLLGSUuPBABMQWEVjEKLF4uRyEXSYxY+FB VhCbRUBV4sjuRWALeAWsJA7tfcAMseAAq8SKrcuZQRKcAn4Sr6ceBRvKKCAm8f3UGjCbWUBc 4taT+UwQlwpILNlznhnCFpV4+fgf2AJRAT2J719nQ8UVJa5OXw7VqydxY+oUNgjbWuLy3e3s ELa2xLKFr5khDhKUODnzCcsERrFZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxanJSbbmSkl1qU mVxcnJ+nl5dasokRGJMHt/w22MH48rnjIUYBDkYlHl4F5k3hQqyJZcWVuYcYJTiYlUR4S6U2 hwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgVH7N1cYm Pe9kgm1p46IDWQsvcMurylYrbp+4qdvD9JDMpfO+WpM/Tu7iK7SfVPHH81D53kPRdZKtH0Ml Ts1kd5Tsuu052T24m+nzjoovEjcfGM80loxmF0ucdW3uMol0Nk35X89u3FY6tfezGMO0wgf7 vL6787OXTHXcduT5sqccJ3bnrSgWUWIpzkg01GIuKk4EAKO3FqrFAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 16 Aug 2016 13:58:20 -0000 Hi, > Content-Disposition allows an implementation that receives a random body >part to have some idea of what to do with it even if it doesn't >understand it. =20 Exactly - and in INFO you use Content-Disposition =B3info-package=B2, which means that the info package description define what to do it. And, you will not receive it unless you understand it. C-D =B3info-package=B2 does NOT refer to a Call-Info header field - and including a Call-Info header field in INFO would not change that. Regards, Christer >-----Original Message----- >From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >Sent: Monday, August 15, 2016 9:23 PM >To: Paul Kyzivat; Drage, Keith (Nokia - GB); Ivo Sedlacek; >ecrit@ietf.org; Brian Rosen >Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage >brings no value) > >Hi Paul, > >The draft says that when data is sent in INFO, the body part's >Content-Disposition is set to "Info-Package" (to be compliant with the >INFO spec). Content-Disposition was created a long time ago to bring >some order to the wild and wooly world of body parts. >Content-Disposition allows an implementation that receives a random body >part to have some idea of what to do with it even if it doesn't >understand it. In our case, we're dealing with a limited usage where the >end points are conformant to the spec and understand the eCall MSD (or >VEDS for car-crash) or metadata/control body part. They don't need the >Content-Disposition value for guidance. So, I don't see any conflict >with using "Info-Package" when the data arrives via INFO and >"by-reference" in other cases. Call-Info identifies the data type, and >this is the same regardless of how the data arrives. > >--Randy > >At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote: > >> On 8/10/16 5:38 PM, Randall Gellens wrote: >>> In reality, there is no separate INFO package negotiation. The >>> endpoints support the data types not because they support the iNFO >>> package, but rather they support the INFO package and the data types >>> and Call-Info because they comply with the draft. >> >> You can't do that without violating something. >> >> For one thing, when using INFO packages the body part that is the >> info package must have a content-disposition of "Info-Package". But >> for the ecall usage the body part must have a content-disposition of >> "by-reference". >> >> Thanks, >> Paul >> >>> At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>> >>>> I disagree. >>>> >>>> The inclusion of the data element in INFO is nothing to do with >>>> RFC 7852. The data element is included because the use of an >>>> appropriate Info package has been negotiated and used. That Info >>>> package definition and the INFO mechanism itself makes no mention >>>> of use of Call-Info in association with it. >>>> >>>> Further I see no justification for complicating any error handling >>>> by suddenly defining it to be applicable, as it is not necessary. >>>> INFO requests always contain a data element appropriate to the Info >>>> package that is defined for its use - it absolutely does not need a >>>> secondary reference to the package. >>>> >>>> Keith >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 10 August 2016 18:20 >>>> To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; >>>> ecrit@ietf.org >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- >>>> Call-Info usage brings no value) >>>> >>>> Hi Keith, >>>> >>>> At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote: >>>> >>>>> Unless someone is defining a new usage for Call-Info beyond >>>>>RFC7852 >>>>> then I have to agree with Ivo. That additional usage is not >>>>>currently >>>>> defined in draft-ietf-ecrit-ecall, and I would need to understand >>>>>that >>>>> usage before it is included. >>>>> >>>>> At the moment RFC7852 is only used for the transfer of MSD in >>>>>INVITE >>>>> requests and 200 (OK) responses, and therefore that is the only >>>>>place >>>>> where it should appear in association with RFC7852. >>>> >>>> RFC 7852 covers use of Call-Info to point to emergency call data >>>> blocks in any SIP message that is permitted to carry a body. >>>> >>>>> >>>>> Negotiation and transfer of MSD in association with INFO requests >>>>>is >>>>> an entirely separate transfer mechanism, not covered by >>>>> draft-ietf-ecrit-data-only-ea and therefore it should never appear >>>>> there as though it had been. Inclusion will lead to complete >>>>>confusion >>>>> as to whether the requirements of the INFO mechanism or the >>>>> requirements of draft-ietf-ecrit-data-only-ea apply, when it >>>>>should be >>>>> absolutely clear that only the former apply. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>> -----Original Message----- >>>>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo >>>>>Sedlacek >>>>> Sent: 10 August 2016 08:41 >>>>> To: Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage >>>>>not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hello, >>>>> >>>>>> The invite response still has a body with content-disposition >>>>>> by-reference. If you remove the reference then its processing is >>>>>> undefined. >>>>> >>>>> If the Call-Info is omitted in INVITE response, then: >>>>> Alt1: a new value could be defined and used in the >>>>> Content-Disposition header field of the >>>>> application/emergencyCallData.eCall.control+xml body; >>>>> or >>>>> Alt2: an existing value could be used in the Content-Disposition >>>>> header field of the application/emergencyCallData.eCall.control+xml >>>>> body; >>>>> or >>>>> Alt3: the Content-Disposition header field can be omitted and thus >>>>> "render" would apply for the >>>>> application/emergencyCallData.eCall.control+xml body according to >>>>> RFC3261 section 13.2.1. >>>>> >>>>> We cannot use the Call-Info in INVITE response as described in >>>>> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, >>>>>the >>>>> Call-Info points to the >>>>> application/emergencyCallData.eCall.control+xml body. This body >>>> > contains a delivery report for the MSD sent in INVITE request. >>>> This is >>>>> NOT information about callee as described in RFC3261. >>>>> >>>>> Kind regards >>>>> >>>>> Ivo >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- The idea >>>> that Bill Gates has appeared like a knight in shining armor to lead >>>> all customers out of a mire of technological chaos neatly ignores >>>> the fact that it was he who, by peddling second-rate technology, >>>> led them into it in the first place. --Douglas >>>>Adams > > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- Who tells the >stories of a culture really governs human behavior. It used to be the >parent, the school, the church, the community. Now it's a handful of >global conglomerates that have nothing to tell, but a great deal to sell. > --George Gerbner, dean of Annenberg School of Communication > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Aug 16 12:12: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 D9C8B12D6AA for ; Tue, 16 Aug 2016 12:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digitaldatatech.onmicrosoft.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 NizebADPxGY8 for ; Tue, 16 Aug 2016 12:12:26 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0064.outbound.protection.outlook.com [104.47.42.64]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE9312B00B for ; Tue, 16 Aug 2016 12:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitaldatatech.onmicrosoft.com; s=selector1-ddti-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cZeW7NBHASJscGe4kikJhh9xszctusdwn5u7QsBWz5w=; b=nHk+CcM1K52n87rUZ0KvoFXRvGuepjzNotgZzJ43bGKLI4eZbQ+G1cenLUukD9PcPPLIRO6xNMlfZKHo1MZREvTNe3Vq3ajn5hKTYA9T8+BCOTW/Y2fGw18CjQIwu4k/FG8VSrHsZHdq+X0gTRTLVwIHJ/mEawUTO4rofExT34U= Received: from BN6PR17MB1252.namprd17.prod.outlook.com (10.173.164.8) by BN6PR17MB1250.namprd17.prod.outlook.com (10.173.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.587.9; Tue, 16 Aug 2016 19:12:24 +0000 Received: from BN6PR17MB1252.namprd17.prod.outlook.com ([10.173.164.8]) by BN6PR17MB1252.namprd17.prod.outlook.com ([10.173.164.8]) with mapi id 15.01.0549.027; Tue, 16 Aug 2016 19:12:23 +0000 From: Chris Santer To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-similar-location comment Thread-Index: AdH38gqi92/USf56TY68qKT2j98fSQ== Date: Tue, 16 Aug 2016 19:12:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=CSanter@ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: 86d992b6-5c2b-4bc0-0d45-08d3c6094113 x-microsoft-exchange-diagnostics: 1; BN6PR17MB1250; 6:nIK1a5QJlo60P7XFv9VIv92twtSZIWH6lc5ZeKNOEopnnvtL19pkCMkixWvymBYBS7UarebFV1a3ive621X1/t1YYrT1tZMGIbAu0K5eiHifRbFODoUntKUsOtRsoNww3c8TBunyKkDpcW8DsbpB3CIL6kLf6SqbzYQD+C2KgvFWTYMBKMvngrJW9SYMX3fzWmYvRcojJW03piytTaOROUvXgnOPl9tzWdDhl73hpAf71c8h1Ah7ytKAT1/4ZNqEN6+s//qeVFvOml77LuleCXqX3OZtSKCOyTiC3a6i9Go=; 5:WLqYV15z+qgwosO2LSMPqoiMA1DY4Pki0jKRPZchAkrMmxR9Js5VQvd5km9fLXOeDZyI5mmNnCEPKnyoQR50jwKwounnL0eGj7bahMtfZD2tBUT6etDtr6mjrsVgfrQ7T3t/oKKTPiwKvg8/c6kN4g==; 24:M5/geBfPiQ9ktBuy0DnICyedsIAJGyl4wFgEgVvVfkoETVf9CXj4GVNKypPOw71WJ4y/vsyclQrLWIx2Rk/Yq+UpqHlcdnuxr4BPRbY2IkU=; 7:cWNYu2KUGZbEIVF+KoLc8rhGpeVmDsjkRR5zdGOoQmiio04W5QBW0WW3DoAK71kjJElHqD39wUN1y+Gy9hKtG6kR/v6KVhYtSz9EAc9RzUu1Yq/AFkj6IVmteDvDEHyfxPrT0a4RFvmLxWxRIXoJtBtwdQ04GaGg9ftTkhoIYSgeaJ/GTBdTfGfq5zNNZyS7HTVmIrd7pm+xSRpRk9DdV2xjyfNizYIUdC0soTEf5FIta/jtksELVjblPqtduQQc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR17MB1250; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN6PR17MB1250; BCL:0; PCL:0; RULEID:; SRVR:BN6PR17MB1250; x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(51694002)(189002)(10400500002)(230783001)(66066001)(9326002)(19580395003)(450100001)(1730700003)(5630700001)(229853001)(54356999)(5002640100001)(7696003)(7736002)(7846002)(80792005)(5640700001)(74316002)(81166006)(19300405004)(97736004)(106356001)(86362001)(50986999)(81156014)(110136002)(107886002)(101416001)(2351001)(189998001)(68736007)(2900100001)(15975445007)(19625215002)(3660700001)(16236675004)(8676002)(87936001)(33656002)(2906002)(6116002)(3846002)(102836003)(586003)(122556002)(77096005)(790700001)(76576001)(105586002)(3280700002)(99286002)(92566002)(9686002)(8936002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR17MB1250; H:BN6PR17MB1252.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ddti.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR17MB1252FE5611D12E79357FA300CA130BN6PR17MB1252namp_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 19:12:23.4920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR17MB1250 Archived-At: Subject: [Ecrit] draft-ietf-ecrit-similar-location comment 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, 16 Aug 2016 19:12:29 -0000 --_000_BN6PR17MB1252FE5611D12E79357FA300CA130BN6PR17MB1252namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just wanted to add a comment for the draft-ietf-ecrit-similar-location dr= aft: The examples provided are clearly US addresses, so they shou= ld be consistent with the US profile defined by CLDXF. For example, the following elements: KING AVE NW Should be: KING COUNTY AVENUE NORTHWEST There are several examples with this problem. Thanks Chris Santer --_000_BN6PR17MB1252FE5611D12E79357FA300CA130BN6PR17MB1252namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I just wanted to add a comment for the draft-ietf-ec= rit-similar-location draft:

 

The <civicAddress> examples provided are clear= ly US addresses, so they should be consistent with the US profile defined b= y CLDXF.

 

For example, the following <civicAddress> elem= ents:

 

<A2>KING</A2>

<STS>AVE</STS>

<POD>NW</POD>

 

Should be:

 

<A2>KING COUNTY</A2>

<STS>AVENUE</STS>

<POD>NORTHWEST</POD>

 

There are several examples with this problem.

 

Thanks

 

Chris Santer

--_000_BN6PR17MB1252FE5611D12E79357FA300CA130BN6PR17MB1252namp_-- From nobody Tue Aug 16 12:39: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 C755212D820 for ; Tue, 16 Aug 2016 12:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 roEZgtzSppbe for ; Tue, 16 Aug 2016 12:39:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 C0C4512D81E for ; Tue, 16 Aug 2016 12:39:06 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so49569187qkc.0 for ; Tue, 16 Aug 2016 12:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iF0enawkOyjT0kKzLy/toZjl+mTXmxyuC48/u39oxRI=; b=B6NnEj+tBK08EFNlhbhxJ6qGUgwia8QR8xWNnxwITJcnKguriEg5gO98xT7Ch0b8i5 +u8koFhKnWaIpARDqMOmZP4rmPrqfln//e6l9wCenD+dwh4NrLFpKObujabbiEWfyUXf m5cut8ZWicFM9MXrARhqZK9DW+JVppyVgwQ+gBbcZIYsZ8rqGcH5OWmwfAfIsCuPKdOG EGY2hoxV+xXH+rt7LdNNMpFmqvih68M7wthQJhWwGS9GpY0er1+G5eWjqR0xzpw7HhH7 0yQzvGbjWbGZfjmnuVF3G8MTm+Oz7bNHGXtpqLc7rSR0BISrdSUsPMe/WEhtaNB3P5zA xD5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iF0enawkOyjT0kKzLy/toZjl+mTXmxyuC48/u39oxRI=; b=XUJYejcPJT1kmGngPXLJjvylDdkcxOCN+yrvl2N8b3pB0HejWhIIaJ4UL4PN32Iw2G Dbb9CnS90aDx6snZQL4qOj4LPmA5ADl5kOnr8qANlCbw7gODs1JXxs3kQRTsXCxtNI2w 356G7QxmSjij/BjpChIo0dvhVrBK10Pj67T56eLOQfzhyaE5r6CIrbe/27dqbELlihEN ts06AXvwfKglOKp0mmfCZ3hVs7xf0vCWruTKCQ4Q7eePoDGXxTLQfkcoc4jOSi/Wvwui QWdRSrp+cupyfK4aptbBSACL3fvw0BWZbwX9XNupdUXb2lp+fCQdN09VJCvAQtVV9EmO HaUA== X-Gm-Message-State: AEkoouv8nHgBLc9eEZUNUddg1F5ypWCxGLBpVgfPo36nehbmtWw+NC7HypRRSXY6THw0xg== X-Received: by 10.55.47.199 with SMTP id v190mr41718944qkh.45.1471376345948; Tue, 16 Aug 2016 12:39:05 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r184sm14667383qke.0.2016.08.16.12.39.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 12:39:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_282D9BC1-A038-4F79-A63E-58FC57F29A32" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Tue, 16 Aug 2016 15:39:02 -0400 Message-Id: <3F3F4E7B-3FE8-40BB-87CA-097D1F3ED42C@brianrosen.net> References: To: Chris Santer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location comment 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, 16 Aug 2016 19:39:09 -0000 --Apple-Mail=_282D9BC1-A038-4F79-A63E-58FC57F29A32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, I=E2=80=99ll change them. Brian > On Aug 16, 2016, at 3:12 PM, Chris Santer wrote: >=20 > Hi, > =20 > I just wanted to add a comment for the = draft-ietf-ecrit-similar-location draft: > =20 > The examples provided are clearly US addresses, so they = should be consistent with the US profile defined by CLDXF. > =20 > For example, the following elements: > =20 > KING > AVE > NW > =20 > Should be: > =20 > KING COUNTY > AVENUE > NORTHWEST > =20 > There are several examples with this problem. > =20 > Thanks > =20 > Chris Santer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_282D9BC1-A038-4F79-A63E-58FC57F29A32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, I=E2=80=99ll change them.

Brian

On Aug 16, 2016, at 3:12 PM, Chris Santer <CSanter@ddti.net> = wrote:

Hi,
 
I just = wanted to add a comment for the draft-ietf-ecrit-similar-location = draft:
 
The <civicAddress> examples provided are clearly US = addresses, so they should be consistent with the US profile defined by = CLDXF.
 
For example, the following <civicAddress> elements:
 
<A2>KING</A2>
<STS>AVE</STS>
<POD>NW</POD>
 
Should be:
 
<A2>KING COUNTY</A2>
<STS>AVENUE</STS>
<POD>NORTHWEST</POD>
 
There are several examples with this problem.
 
Thanks
 
Chris = Santer
_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_282D9BC1-A038-4F79-A63E-58FC57F29A32-- From nobody Wed Aug 17 13:14: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 7559812D190 for ; Wed, 17 Aug 2016 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digitaldatatech.onmicrosoft.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 YT6aTfpSofy4 for ; Wed, 17 Aug 2016 13:14:16 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0062.outbound.protection.outlook.com [104.47.37.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4619112D0FF for ; Wed, 17 Aug 2016 13:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitaldatatech.onmicrosoft.com; s=selector1-ddti-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3Yf5SaRyc2gIrCD14KF+UB6CxxxtRwyDCpTgNasgmtE=; b=eeR6lyA0NiDkzLe8aX8TUBIb4PIDLFYWUjNwrITqH3erunxx45zSHKFN12rv0u/XP+K7pMT3nTwlygn7Q58cW4KBA6nr1/8UHCvgjAS1WuycVd+IVXWMJiF/kPOn2kamvi6v6VM71gNXF3z25RTRKnlQAKXCTWgU5TzwTTmBwH0= Received: from MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) by MWHPR17MB1069.namprd17.prod.outlook.com (10.173.122.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 20:14:04 +0000 Received: from MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) by MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) with mapi id 15.01.0549.027; Wed, 17 Aug 2016 20:14:04 +0000 From: Dan Banks To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info Thread-Index: AdHh/5kM7KlxIdBsQ4SdBwiTXBZrqgNK9wXwAmX18nA= Date: Wed, 17 Aug 2016 20:14:04 +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: spf=none (sender IP is ) smtp.mailfrom=DBanks@ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: 215c4333-86eb-43dd-3987-08d3c6db0969 x-microsoft-exchange-diagnostics: 1; MWHPR17MB1069; 6:zv6m8QOAZpIzmfXHPy3tLBdIRi7AICbGPEs465+MxXfuHcYsyHD6paU9x9ld2TaiRJqCNnx1CgKypOPdtO4ddIkWUyJ0/heb68CQ+fDyxt7GgmhSgUDxHnRZ/YpK56Nj1+ftvPf3l/8DrxLieuNaMFRv+NGNLeGmFau2/8e36r1tpBcROLbav4kDSAtbZwtdAU0vFicSLEj62cO5uwO/AeqUGaVx49Xsj8d3XFpZfZXUIn67orE3gms2w5coywEtBfJjzEL3OSlWJdMKe2myq7qnZNplauYOZ+QC5VHJQAQ=; 5:w79wpjaXt8o1FwBElH+5XMaVEvwUwAKSb5A6GclGzEwOHSsaFYRDoCwLbeOUr7fctnq/c5iV5+I/0T/njcescr6i4n9MOSFVBBl/rncISazaudLM8XZaexc9SxRSqNvs7S3tTL6DaIAVpcPRgi/lmA==; 24:B8pN0yh8ymxH2w3Js5Tq+LmLDfTJZBWSAe3rc3wf17cSJ+2XJGKpYfR4fPy2TrZzAoWhLwkTTaoGX6yRPzEj6p/1SbgEWyH7BMTpNpOoJ/Q=; 7:4ePsrmUZ/HgdSgLKSYwUcgCMX02Tl3iUpXSLrVbK1RqaVoxFmcDSXYGvlZoHvOsQnB4uE6Xbq7zAu2oMSPyoC0FAZaptseYHnpAjB2R8LQR7xpyUMfnPIuM1ZKmFLCj3lhT8XtY9Tv4J36bSCe+HZmDJ55sJqWXiIbk2nVagpmMvrEdxVD6pHERnCqi9ZS1UmW0z1LNqjaC7rkrQm90BPMNVMGjWFp/msIEOYO5T1HukQWEWLBO0Fc3JcmrN4YC1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR17MB1069; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:MWHPR17MB1069; BCL:0; PCL:0; RULEID:; SRVR:MWHPR17MB1069; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(374574003)(505004003)(199003)(377454003)(13464003)(189002)(66066001)(19580405001)(5001770100001)(99286002)(122556002)(68736007)(2900100001)(97736004)(3280700002)(81156014)(81166006)(6116002)(15975445007)(102836003)(2906002)(586003)(92566002)(9686002)(76576001)(3846002)(76176999)(19580395003)(3660700001)(2501003)(77096005)(5890100001)(87936001)(101416001)(11100500001)(8676002)(106356001)(8936002)(80792005)(551944002)(5002640100001)(86362001)(10400500002)(2950100001)(50986999)(189998001)(7736002)(105586002)(54356999)(33656002)(7696003)(7846002)(74316002)(305945005)(107886002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR17MB1069; H:MWHPR17MB1071.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ddti.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 20:14:04.5368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1069 Archived-At: Subject: Re: [Ecrit] WGLC Announce: A LoST extension to return complete and similar location info 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, 17 Aug 2016 20:14:20 -0000 I still believe that complete and similar location will be a useful additio= n to LoST, but I would like some time to attempt an implementation prior to= the standard being published. Despite my several reviews of additional da= ta, I'm working on updating our implementation of that now and I have found= a few new things that it would have been nice to fix earlier. Dan > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: Friday, August 05, 2016 11:12 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC Announce: A LoST extension to return complete a= nd > similar location info >=20 > We received no comments during WGLC for this similar-location draft, yet = we > need to know whether you support this draft moving forward for IESG > submission. We'll still take comments along with your statement of suppo= rt > for this draft. >=20 > Roger & Marc > ECRIT Chairs >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall > Sent: Tuesday, July 19, 2016 1:53 PM > To: ecrit@ietf.org > Subject: [Ecrit] WGLC Announce: A LoST extension to return complete and > similar location info >=20 > Today starts a working group last call for: >=20 > A LoST extension to return complete and similar location info > http://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ >=20 > Please review the document and send comments to the ECRIT mail list by Co= B, > July 30, 2016. >=20 >=20 > Thanks, >=20 > Marc & Roger > ECRIT Chairs > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > NOTICE TO RECIPIENT: This email, including attachments, may contain > information which is confidential, proprietary, attorney-client privilege= d > and/or controlled under U.S. export laws and regulations and may be > restricted from disclosure by applicable State and Federal law. Nothing i= n > this email shall create any legal binding agreement between the parties > unless expressly stated herein and provided by an authorized representati= ve > of Comtech Telecommunications Corp. or its subsidiaries. If you are not t= he > intended recipient of this message, be advised that any dissemination, > distribution, or use of the contents of this message is strictly prohibit= ed. > If you received this message in error, please notify us immediately by re= turn > email and permanently delete all copies of the original email and any > attached documentation from any computer or other media. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 17 13:56:58 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 0051B12D740 for ; Wed, 17 Aug 2016 13:56:58 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 ehAuagLi9Q6F for ; Wed, 17 Aug 2016 13:56:56 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C299012D737 for ; Wed, 17 Aug 2016 13:56:56 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 17 Aug 2016 13:56:55 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 17 Aug 2016 13:56:54 -0700 To: Christer Holmberg , Paul Kyzivat , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" , Brian Rosen 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-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 17 Aug 2016 20:56:58 -0000 Hi Everyone, The authors wish to propose a solution to the concerns that have been raised. We recognize that the vehicle data (MSD for eCall and VEDS for car-crash) is properly considered additional data in the context of RFC 7852, while the metadata/control block can be considered its own request/response protocol. With that in mind, our proposal is to have the INFO package associated with the metadata/control block but not the MSD nor VEDS. For a mid-call update request, the PSAP sends a metadata/control block requesting an updated MSD (or VEDS) in INFO. The IVS in turn sends an INFO with a metadata/control block acknowledging the request with a successful result. Both INFO messages contain a metadata/control block associated with the INFO package and not referenced by a Call-Info header field. The INFO sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 additional data, referenced by a Call-Info header field. There would be two body parts in the INFO from the IVS to the PSAP, each with its appropriate MIME type and Content-Disposition. One body part is associated with the INFO package and is the response to the request. The second body part is the updated MSD and is referenced by Call-Info. This more cleanly separates the request/response protocol from the vehicle data. The request/response protocol uses INFO, is associated with an INFO package, and carries data with the Info-Package Content-Disposition. INFO messages sent by the IVS may also contain vehicle data not associated with the INFO package. In eCall, this allows the PSAP to request a mid-call update and the IVS to respond. In car-crash, this allows the PSAP to request the vehicle to take other actions (such as flashing the lights). In all cases, the vehicle responds to a request with an acknowledgment (and indicates if the request was successfully carried out). Note that RFC 6086 permits INFO messages to also carry data not associated with INFO packages. This has an additional advantage of making it cleaner and easier to reuse the emergency call request/response protocol later, in other documents (e.g., so the PSAP can request building sensor data). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is easier to fight for one's principles than to live up to them. --Alfred Adler From nobody Wed Aug 17 15:21:01 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 C16DB12D50E for ; Wed, 17 Aug 2016 15:20:59 -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 SteYmI9Ymkku for ; Wed, 17 Aug 2016 15:20:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C329A12D19F for ; Wed, 17 Aug 2016 15:20:57 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-76-57b4e347e510 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 9D.8F.02553.743E4B75; Thu, 18 Aug 2016 00:20:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 00:20:54 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat , "Drage, Keith (Nokia - GB)" , "ecrit@ietf.org" , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+MnlNFkcN/FbTkuFykDFRyMmJqBNtZIw Date: Wed, 17 Aug 2016 22:20:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7n6774y3hBm+2WVtMO3mZ2aJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB5LFnyk8ljR8NzZo+7ty4xeWy985glgDWKyyYlNSez LLVI3y6BK2P6rIksBb+lK968XcLUwLhTrIuRk0NCwERi4ue3jCC2kMB6Rol558u6GLmA7CWM EutOHwZKcHCwCVhIdP/TBomLCNxglDg+fQcTiCMssJhRYteKVhaIDFDHwl8XwUaJCBhJLJh5 khnEZhFQlbhxtJENxOYV8JXY+eoZO8SK2WwSaz9MZwdJcALdsWjFAbBmRgExie+n1jCB2MwC 4hK3nsxngrhVQGLJnvPMELaoxMvH/1ghbCWJRbc/Q9XrSCzY/YkNwtaWWLbwNTPEYkGJkzOf sExgFJmFZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgRB3c8ttg B+PL546HGAU4GJV4eBWWbQkXYk0sK67MPcQowcGsJML78S5QiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA2NkyNNLTllC1j+/B+46FpKhYVfDumWvy5ld x75Ob5Ox2O9jUtKlcfNiv61QXG89j+XmeSteTmXltmyaZtQdbXoj6fbT0iehexLWrPFmbDHd k1Sy0zJNqYlRnvuyubjx6wlRSwScXk38ZhHisXUG08sdvmnuKxyWRS0VvTorY/JLWyuHZfwK /EosxRmJhlrMRcWJADXHWGKkAgAA Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 17 Aug 2016 22:21:00 -0000 Hi, I thought we discussed usage of legacy (non-Info-Package) INFOs already. RF= C 6086 allows it for backward compatibility. Any new usage MUST use an Info= Package. And, even if it was allowed, using two different INFO mechanisms would make= things even more complicated. I'll let others decide on whether MSD is considered additional data or not,= but I don't think it's relevant because additional data is not a legacy IN= FO usage, nor does additional data update RFC 6086. Regards, Christer -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: 17 August 2016 23:57 To: Christer Holmberg ; Paul Kyzivat ; Drage, Keith (Nokia - GB) ; ecrit= @ietf.org; Brian Rosen Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned= with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no= value) Hi Everyone, The authors wish to propose a solution to the concerns that have been raise= d. We recognize that the vehicle data (MSD for eCall and VEDS for car-cras= h) is properly considered additional data in the context of RFC 7852, while= the metadata/control block can be considered its own request/response prot= ocol. With that in mind, our proposal is to have the INFO package associat= ed with the metadata/control block but not the MSD nor VEDS. For a mid-cal= l update request, the PSAP sends a metadata/control block requesting an upd= ated MSD (or VEDS) in INFO.=20 The IVS in turn sends an INFO with a metadata/control block acknowledging t= he request with a successful result. Both INFO messages contain a metadata= /control block associated with the INFO package and not referenced by a Cal= l-Info header field. The INFO sent by the IVS also contains an updated MSD= (or VEDS) as RFC 7852 additional data, referenced by a Call-Info header fi= eld. There would be two body parts in the INFO from the IVS to the PSAP, e= ach with its appropriate MIME type and Content-Disposition. One body part = is associated with the INFO package and is the response to the request.=20 The second body part is the updated MSD and is referenced by Call-Info. Th= is more cleanly separates the request/response protocol from the vehicle da= ta. The request/response protocol uses INFO, is associated with an INFO pa= ckage, and carries data with the Info-Package Content-Disposition. INFO me= ssages sent by the IVS may also contain vehicle data not associated with th= e INFO package. In eCall, this allows the PSAP to request a mid-call updat= e and the IVS to respond. In car-crash, this allows the PSAP to request the= vehicle to take other actions (such as flashing the lights). In all cases= , the vehicle responds to a request with an acknowledgment (and indicates i= f the request was successfully carried out). Note that RFC 6086 permits INFO messages to also carry data not associated = with INFO packages. This has an additional advantage of making it cleaner and easier to reuse t= he emergency call request/response protocol later, in other documents (e.g.= , so the PSAP can request building sensor data). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is easier to fight= for one's principles than to live up to them. --Alfred Adler From nobody Wed Aug 17 15:44:01 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 8643812D50B for ; Wed, 17 Aug 2016 15:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 KmwkEbhTBRWs for ; Wed, 17 Aug 2016 15:43:57 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 3B6B812D1D8 for ; Wed, 17 Aug 2016 15:43:57 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id w38so901364qtb.0 for ; Wed, 17 Aug 2016 15:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xMT+Qa5cGQT2X4feAT1Sm9LRVCar00TFdWYVwgfaxtM=; b=ee0gq09sMb+Kg2DfikKP+1LeaLgvfMsW5SD+BWNt/GvtynhgZn0x7JDdyczGiCHllD O2G7redgs0PEYLyuV4W1y2vOZJIvBoOOgXk8ponnQltJxLsR110YNRiMWUtL0Cz4/U3b VpUJnYCnXylxvlG4RilESR+RGBg4EzPregXbJY88gwe1qoswWXuykdZQuB3UjscQZfzR HU8V9kTC4TGtx6BKJD2LBa51Qvy6WlUP9ig1aZPoh3c4pe0mAvQ3GCHcwMIBPt5sLy4L ysAvV5sF4AubuDg90yGCh/JAU5OxSyaQV3wbBKabiD95v0l8xaQF40KexR7HyjTRABoK GOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xMT+Qa5cGQT2X4feAT1Sm9LRVCar00TFdWYVwgfaxtM=; b=Jpm8w1/89kIEi5GNWMu1XkzKSF52pEHd6U/D/gnTwsAYMbH964amKP7BBPXGCRZYGm AO6av0WCndoele1cFZvK+U8KITV0c0JX3D9x8HWQHlcoHsxPJOwEDXd2k1HQn8/FZJW2 9K+Kxja0URVFzYtiH8F5X3sbu82EHuX38bdbiwzgp5JVFv+4zsk06KB2UCOLp9dh9qsI FYt2vXX1d0iutfH+rfnyfDNTfQQ6LdsYMx3P/joTEBccWa3YWPfHVdpxrK7XE4/PAZFd 7eTUF2p6d94EzDBsbLFclcJm0KrqZOHuWnvZCBgEUtmqjwzQb1189sMdHuZUIIhDVX5q TtEw== X-Gm-Message-State: AEkoous5SYftvi6IbFtjMRlBcXvDxZMWJrkoUBy9Z23YPcjF4rhCIHX4Fg0MruQhIue9JQ== X-Received: by 10.200.56.253 with SMTP id g58mr48017211qtc.28.1471473836169; Wed, 17 Aug 2016 15:43:56 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 18sm17781674qkm.32.2016.08.17.15.43.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 15:43:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> Date: Wed, 17 Aug 2016 18:43:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 17 Aug 2016 22:43:59 -0000 You are missing the point of the suggested compromise. This is NOT a legacy INFO. It=E2=80=99s a new-style INFO package, = conforming to 6086. There is only ONE INFO part. It only carries the metadata/control = block, and its ACK. You send an INFO, with the metadata/control body part, with the proper = INFO mime type and content disposition. The MSD/VEDS is not there. You send the MSD/VEDS as Additional Data, in a separate body part, with = the additional data MIME type and content disposition using Call-Info. So there are two parts in the body. One is the INFO block, the other is = the Additional Data block, with the Call-Info header pointing to it. = The latter isn=E2=80=99t legacy use of INFO, it=E2=80=99s permitted use = of Call-Info. 6069 expressly permits this. MSD is most definitely Additional Data, as it is how it is sent in the = initial INVITE. Same data, same MIME, same Disposition. The point we = are making is that the INFO is the command/control mechanism. The = Call-Info carries the VEDS/MSD, whether it=E2=80=99s on an INVITE or an = INFO. The INFO package has the command and it=E2=80=99s response (the = ACK). Brian > On Aug 17, 2016, at 6:20 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I thought we discussed usage of legacy (non-Info-Package) INFOs = already. RFC 6086 allows it for backward compatibility. Any new usage = MUST use an Info Package. >=20 > And, even if it was allowed, using two different INFO mechanisms would = make things even more complicated. >=20 > I'll let others decide on whether MSD is considered additional data or = not, but I don't think it's relevant because additional data is not a = legacy INFO usage, nor does additional data update RFC 6086. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 > Sent: 17 August 2016 23:57 > To: Christer Holmberg ; Paul Kyzivat = ; Drage, Keith (Nokia - GB) = ; ecrit@ietf.org; Brian Rosen = > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage = brings no value) >=20 > Hi Everyone, >=20 > The authors wish to propose a solution to the concerns that have been = raised. We recognize that the vehicle data (MSD for eCall and VEDS for = car-crash) is properly considered additional data in the context of RFC = 7852, while the metadata/control block can be considered its own = request/response protocol. With that in mind, our proposal is to have = the INFO package associated with the metadata/control block but not the = MSD nor VEDS. For a mid-call update request, the PSAP sends a = metadata/control block requesting an updated MSD (or VEDS) in INFO.=20 > The IVS in turn sends an INFO with a metadata/control block = acknowledging the request with a successful result. Both INFO messages = contain a metadata/control block associated with the INFO package and = not referenced by a Call-Info header field. The INFO sent by the IVS = also contains an updated MSD (or VEDS) as RFC 7852 additional data, = referenced by a Call-Info header field. There would be two body parts = in the INFO from the IVS to the PSAP, each with its appropriate MIME = type and Content-Disposition. One body part is associated with the INFO = package and is the response to the request.=20 > The second body part is the updated MSD and is referenced by = Call-Info. This more cleanly separates the request/response protocol = from the vehicle data. The request/response protocol uses INFO, is = associated with an INFO package, and carries data with the Info-Package = Content-Disposition. INFO messages sent by the IVS may also contain = vehicle data not associated with the INFO package. In eCall, this = allows the PSAP to request a mid-call update and the IVS to respond. In = car-crash, this allows the PSAP to request the vehicle to take other = actions (such as flashing the lights). In all cases, the vehicle = responds to a request with an acknowledgment (and indicates if the = request was successfully carried out). >=20 > Note that RFC 6086 permits INFO messages to also carry data not = associated with INFO packages. >=20 > This has an additional advantage of making it cleaner and easier to = reuse the emergency call request/response protocol later, in other = documents (e.g., so the PSAP can request building sensor data). >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- It is easier to = fight for one's principles than to live up to them. > --Alfred Adler >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 17 17:59: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 1C19912D0BC for ; Wed, 17 Aug 2016 17:59:26 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 n4L1AiO5EHLM for ; Wed, 17 Aug 2016 17:59:24 -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 A997712D7AF for ; Wed, 17 Aug 2016 17:59:23 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with SMTP id aBfXbqUqelSxsaBg2b2RUG; Thu, 18 Aug 2016 00:59:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id aBg1bKDKHvDp9aBg2bt5QE; Thu, 18 Aug 2016 00:59:22 +0000 To: Brian Rosen , Christer Holmberg References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Wed, 17 Aug 2016 20:59:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHJULLpSrovvQJrfAvIpbjWymw7/jxm3DqIZN/UA23q73kOn1kN486PPv7wQHq9VND6G7N8YEqwHRM8Xr+vN/6P8806JsNu+GiDMNsAN3qg8H8eOBjxa frj97uw3C7Je2fveEnJKSoVI3cXOkxS5F2DkODD8iEW9kdabk7KW1rjRLzQHtpC5xMkGe2NIHkM2z9HTvNt4CYtGYxxvUYVMQRETewvCbJdRRvDZXxDRCcQT XrJiFQ+8F9j/LN0qcHpmHea9rX9Snxyx3ByEQgnwYKpHmJb6ytYq9/Lf6QgufZ64c9N7v/gb1rN/2mXD8ee0nOVKNY8rwc2WxDW1j4mb5Rc= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 00:59:26 -0000 On 8/17/16 6:43 PM, Brian Rosen wrote: > You are missing the point of the suggested compromise. > > This is NOT a legacy INFO. It’s a new-style INFO package, conforming to 6086. > > There is only ONE INFO part. It only carries the metadata/control block, and its ACK. > > You send an INFO, with the metadata/control body part, with the proper INFO mime type and content disposition. The MSD/VEDS is not there. > You send the MSD/VEDS as Additional Data, in a separate body part, with the additional data MIME type and content disposition using Call-Info. > > So there are two parts in the body. One is the INFO block, the other is the Additional Data block, with the Call-Info header pointing to it. The latter isn’t legacy use of INFO, it’s permitted use of Call-Info. 6069 expressly permits this. > > MSD is most definitely Additional Data, as it is how it is sent in the initial INVITE. Same data, same MIME, same Disposition. The point we are making is that the INFO is the command/control mechanism. The Call-Info carries the VEDS/MSD, whether it’s on an INVITE or an INFO. The INFO package has the command and it’s response (the ACK). Yes, that I how I understood the proposal. And IMO it is a valid thing to do. (I'm pretty sure I did mention an approach like this along the way, but it got lost along the way.) This seems plausible to me. I would then suggest that the while there can then be an INFO with a body that requests the sending of Additional Data, there shouldn't be a *requirement* that the Additional Data come in the same INFO that carries the ACK to that request. It might *typically* come there, because it is a convenient message that happens to be going out at the right time. But it *might* happen to go in some other message - a different INFO, containing some other metadata, or a reINVITE that happens to be needed for some reason, or whatever. This decouples the two usages. Thanks, Paul > >> On Aug 17, 2016, at 6:20 PM, Christer Holmberg wrote: >> >> Hi, >> >> I thought we discussed usage of legacy (non-Info-Package) INFOs already. RFC 6086 allows it for backward compatibility. Any new usage MUST use an Info Package. >> >> And, even if it was allowed, using two different INFO mechanisms would make things even more complicated. >> >> I'll let others decide on whether MSD is considered additional data or not, but I don't think it's relevant because additional data is not a legacy INFO usage, nor does additional data update RFC 6086. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 17 August 2016 23:57 >> To: Christer Holmberg ; Paul Kyzivat ; Drage, Keith (Nokia - GB) ; ecrit@ietf.org; Brian Rosen >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) >> >> Hi Everyone, >> >> The authors wish to propose a solution to the concerns that have been raised. We recognize that the vehicle data (MSD for eCall and VEDS for car-crash) is properly considered additional data in the context of RFC 7852, while the metadata/control block can be considered its own request/response protocol. With that in mind, our proposal is to have the INFO package associated with the metadata/control block but not the MSD nor VEDS. For a mid-call update request, the PSAP sends a metadata/control block requesting an updated MSD (or VEDS) in INFO. >> The IVS in turn sends an INFO with a metadata/control block acknowledging the request with a successful result. Both INFO messages contain a metadata/control block associated with the INFO package and not referenced by a Call-Info header field. The INFO sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 additional data, referenced by a Call-Info header field. There would be two body parts in the INFO from the IVS to the PSAP, each with its appropriate MIME type and Content-Disposition. One body part is associated with the INFO package and is the response to the request. >> The second body part is the updated MSD and is referenced by Call-Info. This more cleanly separates the request/response protocol from the vehicle data. The request/response protocol uses INFO, is associated with an INFO package, and carries data with the Info-Package Content-Disposition. INFO messages sent by the IVS may also contain vehicle data not associated with the INFO package. In eCall, this allows the PSAP to request a mid-call update and the IVS to respond. In car-crash, this allows the PSAP to request the vehicle to take other actions (such as flashing the lights). In all cases, the vehicle responds to a request with an acknowledgment (and indicates if the request was successfully carried out). >> >> Note that RFC 6086 permits INFO messages to also carry data not associated with INFO packages. >> >> This has an additional advantage of making it cleaner and easier to reuse the emergency call request/response protocol later, in other documents (e.g., so the PSAP can request building sensor data). >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- It is easier to fight for one's principles than to live up to them. >> --Alfred Adler >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From nobody Wed Aug 17 23:23: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 1751112D626 for ; Wed, 17 Aug 2016 23:23:11 -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 hRPAoZk9Dvxx for ; Wed, 17 Aug 2016 23:23:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4774B12D5E3 for ; Wed, 17 Aug 2016 23:23:08 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-00-57b5544a9509 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 22.3F.02553.A4455B75; Thu, 18 Aug 2016 08:23:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 08:23:04 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+NjjpZHpzYRry0e+Ak1CeiTcHKBOUiYA Date: Thu, 18 Aug 2016 06:23:04 +0000 Message-ID: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> In-Reply-To: <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3CDAC3E0C52BBE4BBCE20995A580ECD1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7uK5XyNZwg/lHZC2e3p/GZtG46Cmr xYYtx1ksVmw4wGrx/XkXowOrx9/3H5g87n/7y+6xZMlPJo+7ty4xeWy985glgDWKyyYlNSez LLVI3y6BK+PX6mtsBdu0Km4sO8bYwLhaqYuRk0NCwETi9b2/jF2MXBxCAusZJda0zGUGSQgJ LAFyVpd3MXJwsAlYSHT/0wYJiwgoS+y81ckOYjMLbGSUeLJQDMQWFljIKHHhgQhEzSJGicXL 5SBsI4n5V3rZQGwWAVWJuz3rwcbzClhJrL64gxVi73R2iV3nNrOAJDgFnCQu9fexgtiMAmIS 30+tYYJYJi5x68l8JoijBSSW7DnPDGGLSrx8/A+sXlRAT+L719nMIDdLCChJTNuaBtGqJ3Fj 6hQ2CNta4tXdmawQtrbEsoWvoe4RlDg58wnLBEbxWUi2zULSPgtJ+ywk7bOQtC9gZF3FKFqc WpyUm25kpJdalJlcXJyfp5eXWrKJERipB7f8NtjB+PK54yFGAQ5GJR5ehWVbwoVYE8uKK3MP MUpwMCuJ8B4I3houxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJ g1OqgTGJQeuuf4Xi06g652VTLZ104jecYNs6P8j3hcjtAl+nWD2BQ7mnHktcli7+OO/c49wz C/9ee3ly7rLjEqq6246Kzv4pmb1/M+fp/zsfCr2uinl5xHzikZDVhR2/NPpuLTe5XqriaeJy buOHzrcWVqs3zw9S/3OsMJbnz9+5ciU+Bt18RfGTd2xUYinOSDTUYi4qTgQAV2j0rtACAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 06:23:11 -0000 Hi, Please see my reply inline. But, I=B9d like you to send an INFO example according to your example, to make sure we are talking about the same thing. >You are missing the point of the suggested compromise. > >This is NOT a legacy INFO. It=B9s a new-style INFO package, conforming to >6086. > >There is only ONE INFO part. It only carries the metadata/control block, >and its ACK. > >You send an INFO, with the metadata/control body part, with the proper >INFO mime type and content disposition. The MSD/VEDS is not there. >You send the MSD/VEDS as Additional Data, in a separate body part, with >the additional data MIME type and content disposition using Call-Info. > >So there are two parts in the body. One is the INFO block, the other is >the Additional Data block, with the Call-Info header pointing to it. The >latter isn=B9t legacy use of INFO, it=B9s permitted use of Call-Info. 606= 9 >expressly permits this. While RFC 6086 does allow usage of other C-D values than =B3info-package=B2 for specific body parts, the body parts are still associated with the Info Package - which means you know the semantics, and you know that the receiver will support the body part. So, I still don=B9t see what you need Call-Info for? Yes, 6086 does contain an example where one body part is not associated with the Info Package to begin with. But, again, that is to address legacy usages of INFO. Regards, Christer > >> On Aug 17, 2016, at 6:20 PM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >> I thought we discussed usage of legacy (non-Info-Package) INFOs >>already. RFC 6086 allows it for backward compatibility. Any new usage >>MUST use an Info Package. >>=20 >> And, even if it was allowed, using two different INFO mechanisms would >>make things even more complicated. >>=20 >> I'll let others decide on whether MSD is considered additional data or >>not, but I don't think it's relevant because additional data is not a >>legacy INFO usage, nor does additional data update RFC 6086. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: 17 August 2016 23:57 >> To: Christer Holmberg ; Paul Kyzivat >>; Drage, Keith (Nokia - GB) >>; ecrit@ietf.org; Brian Rosen >> >> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage >>brings no value) >>=20 >> Hi Everyone, >>=20 >> The authors wish to propose a solution to the concerns that have been >>raised. We recognize that the vehicle data (MSD for eCall and VEDS for >>car-crash) is properly considered additional data in the context of RFC >>7852, while the metadata/control block can be considered its own >>request/response protocol. With that in mind, our proposal is to have >>the INFO package associated with the metadata/control block but not the >>MSD nor VEDS. For a mid-call update request, the PSAP sends a >>metadata/control block requesting an updated MSD (or VEDS) in INFO. >> The IVS in turn sends an INFO with a metadata/control block >>acknowledging the request with a successful result. Both INFO messages >>contain a metadata/control block associated with the INFO package and >>not referenced by a Call-Info header field. The INFO sent by the IVS >>also contains an updated MSD (or VEDS) as RFC 7852 additional data, >>referenced by a Call-Info header field. There would be two body parts >>in the INFO from the IVS to the PSAP, each with its appropriate MIME >>type and Content-Disposition. One body part is associated with the INFO >>package and is the response to the request. >> The second body part is the updated MSD and is referenced by Call-Info. >> This more cleanly separates the request/response protocol from the >>vehicle data. The request/response protocol uses INFO, is associated >>with an INFO package, and carries data with the Info-Package >>Content-Disposition. INFO messages sent by the IVS may also contain >>vehicle data not associated with the INFO package. In eCall, this >>allows the PSAP to request a mid-call update and the IVS to respond. In >>car-crash, this allows the PSAP to request the vehicle to take other >>actions (such as flashing the lights). In all cases, the vehicle >>responds to a request with an acknowledgment (and indicates if the >>request was successfully carried out). >>=20 >> Note that RFC 6086 permits INFO messages to also carry data not >>associated with INFO packages. >>=20 >> This has an additional advantage of making it cleaner and easier to >>reuse the emergency call request/response protocol later, in other >>documents (e.g., so the PSAP can request building sensor data). >>=20 >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- It is easier to >>fight for one's principles than to live up to them. >> --Alfred Adler >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From nobody Thu Aug 18 06:12: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 F324E12DE05 for ; Thu, 18 Aug 2016 06:12:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 fl4ds93eTya6 for ; Thu, 18 Aug 2016 06:12:17 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 6388C12DDC4 for ; Thu, 18 Aug 2016 06:12:16 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id x25so7554110qtx.2 for ; Thu, 18 Aug 2016 06:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJ3x+nlaM/nICoDmYZandqLyRbQ5YRU6W1hEUBrerd0=; b=SWVHUZ5uhhnBnEdqSR+c0+OWetj6wKxgYR4DqlZ8s/8ZEtWJwB72nUE2iv0rZRRcp+ ErTUhPf6MJlnFEbZiIp69c76U4EltO8qjaFOBSM3TbsGbZFPZn+rZAxpd2OAao35o8sJ VzwDX7LjPUe/FXFgNS5paa5+7ubn4OVecPlVg+MhWu+xiCmaJyXVPziouCKevTfrrL0U KrGmoMhjkjS4yldVoiGttxWiZzTofCtf0QHrHE2ximmgIkUCyyDFAU2AvxUeCRebWUZC NkEx9BbbK1MNsKu0TYbwoEPdo0ufLIM4wIJrH/kA1apVA8XxCfVjBAgCmAhilVKA93X/ fUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJ3x+nlaM/nICoDmYZandqLyRbQ5YRU6W1hEUBrerd0=; b=SkQehPM/tFs/xTqzxUFO8TwLxz/doLYXDq8GO2NLLQD+mG0GdHd6eW3rfyo9dpj3RV Ku20CMYtRstAt8NvaH5oaN2Rvmd2vwJS6u+5t4QPj1vuMV2XUIEuqU68s2b94QDmANIh KSRuUJRGQ5vDIFrbsFE3ke/AU8PJfczwOxmcBg64mmI5K8gVvcl1kLmX29uBY8SB2kTk RRCqcMUEqazLRoupjf1tO1RhSX/90pvEMbsbKK1Ud4tHligKhWnFzDSuDg2HUck2Fhb9 ZsJ8whPAKZAK7oZzXGX9vgAcvgfOuWz411P9m1fr1PUD8Wddrs1TY0GtMgm/LdICZceH XRAA== X-Gm-Message-State: AEkoouvHtga0aiwuPQ1WuPpGkiTlY/2CzvFF5wi1/4oPIUbDCHL7mP8IXBUit64feDKfTQ== X-Received: by 10.200.36.243 with SMTP id t48mr2207065qtt.125.1471525935478; Thu, 18 Aug 2016 06:12:15 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id k186sm981363qke.44.2016.08.18.06.12.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Aug 2016 06:12:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 18 Aug 2016 09:12:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 13:12:20 -0000 Yes, that makes sense. Brian > On Aug 17, 2016, at 8:59 PM, Paul Kyzivat = wrote: >=20 > On 8/17/16 6:43 PM, Brian Rosen wrote: >> You are missing the point of the suggested compromise. >>=20 >> This is NOT a legacy INFO. It=E2=80=99s a new-style INFO package, = conforming to 6086. >>=20 >> There is only ONE INFO part. It only carries the metadata/control = block, and its ACK. >>=20 >> You send an INFO, with the metadata/control body part, with the = proper INFO mime type and content disposition. The MSD/VEDS is not = there. >> You send the MSD/VEDS as Additional Data, in a separate body part, = with the additional data MIME type and content disposition using = Call-Info. >>=20 >> So there are two parts in the body. One is the INFO block, the other = is the Additional Data block, with the Call-Info header pointing to it. = The latter isn=E2=80=99t legacy use of INFO, it=E2=80=99s permitted use = of Call-Info. 6069 expressly permits this. >>=20 >> MSD is most definitely Additional Data, as it is how it is sent in = the initial INVITE. Same data, same MIME, same Disposition. The point = we are making is that the INFO is the command/control mechanism. The = Call-Info carries the VEDS/MSD, whether it=E2=80=99s on an INVITE or an = INFO. The INFO package has the command and it=E2=80=99s response (the = ACK). >=20 > Yes, that I how I understood the proposal. >=20 > And IMO it is a valid thing to do. (I'm pretty sure I did mention an = approach like this along the way, but it got lost along the way.) >=20 > This seems plausible to me. >=20 > I would then suggest that the while there can then be an INFO with a = body that requests the sending of Additional Data, there shouldn't be a = *requirement* that the Additional Data come in the same INFO that = carries the ACK to that request. It might *typically* come there, = because it is a convenient message that happens to be going out at the = right time. But it *might* happen to go in some other message - a = different INFO, containing some other metadata, or a reINVITE that = happens to be needed for some reason, or whatever. This decouples the = two usages. >=20 > Thanks, > Paul >=20 >>=20 >>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>> I thought we discussed usage of legacy (non-Info-Package) INFOs = already. RFC 6086 allows it for backward compatibility. Any new usage = MUST use an Info Package. >>>=20 >>> And, even if it was allowed, using two different INFO mechanisms = would make things even more complicated. >>>=20 >>> I'll let others decide on whether MSD is considered additional data = or not, but I don't think it's relevant because additional data is not a = legacy INFO usage, nor does additional data update RFC 6086. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 17 August 2016 23:57 >>> To: Christer Holmberg ; Paul Kyzivat = ; Drage, Keith (Nokia - GB) = ; ecrit@ietf.org; Brian Rosen = >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage = brings no value) >>>=20 >>> Hi Everyone, >>>=20 >>> The authors wish to propose a solution to the concerns that have = been raised. We recognize that the vehicle data (MSD for eCall and VEDS = for car-crash) is properly considered additional data in the context of = RFC 7852, while the metadata/control block can be considered its own = request/response protocol. With that in mind, our proposal is to have = the INFO package associated with the metadata/control block but not the = MSD nor VEDS. For a mid-call update request, the PSAP sends a = metadata/control block requesting an updated MSD (or VEDS) in INFO. >>> The IVS in turn sends an INFO with a metadata/control block = acknowledging the request with a successful result. Both INFO messages = contain a metadata/control block associated with the INFO package and = not referenced by a Call-Info header field. The INFO sent by the IVS = also contains an updated MSD (or VEDS) as RFC 7852 additional data, = referenced by a Call-Info header field. There would be two body parts = in the INFO from the IVS to the PSAP, each with its appropriate MIME = type and Content-Disposition. One body part is associated with the INFO = package and is the response to the request. >>> The second body part is the updated MSD and is referenced by = Call-Info. This more cleanly separates the request/response protocol = from the vehicle data. The request/response protocol uses INFO, is = associated with an INFO package, and carries data with the Info-Package = Content-Disposition. INFO messages sent by the IVS may also contain = vehicle data not associated with the INFO package. In eCall, this = allows the PSAP to request a mid-call update and the IVS to respond. In = car-crash, this allows the PSAP to request the vehicle to take other = actions (such as flashing the lights). In all cases, the vehicle = responds to a request with an acknowledgment (and indicates if the = request was successfully carried out). >>>=20 >>> Note that RFC 6086 permits INFO messages to also carry data not = associated with INFO packages. >>>=20 >>> This has an additional advantage of making it cleaner and easier to = reuse the emergency call request/response protocol later, in other = documents (e.g., so the PSAP can request building sensor data). >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- It is easier = to fight for one's principles than to live up to them. >>> --Alfred Adler >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >=20 From nobody Thu Aug 18 06:15: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 12EDC12DE06 for ; Thu, 18 Aug 2016 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Hv2EpWLgkM6P for ; Thu, 18 Aug 2016 06:15:26 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 2AB8A12DE04 for ; Thu, 18 Aug 2016 06:15:26 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x25so7600237qtx.2 for ; Thu, 18 Aug 2016 06:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kr45DvDPV9kAMuPBe/uZxzAIPMnzkEPOCxGH8WE42K4=; b=Py0ZF+XSaqZ79LnQLS+37KogsAYPICIuHnQS28Mhmmu7CZzONxi4W/u/N+0XB78T9R f+i26EeFz3Ro7oKX8oa5S96IBz1PAfjMxeQjdl3XHwKlYBTbwULBs9H/XFJvz6JUfgKz +CSh7RdhMS93iRADU1+CPC1sXLLVjLPO+TWoPR3TswH5YriSZyBfi08xVrzNXW3Qfp+3 VKxezRdJTOZvAjnSvPh+8IfPvRfd+PZ9TObodwMbAdalEPm+OiPT2kxZG6wfax5JEl5H yfr6r/h78sKi8wR1mHoOFIn4S4G4Ig+555o84TM5XnTR4uAJutiv8DHHiANCnxwItM3w 1lIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kr45DvDPV9kAMuPBe/uZxzAIPMnzkEPOCxGH8WE42K4=; b=Ld9lKmasL61SFTy+JfHbthPrfWoDpLVxtg7hQzPzt8fKADubDn1YcvDUrJl/YS5NjO KP7mGrutp+MvoD7cMfDs5yogDW6VeDTEvge9wzmtXOEnzG6MV9tzNdDK/uCOE/vzAbfg u8xJSCmuUWNZUs+0EFTKAnrEug+ETQtvMPrkZe0pE947rtaSzoJaw5bLOR0/g3XMCFNn W912VBHJ/pb8QVzlT0L75UsaX1yHOHdd5YLEVE6nWFKx/+rTNZnG1m2s+zNqryXyGmTj rv0mdcAvR5WDreXYw/1pTvX4dCmFL4Ouuz7e6k+c/ndSkAV7cCU9syNKs82xeT5rJfN8 PMhw== X-Gm-Message-State: AEkoouth5SpXUhE8AcRpPbsuqz4xrjPf22ggr1IBXxwi1O64M2IGHQl7yWr1AO0qWsbjbw== X-Received: by 10.200.42.61 with SMTP id k58mr2295868qtk.122.1471526125195; Thu, 18 Aug 2016 06:15:25 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id u76sm993443qkl.39.2016.08.18.06.15.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Aug 2016 06:15:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 18 Aug 2016 09:15:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 13:15:29 -0000 We=E2=80=99ll work up an example. There is no restriction on an INFO carrying body parts not associated = with the INFO. In this case, we would have a body part associated with = the Call-Info CID (the MSD), as well as the body part that is associated = with the INFO (the ack). As per the prior message, the MSD wouldn=E2=80=99= t be limited to to the ACK INFO, even if it usually occurred there. Brian > On Aug 18, 2016, at 2:23 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > Please see my reply inline. But, I=C2=B9d like you to send an INFO = example > according to your example, to make sure we are talking about the same > thing. >=20 >> You are missing the point of the suggested compromise. >>=20 >> This is NOT a legacy INFO. It=C2=B9s a new-style INFO package, = conforming to >> 6086. >>=20 >> There is only ONE INFO part. It only carries the metadata/control = block, >> and its ACK. >>=20 >> You send an INFO, with the metadata/control body part, with the = proper >> INFO mime type and content disposition. The MSD/VEDS is not there. >> You send the MSD/VEDS as Additional Data, in a separate body part, = with >> the additional data MIME type and content disposition using = Call-Info. >>=20 >> So there are two parts in the body. One is the INFO block, the other = is >> the Additional Data block, with the Call-Info header pointing to it. = The >> latter isn=C2=B9t legacy use of INFO, it=C2=B9s permitted use of = Call-Info. 6069 >> expressly permits this. >=20 >=20 > While RFC 6086 does allow usage of other C-D values than = =C2=B3info-package=C2=B2 > for specific body parts, the body parts are still associated with the = Info > Package - which means you know the semantics, and you know that the > receiver will support the body part. So, I still don=C2=B9t see what = you need > Call-Info for? >=20 > Yes, 6086 does contain an example where one body part is not = associated > with the Info Package to begin with. But, again, that is to address = legacy > usages of INFO. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >>=20 >>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>> I thought we discussed usage of legacy (non-Info-Package) INFOs >>> already. RFC 6086 allows it for backward compatibility. Any new = usage >>> MUST use an Info Package. >>>=20 >>> And, even if it was allowed, using two different INFO mechanisms = would >>> make things even more complicated. >>>=20 >>> I'll let others decide on whether MSD is considered additional data = or >>> not, but I don't think it's relevant because additional data is not = a >>> legacy INFO usage, nor does additional data update RFC 6086. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>> -----Original Message----- >>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>> Sent: 17 August 2016 23:57 >>> To: Christer Holmberg ; Paul Kyzivat >>> ; Drage, Keith (Nokia - GB) >>> ; ecrit@ietf.org; Brian Rosen >>> >>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info = usage >>> brings no value) >>>=20 >>> Hi Everyone, >>>=20 >>> The authors wish to propose a solution to the concerns that have = been >>> raised. We recognize that the vehicle data (MSD for eCall and VEDS = for >>> car-crash) is properly considered additional data in the context of = RFC >>> 7852, while the metadata/control block can be considered its own >>> request/response protocol. With that in mind, our proposal is to = have >>> the INFO package associated with the metadata/control block but not = the >>> MSD nor VEDS. For a mid-call update request, the PSAP sends a >>> metadata/control block requesting an updated MSD (or VEDS) in INFO. >>> The IVS in turn sends an INFO with a metadata/control block >>> acknowledging the request with a successful result. Both INFO = messages >>> contain a metadata/control block associated with the INFO package = and >>> not referenced by a Call-Info header field. The INFO sent by the = IVS >>> also contains an updated MSD (or VEDS) as RFC 7852 additional data, >>> referenced by a Call-Info header field. There would be two body = parts >>> in the INFO from the IVS to the PSAP, each with its appropriate MIME >>> type and Content-Disposition. One body part is associated with the = INFO >>> package and is the response to the request. >>> The second body part is the updated MSD and is referenced by = Call-Info. >>> This more cleanly separates the request/response protocol from the >>> vehicle data. The request/response protocol uses INFO, is = associated >>> with an INFO package, and carries data with the Info-Package >>> Content-Disposition. INFO messages sent by the IVS may also contain >>> vehicle data not associated with the INFO package. In eCall, this >>> allows the PSAP to request a mid-call update and the IVS to respond. = In >>> car-crash, this allows the PSAP to request the vehicle to take other >>> actions (such as flashing the lights). In all cases, the vehicle >>> responds to a request with an acknowledgment (and indicates if the >>> request was successfully carried out). >>>=20 >>> Note that RFC 6086 permits INFO messages to also carry data not >>> associated with INFO packages. >>>=20 >>> This has an additional advantage of making it cleaner and easier to >>> reuse the emergency call request/response protocol later, in other >>> documents (e.g., so the PSAP can request building sensor data). >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- It is easier = to >>> fight for one's principles than to live up to them. >>> --Alfred Adler >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From nobody Thu Aug 18 06:22: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 2074512DE2E for ; Thu, 18 Aug 2016 06:22:28 -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 XbnomgQJHBPi for ; Thu, 18 Aug 2016 06:22:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 087C312DE24 for ; Thu, 18 Aug 2016 06:22:18 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-b8-57b5b68995c7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 8B.79.06563.986B5B75; Thu, 18 Aug 2016 15:22:17 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 15:22:16 +0200 From: Ivo Sedlacek To: Brian Rosen , Paul Kyzivat Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR98ZAcHBCKSc2akOhqFpsiJK/HaBNgrEAgAAXd4CAAAZrAIAAJduAgADMwgCAACJEAA== Date: Thu, 18 Aug 2016 13:22:16 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdXbdz29Zwg5YpUhZP709js2hc9JTV YsWGA6wOzB5/339g8rj/7S+7x5IlP5kCmKO4bFJSczLLUov07RK4MmacWs5csMm34uahGawN jFu8uxg5OSQETCTe3dvI1MXIxSEksJ5R4sOLJihnCaNE++RJTCBVbAJ6EhO3HGEFsUUEPCXm PpzOCGIzC6hKnGt8zAJiCwssZJR4uDwGomYRo8Ti5XIQdpjEwyXHwOawANV/fbocrJdXwFdi yvcmVohlrRwS+x98BiviFHCS6Nz6H2woo4CsxNU/vVDLxCVuPZnPBHG2gMSSPeeZIWxRiZeP /7FC2EoSjUueANkcQPWaEut36UO0KkpM6X7IDrFXUOLkzCcsExhFZyGZOguhYxaSjllIOhYw sqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIydg1t+6+5gXP3a8RCjAAejEg+vwrIt4UKs iWXFlbmHGCU4mJVEeHdv3BouxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6Yklqdmpq QWoRTJaJg1OqgdG+gGt5RWBYwr1vx/X9P08WUzhw6ddZcy8DpU8W6yqfbXm6f0es5MadiZwP 9seb72A8oBE/ReHNax4mr8AQvt377BW9XI82Lin/ocFvL3CU5f2qM/eq6pKnzv2yPfLS5ScG e9fLslzdt+CL8vRFC+qjlp0tl9/34drR6K0O3K/DehiYtS9smbBciaU4I9FQi7moOBEAFIS5 V5kCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 13:22:28 -0000 SGVsbG8sDQoNCkZyb20gbXkgcG9pbnQgb2YgdmlldywgaXQgZG9lcyBub3QgbWFrZSBzZW5zZS4g DQoNCldoeSB0byBzZW5kIHR3byBib2RpZXMgKE1TRCwgY29udHJvbCBibG9jayBmb3IgImFjayIp IGluIGFuIElORk8gcmVxdWVzdCwgaWYgc28gZmFyIHNvbGVseSBNU0Qgd2FzIGluY2x1ZGVkIGFu ZCBpcyBubyBwcm9ibGVtIHdhcyBmb3VuZD8NCg0KTW9yZW92ZXIsIGlmIHdlIGFkb3B0IFBhdWwn cyBpZGVhIHRoYXQgTVNEIGFuZCBjb250cm9sIGJsb2NrIGZvciAiYWNrIiBjYW4gcG90ZW50aWFs bHkgYmUgc2VudCBpbiB0d28gSU5GTyB0cmFuc2FjdGlvbnMsIHRoZW4gd2UgZ2V0IGFuIGFkZGl0 aW9uYWwgSU5GTyB0cmFuc2FjdGlvbi4NCg0KQW5kIGlmIHdlIG5lZWQgdG8gc2VuZCB0d28gYm9k aWVzIGFuZCB3ZSBhcmUgZGVmaW5pbmcgYW4gaW5mbyBwYWNrYWdlIHRvIHRyYW5zZmVyIHRoZW0s IHdoeSBkb24ndCB3ZSBhc3NvY2lhdGUgYm90aCBib2RpZXMgd2l0aCB0aGUgaW5mbyBwYWNrYWdl Pw0KDQpBbmQgSSBzdGlsbCBoYXZlIG5vdCBnb3QgYW4gYW5zd2VyIHRvIG15IHF1ZXN0aW9uIG9u IHdoeSBpcyB1c2luZyB0aGUgQ2FsbC1JRCBpbiBJTkZPIHJlcXVlc3Q/IFVBUyBvZiBJTkZPIHJl cXVlc3Q/IFByb3h5IGhhbmRsaW5nIElORk8gcmVxdWVzdD8NCg0KU28sIGluIHNob3J0LCB0aGlz IHByb3Bvc2FsIGJyaW5ncyBhIExPVCBvZiBjb21wbGV4aXR5IGZvciBubyBjbGVhciBiZW5lZml0 Lg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBFY3JpdCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxOCwgMjAxNiAzOjEy IFBNDQpUbzogUGF1bCBLeXppdmF0DQpDYzogZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb RWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgYWxp Z25lZCB3aXRoIFJGQzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2Fs bC1JbmZvIHVzYWdlIGJyaW5ncyBubyB2YWx1ZSkNCg0KWWVzLCB0aGF0IG1ha2VzIHNlbnNlLg0K DQpCcmlhbg0KPiBPbiBBdWcgMTcsIDIwMTYsIGF0IDg6NTkgUE0sIFBhdWwgS3l6aXZhdCA8cGt5 eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4gDQo+IE9uIDgvMTcvMTYgNjo0MyBQTSwgQnJp YW4gUm9zZW4gd3JvdGU6DQo+PiBZb3UgYXJlIG1pc3NpbmcgdGhlIHBvaW50IG9mIHRoZSBzdWdn ZXN0ZWQgY29tcHJvbWlzZS4NCj4+IA0KPj4gVGhpcyBpcyBOT1QgYSBsZWdhY3kgSU5GTy4gIEl0 4oCZcyBhIG5ldy1zdHlsZSBJTkZPIHBhY2thZ2UsIGNvbmZvcm1pbmcgdG8gNjA4Ni4NCj4+IA0K Pj4gVGhlcmUgaXMgb25seSBPTkUgSU5GTyBwYXJ0LiAgSXQgb25seSBjYXJyaWVzIHRoZSBtZXRh ZGF0YS9jb250cm9sIGJsb2NrLCBhbmQgaXRzIEFDSy4NCj4+IA0KPj4gWW91IHNlbmQgYW4gSU5G Tywgd2l0aCB0aGUgbWV0YWRhdGEvY29udHJvbCBib2R5IHBhcnQsIHdpdGggdGhlIHByb3BlciBJ TkZPIG1pbWUgdHlwZSBhbmQgY29udGVudCBkaXNwb3NpdGlvbi4gIFRoZSBNU0QvVkVEUyBpcyBu b3QgdGhlcmUuDQo+PiBZb3Ugc2VuZCB0aGUgTVNEL1ZFRFMgYXMgQWRkaXRpb25hbCBEYXRhLCBp biBhIHNlcGFyYXRlIGJvZHkgcGFydCwgd2l0aCB0aGUgYWRkaXRpb25hbCBkYXRhIE1JTUUgdHlw ZSBhbmQgY29udGVudCBkaXNwb3NpdGlvbiB1c2luZyBDYWxsLUluZm8uDQo+PiANCj4+IFNvIHRo ZXJlIGFyZSB0d28gcGFydHMgaW4gdGhlIGJvZHkuICBPbmUgaXMgdGhlIElORk8gYmxvY2ssIHRo ZSBvdGhlciBpcyB0aGUgQWRkaXRpb25hbCBEYXRhIGJsb2NrLCB3aXRoIHRoZSBDYWxsLUluZm8g aGVhZGVyIHBvaW50aW5nIHRvIGl0LiAgVGhlIGxhdHRlciBpc27igJl0IGxlZ2FjeSB1c2Ugb2Yg SU5GTywgaXTigJlzIHBlcm1pdHRlZCB1c2Ugb2YgQ2FsbC1JbmZvLiAgNjA2OSBleHByZXNzbHkg cGVybWl0cyB0aGlzLg0KPj4gDQo+PiBNU0QgaXMgbW9zdCBkZWZpbml0ZWx5IEFkZGl0aW9uYWwg RGF0YSwgYXMgaXQgaXMgaG93IGl0IGlzIHNlbnQgaW4gdGhlIGluaXRpYWwgSU5WSVRFLiAgU2Ft ZSBkYXRhLCBzYW1lIE1JTUUsIHNhbWUgRGlzcG9zaXRpb24uICBUaGUgcG9pbnQgd2UgYXJlIG1h a2luZyBpcyB0aGF0IHRoZSBJTkZPIGlzIHRoZSBjb21tYW5kL2NvbnRyb2wgbWVjaGFuaXNtLiAg VGhlIENhbGwtSW5mbyBjYXJyaWVzIHRoZSBWRURTL01TRCwgd2hldGhlciBpdOKAmXMgb24gYW4g SU5WSVRFIG9yIGFuIElORk8uICBUaGUgSU5GTyBwYWNrYWdlIGhhcyB0aGUgY29tbWFuZCBhbmQg aXTigJlzIHJlc3BvbnNlICh0aGUgQUNLKS4NCj4gDQo+IFllcywgdGhhdCBJIGhvdyBJIHVuZGVy c3Rvb2QgdGhlIHByb3Bvc2FsLg0KPiANCj4gQW5kIElNTyBpdCBpcyBhIHZhbGlkIHRoaW5nIHRv IGRvLiAoSSdtIHByZXR0eSBzdXJlIEkgZGlkIG1lbnRpb24gYW4gYXBwcm9hY2ggbGlrZSB0aGlz IGFsb25nIHRoZSB3YXksIGJ1dCBpdCBnb3QgbG9zdCBhbG9uZyB0aGUgd2F5LikNCj4gDQo+IFRo aXMgc2VlbXMgcGxhdXNpYmxlIHRvIG1lLg0KPiANCj4gSSB3b3VsZCB0aGVuIHN1Z2dlc3QgdGhh dCB0aGUgd2hpbGUgdGhlcmUgY2FuIHRoZW4gYmUgYW4gSU5GTyB3aXRoIGEgYm9keSB0aGF0IHJl cXVlc3RzIHRoZSBzZW5kaW5nIG9mIEFkZGl0aW9uYWwgRGF0YSwgdGhlcmUgc2hvdWxkbid0IGJl IGEgKnJlcXVpcmVtZW50KiB0aGF0IHRoZSBBZGRpdGlvbmFsIERhdGEgY29tZSBpbiB0aGUgc2Ft ZSBJTkZPIHRoYXQgY2FycmllcyB0aGUgQUNLIHRvIHRoYXQgcmVxdWVzdC4gSXQgbWlnaHQgKnR5 cGljYWxseSogY29tZSB0aGVyZSwgYmVjYXVzZSBpdCBpcyBhIGNvbnZlbmllbnQgbWVzc2FnZSB0 aGF0IGhhcHBlbnMgdG8gYmUgZ29pbmcgb3V0IGF0IHRoZSByaWdodCB0aW1lLiBCdXQgaXQgKm1p Z2h0KiBoYXBwZW4gdG8gZ28gaW4gc29tZSBvdGhlciBtZXNzYWdlIC0gYSBkaWZmZXJlbnQgSU5G TywgY29udGFpbmluZyBzb21lIG90aGVyIG1ldGFkYXRhLCBvciBhIHJlSU5WSVRFIHRoYXQgaGFw cGVucyB0byBiZSBuZWVkZWQgZm9yIHNvbWUgcmVhc29uLCBvciB3aGF0ZXZlci4gVGhpcyBkZWNv dXBsZXMgdGhlIHR3byB1c2FnZXMuDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0KPiANCj4+IA0K Pj4+IE9uIEF1ZyAxNywgMjAxNiwgYXQgNjoyMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+ Pj4gSSB0aG91Z2h0IHdlIGRpc2N1c3NlZCB1c2FnZSBvZiBsZWdhY3kgKG5vbi1JbmZvLVBhY2th Z2UpIElORk9zIGFscmVhZHkuIFJGQyA2MDg2IGFsbG93cyBpdCBmb3IgYmFja3dhcmQgY29tcGF0 aWJpbGl0eS4gQW55IG5ldyB1c2FnZSBNVVNUIHVzZSBhbiBJbmZvIFBhY2thZ2UuDQo+Pj4gDQo+ Pj4gQW5kLCBldmVuIGlmIGl0IHdhcyBhbGxvd2VkLCB1c2luZyB0d28gZGlmZmVyZW50IElORk8g bWVjaGFuaXNtcyB3b3VsZCBtYWtlIHRoaW5ncyBldmVuIG1vcmUgY29tcGxpY2F0ZWQuDQo+Pj4g DQo+Pj4gSSdsbCBsZXQgb3RoZXJzIGRlY2lkZSBvbiB3aGV0aGVyIE1TRCBpcyBjb25zaWRlcmVk IGFkZGl0aW9uYWwgZGF0YSBvciBub3QsIGJ1dCBJIGRvbid0IHRoaW5rIGl0J3MgcmVsZXZhbnQg YmVjYXVzZSBhZGRpdGlvbmFsIGRhdGEgaXMgbm90IGEgbGVnYWN5IElORk8gdXNhZ2UsIG5vciBk b2VzIGFkZGl0aW9uYWwgZGF0YSB1cGRhdGUgUkZDIDYwODYuDQo+Pj4gDQo+Pj4gUmVnYXJkcywN Cj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gRnJvbTogUmFuZGFsbCBHZWxsZW5zIFttYWlsdG86cmcraWV0ZkByYW5keS5w ZW5zaXZlLm9yZ10NCj4+PiBTZW50OiAxNyBBdWd1c3QgMjAxNiAyMzo1Nw0KPj4+IFRvOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIDxr ZWl0aC5kcmFnZUBub2tpYS5jb20+OyBlY3JpdEBpZXRmLm9yZzsgQnJpYW4gUm9zZW4gPEJyaWFu LlJvc2VuQG5ldXN0YXIuYml6Pg0KPj4+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYt ZWNyaXQtZWNhbGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgYWxpZ25lZCB3aXRoIFJGQzMyNjEg KHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIGJyaW5n cyBubyB2YWx1ZSkNCj4+PiANCj4+PiBIaSBFdmVyeW9uZSwNCj4+PiANCj4+PiBUaGUgYXV0aG9y cyB3aXNoIHRvIHByb3Bvc2UgYSBzb2x1dGlvbiB0byB0aGUgY29uY2VybnMgdGhhdCBoYXZlIGJl ZW4gcmFpc2VkLiAgV2UgcmVjb2duaXplIHRoYXQgdGhlIHZlaGljbGUgZGF0YSAoTVNEIGZvciBl Q2FsbCBhbmQgVkVEUyBmb3IgY2FyLWNyYXNoKSBpcyBwcm9wZXJseSBjb25zaWRlcmVkIGFkZGl0 aW9uYWwgZGF0YSBpbiB0aGUgY29udGV4dCBvZiBSRkMgNzg1Miwgd2hpbGUgdGhlIG1ldGFkYXRh L2NvbnRyb2wgYmxvY2sgY2FuIGJlIGNvbnNpZGVyZWQgaXRzIG93biByZXF1ZXN0L3Jlc3BvbnNl IHByb3RvY29sLiAgV2l0aCB0aGF0IGluIG1pbmQsIG91ciBwcm9wb3NhbCBpcyB0byBoYXZlIHRo ZSBJTkZPIHBhY2thZ2UgYXNzb2NpYXRlZCB3aXRoIHRoZSBtZXRhZGF0YS9jb250cm9sIGJsb2Nr IGJ1dCBub3QgdGhlIE1TRCBub3IgVkVEUy4gIEZvciBhIG1pZC1jYWxsIHVwZGF0ZSByZXF1ZXN0 LCB0aGUgUFNBUCBzZW5kcyBhIG1ldGFkYXRhL2NvbnRyb2wgYmxvY2sgcmVxdWVzdGluZyBhbiB1 cGRhdGVkIE1TRCAob3IgVkVEUykgaW4gSU5GTy4NCj4+PiBUaGUgSVZTIGluIHR1cm4gc2VuZHMg YW4gSU5GTyB3aXRoIGEgbWV0YWRhdGEvY29udHJvbCBibG9jayBhY2tub3dsZWRnaW5nIHRoZSBy ZXF1ZXN0IHdpdGggYSBzdWNjZXNzZnVsIHJlc3VsdC4gIEJvdGggSU5GTyBtZXNzYWdlcyBjb250 YWluIGEgbWV0YWRhdGEvY29udHJvbCBibG9jayBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gcGFj a2FnZSBhbmQgbm90IHJlZmVyZW5jZWQgYnkgYSBDYWxsLUluZm8gaGVhZGVyIGZpZWxkLiAgVGhl IElORk8gc2VudCBieSB0aGUgSVZTIGFsc28gY29udGFpbnMgYW4gdXBkYXRlZCBNU0QgKG9yIFZF RFMpIGFzIFJGQyA3ODUyIGFkZGl0aW9uYWwgZGF0YSwgcmVmZXJlbmNlZCBieSBhIENhbGwtSW5m byBoZWFkZXIgZmllbGQuICBUaGVyZSB3b3VsZCBiZSB0d28gYm9keSBwYXJ0cyBpbiB0aGUgSU5G TyBmcm9tIHRoZSBJVlMgdG8gdGhlIFBTQVAsIGVhY2ggd2l0aCBpdHMgYXBwcm9wcmlhdGUgTUlN RSB0eXBlIGFuZCBDb250ZW50LURpc3Bvc2l0aW9uLiAgT25lIGJvZHkgcGFydCBpcyBhc3NvY2lh dGVkIHdpdGggdGhlIElORk8gcGFja2FnZSBhbmQgaXMgdGhlIHJlc3BvbnNlIHRvIHRoZSByZXF1 ZXN0Lg0KPj4+IFRoZSBzZWNvbmQgYm9keSBwYXJ0IGlzIHRoZSB1cGRhdGVkIE1TRCBhbmQgaXMg cmVmZXJlbmNlZCBieSBDYWxsLUluZm8uICBUaGlzIG1vcmUgY2xlYW5seSBzZXBhcmF0ZXMgdGhl IHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgZnJvbSB0aGUgdmVoaWNsZSBkYXRhLiAgVGhlIHJl cXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgdXNlcyBJTkZPLCBpcyBhc3NvY2lhdGVkIHdpdGggYW4g SU5GTyBwYWNrYWdlLCBhbmQgY2FycmllcyBkYXRhIHdpdGggdGhlIEluZm8tUGFja2FnZSBDb250 ZW50LURpc3Bvc2l0aW9uLiAgSU5GTyBtZXNzYWdlcyBzZW50IGJ5IHRoZSBJVlMgbWF5IGFsc28g Y29udGFpbiB2ZWhpY2xlIGRhdGEgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5GTyBwYWNrYWdl LiAgSW4gZUNhbGwsIHRoaXMgYWxsb3dzIHRoZSBQU0FQIHRvIHJlcXVlc3QgYSBtaWQtY2FsbCB1 cGRhdGUgYW5kIHRoZSBJVlMgdG8gcmVzcG9uZC4gSW4gY2FyLWNyYXNoLCB0aGlzIGFsbG93cyB0 aGUgUFNBUCB0byByZXF1ZXN0IHRoZSB2ZWhpY2xlIHRvIHRha2Ugb3RoZXIgYWN0aW9ucyAoc3Vj aCBhcyBmbGFzaGluZyB0aGUgbGlnaHRzKS4gIEluIGFsbCBjYXNlcywgdGhlIHZlaGljbGUgcmVz cG9uZHMgdG8gYSByZXF1ZXN0IHdpdGggYW4gYWNrbm93bGVkZ21lbnQgKGFuZCBpbmRpY2F0ZXMg aWYgdGhlIHJlcXVlc3Qgd2FzIHN1Y2Nlc3NmdWxseSBjYXJyaWVkIG91dCkuDQo+Pj4gDQo+Pj4g Tm90ZSB0aGF0IFJGQyA2MDg2IHBlcm1pdHMgSU5GTyBtZXNzYWdlcyB0byBhbHNvIGNhcnJ5IGRh dGEgbm90IGFzc29jaWF0ZWQgd2l0aCBJTkZPIHBhY2thZ2VzLg0KPj4+IA0KPj4+IFRoaXMgaGFz IGFuIGFkZGl0aW9uYWwgYWR2YW50YWdlIG9mIG1ha2luZyBpdCBjbGVhbmVyIGFuZCBlYXNpZXIg dG8gcmV1c2UgdGhlIGVtZXJnZW5jeSBjYWxsIHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgbGF0 ZXIsIGluIG90aGVyIGRvY3VtZW50cyAoZS5nLiwgc28gdGhlIFBTQVAgY2FuIHJlcXVlc3QgYnVp bGRpbmcgc2Vuc29yIGRhdGEpLg0KPj4+IA0KPj4+IC0tDQo+Pj4gUmFuZGFsbCBHZWxsZW5zDQo+ Pj4gT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVh ayBmb3IgbXlzZWxmIG9ubHkNCj4+PiAtLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0 YWc6IC0tLS0tLS0tLS0tLS0tLSBJdCBpcyBlYXNpZXIgdG8gZmlnaHQgZm9yIG9uZSdzIHByaW5j aXBsZXMgdGhhbiB0byBsaXZlIHVwIHRvIHRoZW0uDQo+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tQWxmcmVkIEFkbGVyDQo+Pj4gDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBFY3JpdCBt YWlsaW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+IA0KPj4gDQo+IA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3Jp dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From nobody Thu Aug 18 08:43: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 D20A212DE2C for ; Thu, 18 Aug 2016 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 KYgKcABNaWSD for ; Thu, 18 Aug 2016 08:43:43 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 793B712DA9F for ; Thu, 18 Aug 2016 08:43:43 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w38so9907623qtb.0 for ; Thu, 18 Aug 2016 08:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OKkCvl8rcVG+BGRRCoohv66yjzo1QR6yR4a8BlQZp2M=; b=zpUXgf2g0hzliYfxVcRCroxS78nc09kg97IGeFpX+hrEMjMBZ64o4M5xm++YOAZHTt AktQ+E+ny8SzBoxqYQmrE45YBpHUJyZTmQP543ORE0iiggD/P4npDWfRxFPwkkMgCw+i KXm1+jGK1r6OT1vDkhViAF6epVwzvyxK1xbKme5rE/hnyWMmIlwPLl7yYusNocD+P+ka C2t/3wlevai/nKbDzadGEe3mftU84Z1GZwkdCxowWmIosqqAN/pXF/Kweet/x11D2r6/ 4eDVp8ng84TrwQp0TeoDR8B3mjCEx14MsoEtP2MCH1G/YPwPtI81T5Ou8dkkg/IEoAyf M+jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OKkCvl8rcVG+BGRRCoohv66yjzo1QR6yR4a8BlQZp2M=; b=kaul0r7lA9BVaNux7nM/KtPMkah9sKFbmCKL9j2fzA/cgXSSoSyfayVISgZtG9B4Bh Dfol+vn3i3Y7htN8WZA3EI2lDLC/CapOtz4+ppETtTcvp9WXQfAesUA5B9p0viiijuBk nDoKhvVOBmsR8AmpNQ6JBvL8xbb2lImNMTu1uLQOmjPLx9wqDLYvVJ97VQsoTKMPgHNG QhJRx7TecI2H2De84IYrFKaFCplja71FEFpcPLufxmJC2a9NcV6h4Ukr2xs8WC/6lWXR BRYpV0WWSidrQuEbBmewH+jsBVYLmRj5D8YOjDSwihN1OO2PghPIe16765U03qd3n8jd k7Qw== X-Gm-Message-State: AEkoouuROg/RwHYDPXWsScZJ8e4vWptt8hutYCa9NPt78ekw7MV7HoFbtgC+b2aFx2aPZQ== X-Received: by 10.200.56.35 with SMTP id q32mr3219452qtb.32.1471535022436; Thu, 18 Aug 2016 08:43:42 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id p76sm1325341qkl.48.2016.08.18.08.43.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Aug 2016 08:43:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> Date: Thu, 18 Aug 2016 11:43:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 15:43:47 -0000 Ivo Please try to look at this from a wider perspective. You are = concentrating on very limited example of a more general problem of PSAPs = being able to manage data being sent to them from a device. The MSD comes in more than one way: unsolicited, and requested. The = data block, the MSD itself, is the same. Its use is the same. The XML = is the same. It IS Additional Data. The command we send to request in mid call is an active command/control = and response protocol that has a much bigger use than just eCall. There = are many examples of this, including the one Randall mentioned: getting = environmental information from a building. I can give you plenty of = others, for example, you may be able to control the elevators of that = building, or a container may have some kind of leak detector that you = want an update from.=20 This command/control mechanism needs to be standardized, independently = of eCall, but we=E2=80=99re not going to try to do that in this = document. All we want to do is separate the piece that very clearly is = Additional Data, from the command/control and it=E2=80=99s Ack/Nak = response. Since we recognize that any other instance of command/control = that is mid call initiated would need its own INFO package, we don=E2=80=99= t need to do much to make eCall an instance of a more general = command/control mechanism. We propose to use Call-Info to =E2=80=9Clabel=E2=80=9D the MSD so that = all instances of this data is treated as Additional Data, which it very = clearly is. =20 With respect to UAS and Proxy issues, again, please consider that eCall = is a very limited example of a much bigger problem. Consider, for = example, if a call was dropped, and the PSAP called the vehicle back. = We would like to be able to request the MSD, but now the caller is the = PSAP. I don=E2=80=99t think a proxy would have any problems with, or = would do anything with the INFO package other than forward it like any = other INFO. The same as is would with Call-Info. The only complexity is two MIME body parts and the Call-Info header. = Yeah, that=E2=80=99s more, three lines, and a little extra processing. =20= This is a compromise between what authors want and you want. Please = reconsider. Brian > On Aug 18, 2016, at 9:22 AM, Ivo Sedlacek = wrote: >=20 > Hello, >=20 > =46rom my point of view, it does not make sense.=20 >=20 > Why to send two bodies (MSD, control block for "ack") in an INFO = request, if so far solely MSD was included and is no problem was found? >=20 > Moreover, if we adopt Paul's idea that MSD and control block for "ack" = can potentially be sent in two INFO transactions, then we get an = additional INFO transaction. >=20 > And if we need to send two bodies and we are defining an info package = to transfer them, why don't we associate both bodies with the info = package? >=20 > And I still have not got an answer to my question on why is using the = Call-ID in INFO request? UAS of INFO request? Proxy handling INFO = request? >=20 > So, in short, this proposal brings a LOT of complexity for no clear = benefit. >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Thursday, August 18, 2016 3:12 PM > To: Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage = brings no value) >=20 > Yes, that makes sense. >=20 > Brian >> On Aug 17, 2016, at 8:59 PM, Paul Kyzivat = wrote: >>=20 >> On 8/17/16 6:43 PM, Brian Rosen wrote: >>> You are missing the point of the suggested compromise. >>>=20 >>> This is NOT a legacy INFO. It=E2=80=99s a new-style INFO package, = conforming to 6086. >>>=20 >>> There is only ONE INFO part. It only carries the metadata/control = block, and its ACK. >>>=20 >>> You send an INFO, with the metadata/control body part, with the = proper INFO mime type and content disposition. The MSD/VEDS is not = there. >>> You send the MSD/VEDS as Additional Data, in a separate body part, = with the additional data MIME type and content disposition using = Call-Info. >>>=20 >>> So there are two parts in the body. One is the INFO block, the = other is the Additional Data block, with the Call-Info header pointing = to it. The latter isn=E2=80=99t legacy use of INFO, it=E2=80=99s = permitted use of Call-Info. 6069 expressly permits this. >>>=20 >>> MSD is most definitely Additional Data, as it is how it is sent in = the initial INVITE. Same data, same MIME, same Disposition. The point = we are making is that the INFO is the command/control mechanism. The = Call-Info carries the VEDS/MSD, whether it=E2=80=99s on an INVITE or an = INFO. The INFO package has the command and it=E2=80=99s response (the = ACK). >>=20 >> Yes, that I how I understood the proposal. >>=20 >> And IMO it is a valid thing to do. (I'm pretty sure I did mention an = approach like this along the way, but it got lost along the way.) >>=20 >> This seems plausible to me. >>=20 >> I would then suggest that the while there can then be an INFO with a = body that requests the sending of Additional Data, there shouldn't be a = *requirement* that the Additional Data come in the same INFO that = carries the ACK to that request. It might *typically* come there, = because it is a convenient message that happens to be going out at the = right time. But it *might* happen to go in some other message - a = different INFO, containing some other metadata, or a reINVITE that = happens to be needed for some reason, or whatever. This decouples the = two usages. >>=20 >> Thanks, >> Paul >>=20 >>>=20 >>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I thought we discussed usage of legacy (non-Info-Package) INFOs = already. RFC 6086 allows it for backward compatibility. Any new usage = MUST use an Info Package. >>>>=20 >>>> And, even if it was allowed, using two different INFO mechanisms = would make things even more complicated. >>>>=20 >>>> I'll let others decide on whether MSD is considered additional data = or not, but I don't think it's relevant because additional data is not a = legacy INFO usage, nor does additional data update RFC 6086. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 17 August 2016 23:57 >>>> To: Christer Holmberg ; Paul = Kyzivat ; Drage, Keith (Nokia - GB) = ; ecrit@ietf.org; Brian Rosen = >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not = aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage = brings no value) >>>>=20 >>>> Hi Everyone, >>>>=20 >>>> The authors wish to propose a solution to the concerns that have = been raised. We recognize that the vehicle data (MSD for eCall and VEDS = for car-crash) is properly considered additional data in the context of = RFC 7852, while the metadata/control block can be considered its own = request/response protocol. With that in mind, our proposal is to have = the INFO package associated with the metadata/control block but not the = MSD nor VEDS. For a mid-call update request, the PSAP sends a = metadata/control block requesting an updated MSD (or VEDS) in INFO. >>>> The IVS in turn sends an INFO with a metadata/control block = acknowledging the request with a successful result. Both INFO messages = contain a metadata/control block associated with the INFO package and = not referenced by a Call-Info header field. The INFO sent by the IVS = also contains an updated MSD (or VEDS) as RFC 7852 additional data, = referenced by a Call-Info header field. There would be two body parts = in the INFO from the IVS to the PSAP, each with its appropriate MIME = type and Content-Disposition. One body part is associated with the INFO = package and is the response to the request. >>>> The second body part is the updated MSD and is referenced by = Call-Info. This more cleanly separates the request/response protocol = from the vehicle data. The request/response protocol uses INFO, is = associated with an INFO package, and carries data with the Info-Package = Content-Disposition. INFO messages sent by the IVS may also contain = vehicle data not associated with the INFO package. In eCall, this = allows the PSAP to request a mid-call update and the IVS to respond. In = car-crash, this allows the PSAP to request the vehicle to take other = actions (such as flashing the lights). In all cases, the vehicle = responds to a request with an acknowledgment (and indicates if the = request was successfully carried out). >>>>=20 >>>> Note that RFC 6086 permits INFO messages to also carry data not = associated with INFO packages. >>>>=20 >>>> This has an additional advantage of making it cleaner and easier to = reuse the emergency call request/response protocol later, in other = documents (e.g., so the PSAP can request building sensor data). >>>>=20 >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself = only >>>> -------------- Randomly selected tag: --------------- It is easier = to fight for one's principles than to live up to them. >>>> --Alfred Adler >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 18 08:49:45 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 61D2112D1CA for ; Thu, 18 Aug 2016 08:49:44 -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 Jfy6O-sbCzv2 for ; Thu, 18 Aug 2016 08:49:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8249112DC34 for ; Thu, 18 Aug 2016 08:49:40 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-50-57b5d912091d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 9E.5F.04209.219D5B75; Thu, 18 Aug 2016 17:49:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 17:49:37 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+NjjpZHpzYRry0e+Ak1CeiTcHKBOUiYAgAA/xwCAAEvh0A== Date: Thu, 18 Aug 2016 15:49:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> In-Reply-To: <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7ma7Qza3hBrdnaFg8vT+NzaJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB53P/2l91jyZKfTB53b11i8th65zFLAGsUl01Kak5m WWqRvl0CV8aNdx/YC+65VNxY9pyxgfGPUxcjJ4eEgInEuzkPWLsYuTiEBNYzSvROecQGkhAS WMIoMe96RBcjBwebgIVE9z9tkLCIgLLEzlud7CA2s8BGRoknC8VAbGGBhYwSD5fHQNQsYpRY vFwOwnaSuHzoM9hIFgFVie3vfjKB2LwCvhKNc7cyQaxq4JD4sE8IxOYEqp+zbSMriM0oICbx /dQaJohd4hK3nsxngrhZQGLJnvPMELaoxMvH/1ghbCWJxiVPWEFOZhbQlFi/Sx+iVVFiSvdD doi1ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmB0HdzyW3UH4+U3jocYBTgYlXh4FZZtCRdiTSwrrsw9xCjBwawkwpt3fWu4EG9KYmVValF+ fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBkYlyZuVEyJVZHarGTMKiOuI H2+xW3bF+cKiRUuXpa2Tj7/h4podHNFsGTfDkFt36Q5jR6+Sl98eO1kHHbd01E6bI90WWLvm e4JAgtFBHZajd2PPnYhlbPzxVGD6xqvlbzQz9RVrAg1E6gWbzFfXMDz6vP46v5VC3mp2NZ0o 5R3bq81KQ76cUmIpzkg01GIuKk4EAHi+0pyqAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 15:49:44 -0000 SGksDQoNCj4gV2XigJlsbCB3b3JrIHVwIGFuIGV4YW1wbGUuDQo+DQo+IFRoZXJlIGlzIG5vIHJl c3RyaWN0aW9uIG9uIGFuIElORk8gY2FycnlpbmcgYm9keSBwYXJ0cyBub3QgYXNzb2NpYXRlZCB3 aXRoIHRoZSBJTkZPLg0KDQpUaGVyZSBpcyBhIHJlc3RyaWN0aW9uIHNheWluZyB0aGF0IGFueSBu ZXcgSU5GTyB1c2FnZSBtdXN0IHVzZSB0aGUgaW5mbyBwYWNrYWdlIG1lY2hhbmlzbS4NCg0KVGhl IG9ubHkgcmVhc29uIFJGQyA2MDg2IGFsbG93cyBjYXJyeWluZyBib2R5IHBhcnRzIG5vdCBhc3Nv Y2lhdGVkIHdpdGggYW4gaW5mbyBwYWNrYWdlIGlzIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IHdpdGggbGVnYWN5IElORk8gdXNhZ2VzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCiAg SW4gdGhpcyBjYXNlLCB3ZSB3b3VsZCBoYXZlIGEgYm9keSBwYXJ0IGFzc29jaWF0ZWQgd2l0aCB0 aGUgQ2FsbC1JbmZvIENJRCAodGhlIE1TRCksIGFzIHdlbGwgYXMgdGhlIGJvZHkgcGFydCB0aGF0 IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5GTyAodGhlIGFjaykuICBBcyBwZXIgdGhlIHByaW9y IG1lc3NhZ2UsIHRoZSBNU0Qgd291bGRu4oCZdCBiZSBsaW1pdGVkIHRvIHRvIHRoZSBBQ0sgSU5G TywgZXZlbiBpZiBpdCB1c3VhbGx5IG9jY3VycmVkIHRoZXJlLg0KDQpCcmlhbg0KPiBPbiBBdWcg MTgsIDIwMTYsIGF0IDI6MjMgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBQbGVhc2Ugc2VlIG15IHJl cGx5IGlubGluZS4gQnV0LCBJwrlkIGxpa2UgeW91IHRvIHNlbmQgYW4gSU5GTyBleGFtcGxlIA0K PiBhY2NvcmRpbmcgdG8geW91ciBleGFtcGxlLCB0byBtYWtlIHN1cmUgd2UgYXJlIHRhbGtpbmcg YWJvdXQgdGhlIHNhbWUgDQo+IHRoaW5nLg0KPiANCj4+IFlvdSBhcmUgbWlzc2luZyB0aGUgcG9p bnQgb2YgdGhlIHN1Z2dlc3RlZCBjb21wcm9taXNlLg0KPj4gDQo+PiBUaGlzIGlzIE5PVCBhIGxl Z2FjeSBJTkZPLiAgSXTCuXMgYSBuZXctc3R5bGUgSU5GTyBwYWNrYWdlLCBjb25mb3JtaW5nIA0K Pj4gdG8gNjA4Ni4NCj4+IA0KPj4gVGhlcmUgaXMgb25seSBPTkUgSU5GTyBwYXJ0LiAgSXQgb25s eSBjYXJyaWVzIHRoZSBtZXRhZGF0YS9jb250cm9sIA0KPj4gYmxvY2ssIGFuZCBpdHMgQUNLLg0K Pj4gDQo+PiBZb3Ugc2VuZCBhbiBJTkZPLCB3aXRoIHRoZSBtZXRhZGF0YS9jb250cm9sIGJvZHkg cGFydCwgd2l0aCB0aGUgDQo+PiBwcm9wZXIgSU5GTyBtaW1lIHR5cGUgYW5kIGNvbnRlbnQgZGlz cG9zaXRpb24uICBUaGUgTVNEL1ZFRFMgaXMgbm90IHRoZXJlLg0KPj4gWW91IHNlbmQgdGhlIE1T RC9WRURTIGFzIEFkZGl0aW9uYWwgRGF0YSwgaW4gYSBzZXBhcmF0ZSBib2R5IHBhcnQsIA0KPj4g d2l0aCB0aGUgYWRkaXRpb25hbCBkYXRhIE1JTUUgdHlwZSBhbmQgY29udGVudCBkaXNwb3NpdGlv biB1c2luZyBDYWxsLUluZm8uDQo+PiANCj4+IFNvIHRoZXJlIGFyZSB0d28gcGFydHMgaW4gdGhl IGJvZHkuICBPbmUgaXMgdGhlIElORk8gYmxvY2ssIHRoZSBvdGhlciANCj4+IGlzIHRoZSBBZGRp dGlvbmFsIERhdGEgYmxvY2ssIHdpdGggdGhlIENhbGwtSW5mbyBoZWFkZXIgcG9pbnRpbmcgdG8g DQo+PiBpdC4gIFRoZSBsYXR0ZXIgaXNuwrl0IGxlZ2FjeSB1c2Ugb2YgSU5GTywgaXTCuXMgcGVy bWl0dGVkIHVzZSBvZiANCj4+IENhbGwtSW5mby4gIDYwNjkgZXhwcmVzc2x5IHBlcm1pdHMgdGhp cy4NCj4gDQo+IA0KPiBXaGlsZSBSRkMgNjA4NiBkb2VzIGFsbG93IHVzYWdlIG9mIG90aGVyIEMt RCB2YWx1ZXMgdGhhbiANCj4gwrNpbmZvLXBhY2thZ2XCsiBmb3Igc3BlY2lmaWMgYm9keSBwYXJ0 cywgdGhlIGJvZHkgcGFydHMgYXJlIHN0aWxsIA0KPiBhc3NvY2lhdGVkIHdpdGggdGhlIEluZm8g UGFja2FnZSAtIHdoaWNoIG1lYW5zIHlvdSBrbm93IHRoZSBzZW1hbnRpY3MsIA0KPiBhbmQgeW91 IGtub3cgdGhhdCB0aGUgcmVjZWl2ZXIgd2lsbCBzdXBwb3J0IHRoZSBib2R5IHBhcnQuIFNvLCBJ IHN0aWxsIA0KPiBkb27CuXQgc2VlIHdoYXQgeW91IG5lZWQgQ2FsbC1JbmZvIGZvcj8NCj4gDQo+ IFllcywgNjA4NiBkb2VzIGNvbnRhaW4gYW4gZXhhbXBsZSB3aGVyZSBvbmUgYm9keSBwYXJ0IGlz IG5vdCANCj4gYXNzb2NpYXRlZCB3aXRoIHRoZSBJbmZvIFBhY2thZ2UgdG8gYmVnaW4gd2l0aC4g QnV0LCBhZ2FpbiwgdGhhdCBpcyB0byANCj4gYWRkcmVzcyBsZWdhY3kgdXNhZ2VzIG9mIElORk8u DQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4+IA0KPj4+IE9u IEF1ZyAxNywgMjAxNiwgYXQgNjoyMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgDQo+Pj4gPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+ Pj4gSSB0aG91Z2h0IHdlIGRpc2N1c3NlZCB1c2FnZSBvZiBsZWdhY3kgKG5vbi1JbmZvLVBhY2th Z2UpIElORk9zIA0KPj4+IGFscmVhZHkuIFJGQyA2MDg2IGFsbG93cyBpdCBmb3IgYmFja3dhcmQg Y29tcGF0aWJpbGl0eS4gQW55IG5ldyANCj4+PiB1c2FnZSBNVVNUIHVzZSBhbiBJbmZvIFBhY2th Z2UuDQo+Pj4gDQo+Pj4gQW5kLCBldmVuIGlmIGl0IHdhcyBhbGxvd2VkLCB1c2luZyB0d28gZGlm ZmVyZW50IElORk8gbWVjaGFuaXNtcyANCj4+PiB3b3VsZCBtYWtlIHRoaW5ncyBldmVuIG1vcmUg Y29tcGxpY2F0ZWQuDQo+Pj4gDQo+Pj4gSSdsbCBsZXQgb3RoZXJzIGRlY2lkZSBvbiB3aGV0aGVy IE1TRCBpcyBjb25zaWRlcmVkIGFkZGl0aW9uYWwgZGF0YSANCj4+PiBvciBub3QsIGJ1dCBJIGRv bid0IHRoaW5rIGl0J3MgcmVsZXZhbnQgYmVjYXVzZSBhZGRpdGlvbmFsIGRhdGEgaXMgDQo+Pj4g bm90IGEgbGVnYWN5IElORk8gdXNhZ2UsIG5vciBkb2VzIGFkZGl0aW9uYWwgZGF0YSB1cGRhdGUg UkZDIDYwODYuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0K Pj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogUmFuZGFsbCBH ZWxsZW5zIFttYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZ10NCj4+PiBTZW50OiAxNyBB dWd1c3QgMjAxNiAyMzo1Nw0KPj4+IFRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPjsgUGF1bCBLeXppdmF0IA0KPj4+IDxwa3l6aXZhdEBhbHVtLm1p dC5lZHU+OyBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIA0KPj4+IDxrZWl0aC5kcmFnZUBub2tp YS5jb20+OyBlY3JpdEBpZXRmLm9yZzsgQnJpYW4gUm9zZW4gDQo+Pj4gPEJyaWFuLlJvc2VuQG5l dXN0YXIuYml6Pg0KPj4+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIGRyYWZ0LWlldGYtZWNyaXQtZWNh bGwtMTEtIENhbGwtSW5mbyB1c2FnZSBub3QgDQo+Pj4gYWxpZ25lZCB3aXRoIFJGQzMyNjEgKHdh cyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIA0KPj4+IHVzYWdlIGJy aW5ncyBubyB2YWx1ZSkNCj4+PiANCj4+PiBIaSBFdmVyeW9uZSwNCj4+PiANCj4+PiBUaGUgYXV0 aG9ycyB3aXNoIHRvIHByb3Bvc2UgYSBzb2x1dGlvbiB0byB0aGUgY29uY2VybnMgdGhhdCBoYXZl IA0KPj4+IGJlZW4gcmFpc2VkLiAgV2UgcmVjb2duaXplIHRoYXQgdGhlIHZlaGljbGUgZGF0YSAo TVNEIGZvciBlQ2FsbCBhbmQgDQo+Pj4gVkVEUyBmb3INCj4+PiBjYXItY3Jhc2gpIGlzIHByb3Bl cmx5IGNvbnNpZGVyZWQgYWRkaXRpb25hbCBkYXRhIGluIHRoZSBjb250ZXh0IG9mIA0KPj4+IFJG QyA3ODUyLCB3aGlsZSB0aGUgbWV0YWRhdGEvY29udHJvbCBibG9jayBjYW4gYmUgY29uc2lkZXJl ZCBpdHMgb3duIA0KPj4+IHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wuICBXaXRoIHRoYXQgaW4g bWluZCwgb3VyIHByb3Bvc2FsIGlzIHRvIA0KPj4+IGhhdmUgdGhlIElORk8gcGFja2FnZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIG1ldGFkYXRhL2NvbnRyb2wgYmxvY2sgYnV0IA0KPj4+IG5vdCB0aGUg TVNEIG5vciBWRURTLiAgRm9yIGEgbWlkLWNhbGwgdXBkYXRlIHJlcXVlc3QsIHRoZSBQU0FQIHNl bmRzIA0KPj4+IGEgbWV0YWRhdGEvY29udHJvbCBibG9jayByZXF1ZXN0aW5nIGFuIHVwZGF0ZWQg TVNEIChvciBWRURTKSBpbiBJTkZPLg0KPj4+IFRoZSBJVlMgaW4gdHVybiBzZW5kcyBhbiBJTkZP IHdpdGggYSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIA0KPj4+IGFja25vd2xlZGdpbmcgdGhlIHJl cXVlc3Qgd2l0aCBhIHN1Y2Nlc3NmdWwgcmVzdWx0LiAgQm90aCBJTkZPIA0KPj4+IG1lc3NhZ2Vz IGNvbnRhaW4gYSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5G TyANCj4+PiBwYWNrYWdlIGFuZCBub3QgcmVmZXJlbmNlZCBieSBhIENhbGwtSW5mbyBoZWFkZXIg ZmllbGQuICBUaGUgSU5GTyANCj4+PiBzZW50IGJ5IHRoZSBJVlMgYWxzbyBjb250YWlucyBhbiB1 cGRhdGVkIE1TRCAob3IgVkVEUykgYXMgUkZDIDc4NTIgDQo+Pj4gYWRkaXRpb25hbCBkYXRhLCBy ZWZlcmVuY2VkIGJ5IGEgQ2FsbC1JbmZvIGhlYWRlciBmaWVsZC4gIFRoZXJlIA0KPj4+IHdvdWxk IGJlIHR3byBib2R5IHBhcnRzIGluIHRoZSBJTkZPIGZyb20gdGhlIElWUyB0byB0aGUgUFNBUCwg ZWFjaCANCj4+PiB3aXRoIGl0cyBhcHByb3ByaWF0ZSBNSU1FIHR5cGUgYW5kIENvbnRlbnQtRGlz cG9zaXRpb24uICBPbmUgYm9keSANCj4+PiBwYXJ0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgSU5G TyBwYWNrYWdlIGFuZCBpcyB0aGUgcmVzcG9uc2UgdG8gdGhlIHJlcXVlc3QuDQo+Pj4gVGhlIHNl Y29uZCBib2R5IHBhcnQgaXMgdGhlIHVwZGF0ZWQgTVNEIGFuZCBpcyByZWZlcmVuY2VkIGJ5IENh bGwtSW5mby4NCj4+PiBUaGlzIG1vcmUgY2xlYW5seSBzZXBhcmF0ZXMgdGhlIHJlcXVlc3QvcmVz cG9uc2UgcHJvdG9jb2wgZnJvbSB0aGUgDQo+Pj4gdmVoaWNsZSBkYXRhLiAgVGhlIHJlcXVlc3Qv cmVzcG9uc2UgcHJvdG9jb2wgdXNlcyBJTkZPLCBpcyANCj4+PiBhc3NvY2lhdGVkIHdpdGggYW4g SU5GTyBwYWNrYWdlLCBhbmQgY2FycmllcyBkYXRhIHdpdGggdGhlIA0KPj4+IEluZm8tUGFja2Fn ZSBDb250ZW50LURpc3Bvc2l0aW9uLiAgSU5GTyBtZXNzYWdlcyBzZW50IGJ5IHRoZSBJVlMgbWF5 IA0KPj4+IGFsc28gY29udGFpbiB2ZWhpY2xlIGRhdGEgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUg SU5GTyBwYWNrYWdlLiAgSW4gDQo+Pj4gZUNhbGwsIHRoaXMgYWxsb3dzIHRoZSBQU0FQIHRvIHJl cXVlc3QgYSBtaWQtY2FsbCB1cGRhdGUgYW5kIHRoZSBJVlMgDQo+Pj4gdG8gcmVzcG9uZC4gSW4g Y2FyLWNyYXNoLCB0aGlzIGFsbG93cyB0aGUgUFNBUCB0byByZXF1ZXN0IHRoZSANCj4+PiB2ZWhp Y2xlIHRvIHRha2Ugb3RoZXIgYWN0aW9ucyAoc3VjaCBhcyBmbGFzaGluZyB0aGUgbGlnaHRzKS4g IEluIGFsbCANCj4+PiBjYXNlcywgdGhlIHZlaGljbGUgcmVzcG9uZHMgdG8gYSByZXF1ZXN0IHdp dGggYW4gYWNrbm93bGVkZ21lbnQgKGFuZCANCj4+PiBpbmRpY2F0ZXMgaWYgdGhlIHJlcXVlc3Qg d2FzIHN1Y2Nlc3NmdWxseSBjYXJyaWVkIG91dCkuDQo+Pj4gDQo+Pj4gTm90ZSB0aGF0IFJGQyA2 MDg2IHBlcm1pdHMgSU5GTyBtZXNzYWdlcyB0byBhbHNvIGNhcnJ5IGRhdGEgbm90IA0KPj4+IGFz c29jaWF0ZWQgd2l0aCBJTkZPIHBhY2thZ2VzLg0KPj4+IA0KPj4+IFRoaXMgaGFzIGFuIGFkZGl0 aW9uYWwgYWR2YW50YWdlIG9mIG1ha2luZyBpdCBjbGVhbmVyIGFuZCBlYXNpZXIgdG8gDQo+Pj4g cmV1c2UgdGhlIGVtZXJnZW5jeSBjYWxsIHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgbGF0ZXIs IGluIG90aGVyIA0KPj4+IGRvY3VtZW50cyAoZS5nLiwgc28gdGhlIFBTQVAgY2FuIHJlcXVlc3Qg YnVpbGRpbmcgc2Vuc29yIGRhdGEpLg0KPj4+IA0KPj4+IC0tDQo+Pj4gUmFuZGFsbCBHZWxsZW5z DQo+Pj4gT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBz cGVhayBmb3IgbXlzZWxmIG9ubHkNCj4+PiAtLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3Rl ZCB0YWc6IC0tLS0tLS0tLS0tLS0tLSBJdCBpcyBlYXNpZXIgDQo+Pj4gdG8gZmlnaHQgZm9yIG9u ZSdzIHByaW5jaXBsZXMgdGhhbiB0byBsaXZlIHVwIHRvIHRoZW0uDQo+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tQWxmcmVkIEFkbGVyDQo+Pj4g DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+IA0KPiANCg0K From nobody Thu Aug 18 09:10:20 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 3E46B12DA24 for ; Thu, 18 Aug 2016 09:10:19 -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 eMleS31lrj4U for ; Thu, 18 Aug 2016 09:10:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E049A12D0B7 for ; Thu, 18 Aug 2016 09:10:17 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-97-57b5dde7a1f9 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B8.81.02493.7EDD5B75; Thu, 18 Aug 2016 18:10:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 18:10:14 +0200 From: Christer Holmberg To: Brian Rosen , Ivo Sedlacek Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+NjjpZHpzYRry0e+Ak1CeiTcHKBNxEmAgADMwQCAAALQAIAAJ4AAgAAoBrA= Date: Thu, 18 Aug 2016 16:10:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7q+6Lu1vDDZ7/ELF4en8am0Xjoqes Dkwe97/9ZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGpGmPGQuWsVb8O9LC3sA4hbWLkZNDQsBE 4seSj4wgtpDAekaJkxOruxi5gOwljBIb3x5l6WLk4GATsJDo/qcNUiMi4Cvx5PF0ZhCbWUBV 4lzjYxYQW1hgIaPEw+UxEDWLGCUWL5eDsP0kVq9/xw4yhgWo/up/WZAwL9CYG4/mMkGsauSU ODRnOtgcTgEniV0f28HmMwqISXw/tYYJYpe4xK0n85kgbhaQWLLnPDOELSrx8vE/qF+UJBqX PGEF2cUsoCmxfpc+RKuixJTuh+wQewUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbR4tTi 4tx0IyO91KLM5OLi/Dy9vNSSTYzACDm45bfVDsaDzx0PMQpwMCrx8Cbs3xouxJpYVlyZe4hR goNZSYRX8Q5QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dU A6NYqaUr2/V9vjeZG8uPzPm/VN9AQNgq1PTxoaSZ5/bfV7NMK+Lot4lkXLRX8sT8CctbQg87 LZyXsdUxfkbscdVZ20qkhP8rf3278dCjW0IRW8I3FmROfPT79bEF3+ezCs66lWRze+/mMI99 InP9O/QPtWzZ+qZaKqexa2LNfLZ3n9+cVmZ5saxIiaU4I9FQi7moOBEA5JXZUowCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 16:10:19 -0000 SGksDQoNCi4uLg0KDQo+V2UgcHJvcG9zZSB0byB1c2UgQ2FsbC1JbmZvIHRvIOKAnGxhYmVs4oCd IHRoZSBNU0Qgc28gdGhhdCBhbGwgaW5zdGFuY2VzIG9mIHRoaXMgZGF0YSBpcyB0cmVhdGVkIGFz IEFkZGl0aW9uYWwgRGF0YSwgd2hpY2ggaXQgdmVyeSBjbGVhcmx5IGlzLiAgDQoNCldoZW4geW91 IHVzZSBJTkZPIHlvdSBkZWZpbmUsIHdpdGhpbiB0aGUgaW5mbyBwYWNrYWdlIHNwZWNpZmljYXRp b24sIHRoYXQgd2hlbiB5b3UgcmVjZWl2ZSBib2R5IFggeW91IHRyZWF0IGl0IGFzIFkuIElmIHRo YXQgdHJlYXRtZW50IGhhcyBzb21lIGNvbm5lY3Rpb24gdG8gaG93IHlvdSB0cmVhdCBBZGRpdGlv bmFsIERhdGEsIGZpbmUsIGJ1dCB0aGF0IGlzIGEgc2VwYXJhdGUgaXNzdWUgZnJvbSBob3cgeW91 IGNhcnJ5IHRoZSBpbmZvcm1hdGlvbiBpbiBTSVAuDQoNCk5vIG5lZWQgZm9yIGFueSBDYWxsLUlu Zm8gImxhYmVsIi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Aug 18 09:26: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 D439B12DB36 for ; Thu, 18 Aug 2016 09:26:14 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 pTUlROZgIWkc for ; Thu, 18 Aug 2016 09:26:13 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 28BDA12DA2A for ; Thu, 18 Aug 2016 09:26:13 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with SMTP id aQ7jb48xN0MKRaQ8ybjgRJ; Thu, 18 Aug 2016 16:26:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with SMTP id aQ8xbldX0Owl9aQ8xbgWcV; Thu, 18 Aug 2016 16:26:12 +0000 To: Christer Holmberg , Brian Rosen References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <1c0c6217-481d-6e3f-4db8-9742d92fff83@alum.mit.edu> Date: Thu, 18 Aug 2016 12:26:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJxaKcZMp3vXdn/ZggVYtPDYBi7OAZOjMZ/Z6MSreOVcfO0rtsqNCh53C4Sa5DGCgrOEEzShZ6/ZUqqcNMLQXl1VB/2S4vSwbQMcHvcCTahZTerD1wNp BT8aC61n5dFHg2iqQfk+KHgFK3JmjcWq9x6VNjufyqk7al0VHaSwLFgsPB2sCIx1rtfNlvY3YboYPIJyJmTkEYP0ERBOLd55VHFr8n1EWRLyXxg/9eqqIO62 uh1A48+Ik7uiVdtPNn5yEc3Yaiyc+5Yp0sYSLFsTiKEI4Q0u++EkoU9CLKe8f2mrr9kYicLT5TuPQufV3xfhGm5GzN+ljV14lxJVxdfLOxY= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 16:26:15 -0000 On 8/18/16 11:49 AM, Christer Holmberg wrote: > Hi, > >> We’ll work up an example. >> >> There is no restriction on an INFO carrying body parts not associated with the INFO. > > There is a restriction saying that any new INFO usage must use the info package mechanism. > > The only reason RFC 6086 allows carrying body parts not associated with an info package is for backward compatibility with legacy INFO usages. IMO the specification of INFO has no business disallowing "extra" body parts that are serving other needs that are incidental to the primary purpose of INFO. This is no different than the situation with INVITE. INVITE has *one* body part that is tightly bound to the function of the message. It is identified by content-disposition "session" and content-type application/sdp. But it doesn't disallow other body parts, or the multipart wrapper that is needed when there are multiple body parts. There is no reason for the situation to be any different for INFO. Thanks, Paul > Regards, > > Christer > > > In this case, we would have a body part associated with the Call-Info CID (the MSD), as well as the body part that is associated with the INFO (the ack). As per the prior message, the MSD wouldn’t be limited to to the ACK INFO, even if it usually occurred there. > > Brian >> On Aug 18, 2016, at 2:23 AM, Christer Holmberg wrote: >> >> Hi, >> >> Please see my reply inline. But, I¹d like you to send an INFO example >> according to your example, to make sure we are talking about the same >> thing. >> >>> You are missing the point of the suggested compromise. >>> >>> This is NOT a legacy INFO. It¹s a new-style INFO package, conforming >>> to 6086. >>> >>> There is only ONE INFO part. It only carries the metadata/control >>> block, and its ACK. >>> >>> You send an INFO, with the metadata/control body part, with the >>> proper INFO mime type and content disposition. The MSD/VEDS is not there. >>> You send the MSD/VEDS as Additional Data, in a separate body part, >>> with the additional data MIME type and content disposition using Call-Info. >>> >>> So there are two parts in the body. One is the INFO block, the other >>> is the Additional Data block, with the Call-Info header pointing to >>> it. The latter isn¹t legacy use of INFO, it¹s permitted use of >>> Call-Info. 6069 expressly permits this. >> >> >> While RFC 6086 does allow usage of other C-D values than >> ³info-package² for specific body parts, the body parts are still >> associated with the Info Package - which means you know the semantics, >> and you know that the receiver will support the body part. So, I still >> don¹t see what you need Call-Info for? >> >> Yes, 6086 does contain an example where one body part is not >> associated with the Info Package to begin with. But, again, that is to >> address legacy usages of INFO. >> >> Regards, >> >> Christer >> >> >> >>> >>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg >>>> wrote: >>>> >>>> Hi, >>>> >>>> I thought we discussed usage of legacy (non-Info-Package) INFOs >>>> already. RFC 6086 allows it for backward compatibility. Any new >>>> usage MUST use an Info Package. >>>> >>>> And, even if it was allowed, using two different INFO mechanisms >>>> would make things even more complicated. >>>> >>>> I'll let others decide on whether MSD is considered additional data >>>> or not, but I don't think it's relevant because additional data is >>>> not a legacy INFO usage, nor does additional data update RFC 6086. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 17 August 2016 23:57 >>>> To: Christer Holmberg ; Paul Kyzivat >>>> ; Drage, Keith (Nokia - GB) >>>> ; ecrit@ietf.org; Brian Rosen >>>> >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Everyone, >>>> >>>> The authors wish to propose a solution to the concerns that have >>>> been raised. We recognize that the vehicle data (MSD for eCall and >>>> VEDS for >>>> car-crash) is properly considered additional data in the context of >>>> RFC 7852, while the metadata/control block can be considered its own >>>> request/response protocol. With that in mind, our proposal is to >>>> have the INFO package associated with the metadata/control block but >>>> not the MSD nor VEDS. For a mid-call update request, the PSAP sends >>>> a metadata/control block requesting an updated MSD (or VEDS) in INFO. >>>> The IVS in turn sends an INFO with a metadata/control block >>>> acknowledging the request with a successful result. Both INFO >>>> messages contain a metadata/control block associated with the INFO >>>> package and not referenced by a Call-Info header field. The INFO >>>> sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 >>>> additional data, referenced by a Call-Info header field. There >>>> would be two body parts in the INFO from the IVS to the PSAP, each >>>> with its appropriate MIME type and Content-Disposition. One body >>>> part is associated with the INFO package and is the response to the request. >>>> The second body part is the updated MSD and is referenced by Call-Info. >>>> This more cleanly separates the request/response protocol from the >>>> vehicle data. The request/response protocol uses INFO, is >>>> associated with an INFO package, and carries data with the >>>> Info-Package Content-Disposition. INFO messages sent by the IVS may >>>> also contain vehicle data not associated with the INFO package. In >>>> eCall, this allows the PSAP to request a mid-call update and the IVS >>>> to respond. In car-crash, this allows the PSAP to request the >>>> vehicle to take other actions (such as flashing the lights). In all >>>> cases, the vehicle responds to a request with an acknowledgment (and >>>> indicates if the request was successfully carried out). >>>> >>>> Note that RFC 6086 permits INFO messages to also carry data not >>>> associated with INFO packages. >>>> >>>> This has an additional advantage of making it cleaner and easier to >>>> reuse the emergency call request/response protocol later, in other >>>> documents (e.g., so the PSAP can request building sensor data). >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- It is easier >>>> to fight for one's principles than to live up to them. >>>> --Alfred Adler >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> > From nobody Thu Aug 18 09:38: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 DF2D112DC60 for ; Thu, 18 Aug 2016 09:38:37 -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 RGZ2NYPVol9w for ; Thu, 18 Aug 2016 09:38:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9054512DB36 for ; Thu, 18 Aug 2016 09:38:34 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-91-57b5e4879c32 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id D1.55.04209.784E5B75; Thu, 18 Aug 2016 18:38:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 18:38:31 +0200 From: Christer Holmberg To: Paul Kyzivat , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+NjjpZHpzYRry0e+Ak1CeiTcHKBOUiYAgAA/xwCAAEvh0P//6W4AgAAkJvA= Date: Thu, 18 Aug 2016 16:38:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC22D76@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> <1c0c6217-481d-6e3f-4db8-9742d92fff83@alum.mit.edu> In-Reply-To: <1c0c6217-481d-6e3f-4db8-9742d92fff83@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7hG7Hk63hBh3rrC2e3p/GZtG46Cmr xYYtx1ksVmw4wGrx/XkXowOrx9/3H5g87n/7y+6xZMlPJo+7ty4xeWy985glgDWKyyYlNSez LLVI3y6BK2PWgo/MBff8K56vmc7awHjDt4uRk0NCwERi2ZU3rCC2kMB6Rombq0q6GLmA7CWM Eme7brJ0MXJwsAlYSHT/0wapERHwlOj4f4MRxGYW6GSUeH6+AMQWFljIKPFweQxEzSJGicXL 5SBsP4n+rkNg9SwCqhI356xjArF5BXwlJn5/wA6xazOHxNrNp8GKOAUcJLrA9nJyMAqISXw/ tYYJYpm4xK0n85kgjhaQWLLnPDOELSrx8vE/VghbSaJxyRNWkJuZBTQl1u/Sh2hVlJjS/ZAd Yq+gxMmZT1gmMIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokR GF8Ht/xW3cF4+Y3jIUYBDkYlHl6FZVvChVgTy4orcw8xSnAwK4nwXnqwNVyINyWxsiq1KD++ qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QD44SOHX5PE04sjnvd1xhkNfmG W2rD5X18B53LTGLMOu8k+GzNyJJx0uOZc2JOxJ3t/tFcImtnV/X7T3jyvMHfLaXA9/LlmMPX hG72Gv3rUGp0sb69sOb0+QM/3eTf/qzYplJp9jic83vrm6Q9p+S+a34Qy5g/ebfOTgem9/Oi DC9sLaxwF1KbpMRSnJFoqMVcVJwIAEJ8SlWrAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 16:38:38 -0000 SGksDQoNCj4+PiBXZeKAmWxsIHdvcmsgdXAgYW4gZXhhbXBsZS4NCj4+Pg0KPj4+IFRoZXJlIGlz IG5vIHJlc3RyaWN0aW9uIG9uIGFuIElORk8gY2FycnlpbmcgYm9keSBwYXJ0cyBub3QgYXNzb2Np YXRlZCB3aXRoIHRoZSBJTkZPLg0KPj4NCj4+IFRoZXJlIGlzIGEgcmVzdHJpY3Rpb24gc2F5aW5n IHRoYXQgYW55IG5ldyBJTkZPIHVzYWdlIG11c3QgdXNlIHRoZSBpbmZvIHBhY2thZ2UgbWVjaGFu aXNtLg0KPj4NCj4+IFRoZSBvbmx5IHJlYXNvbiBSRkMgNjA4NiBhbGxvd3MgY2FycnlpbmcgYm9k eSBwYXJ0cyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGluZm8gcGFja2FnZSBpcyBmb3IgYmFja3dh cmQgY29tcGF0aWJpbGl0eSB3aXRoIGxlZ2FjeSBJTkZPIHVzYWdlcy4NCj4NCj4gSU1PIHRoZSBz cGVjaWZpY2F0aW9uIG9mIElORk8gaGFzIG5vIGJ1c2luZXNzIGRpc2FsbG93aW5nICJleHRyYSIg Ym9keSBwYXJ0cyB0aGF0IGFyZSBzZXJ2aW5nIG90aGVyIG5lZWRzIHRoYXQgYXJlIGluY2lkZW50 YWwgdG8gdGhlIHByaW1hcnkgcHVycG9zZSBvZiBJTkZPLg0KPg0KPiBUaGlzIGlzIG5vIGRpZmZl cmVudCB0aGFuIHRoZSBzaXR1YXRpb24gd2l0aCBJTlZJVEUuIElOVklURSBoYXMgKm9uZSogYm9k eSBwYXJ0IHRoYXQgaXMgdGlnaHRseSBib3VuZCB0byB0aGUgZnVuY3Rpb24gb2YgdGhlIA0KPiBt ZXNzYWdlLiBJdCBpcyBpZGVudGlmaWVkIGJ5IGNvbnRlbnQtZGlzcG9zaXRpb24gInNlc3Npb24i IGFuZCBjb250ZW50LXR5cGUgYXBwbGljYXRpb24vc2RwLiBCdXQgaXQgZG9lc24ndCBkaXNhbGxv dyBvdGhlciANCj4gYm9keSBwYXJ0cywgb3IgdGhlIG11bHRpcGFydCB3cmFwcGVyIHRoYXQgaXMg bmVlZGVkIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIGJvZHkgcGFydHMuIA0KPiBUaGVyZSBpcyBu byByZWFzb24gZm9yIHRoZSBzaXR1YXRpb24gdG8gYmUgYW55IGRpZmZlcmVudCBmb3IgSU5GTy4N Cg0KTVNEIHRyYW5zcG9ydCBpcyBvbmUgb2YgdGhlIG1haW4gcmVhc29ucyB3ZSBzZW5kIHRoZSBJ TkZPIHRvIGJlZ2luIC0gaXQgZGVmaW5lcyBJTkZPIHVzYWdlLCB3aGljaCBtZWFucyB5b3UgaGF2 ZSB0byB1c2UgYW4gaW5mbyBwYWNrYWdlLg0KDQpNU0QgaXMgKm5vdCogc29tZSBpbmZvcm1hdGlv biB0aGF0IGlzIHBpZ2d5YmFja2VkIG9udG8gdGhlIG1lc3NhZ2UgdGhhdCBzb21lb25lIGp1c3Qg aGFwcGVucyB0byBzZW5kIGZvciBzb21lIG90aGVyIHB1cnBvc2UuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rl cg0KPg0KPg0KPiAgIEluIHRoaXMgY2FzZSwgd2Ugd291bGQgaGF2ZSBhIGJvZHkgcGFydCBhc3Nv Y2lhdGVkIHdpdGggdGhlIENhbGwtSW5mbyBDSUQgKHRoZSBNU0QpLCBhcyB3ZWxsIGFzIHRoZSBi b2R5IHBhcnQgdGhhdCBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gKHRoZSBhY2spLiAgQXMg cGVyIHRoZSBwcmlvciBtZXNzYWdlLCB0aGUgTVNEIHdvdWxkbuKAmXQgYmUgbGltaXRlZCB0byB0 byB0aGUgQUNLIElORk8sIGV2ZW4gaWYgaXQgdXN1YWxseSBvY2N1cnJlZCB0aGVyZS4NCj4NCj4g QnJpYW4NCj4+IE9uIEF1ZyAxOCwgMjAxNiwgYXQgMjoyMyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGksDQo+Pg0K Pj4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUuIEJ1dCwgScK5ZCBsaWtlIHlvdSB0byBzZW5k IGFuIElORk8gZXhhbXBsZSANCj4+IGFjY29yZGluZyB0byB5b3VyIGV4YW1wbGUsIHRvIG1ha2Ug c3VyZSB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgc2FtZSANCj4+IHRoaW5nLg0KPj4NCj4+PiBZ b3UgYXJlIG1pc3NpbmcgdGhlIHBvaW50IG9mIHRoZSBzdWdnZXN0ZWQgY29tcHJvbWlzZS4NCj4+ Pg0KPj4+IFRoaXMgaXMgTk9UIGEgbGVnYWN5IElORk8uICBJdMK5cyBhIG5ldy1zdHlsZSBJTkZP IHBhY2thZ2UsIA0KPj4+IGNvbmZvcm1pbmcgdG8gNjA4Ni4NCj4+Pg0KPj4+IFRoZXJlIGlzIG9u bHkgT05FIElORk8gcGFydC4gIEl0IG9ubHkgY2FycmllcyB0aGUgbWV0YWRhdGEvY29udHJvbCAN Cj4+PiBibG9jaywgYW5kIGl0cyBBQ0suDQo+Pj4NCj4+PiBZb3Ugc2VuZCBhbiBJTkZPLCB3aXRo IHRoZSBtZXRhZGF0YS9jb250cm9sIGJvZHkgcGFydCwgd2l0aCB0aGUgDQo+Pj4gcHJvcGVyIElO Rk8gbWltZSB0eXBlIGFuZCBjb250ZW50IGRpc3Bvc2l0aW9uLiAgVGhlIE1TRC9WRURTIGlzIG5v dCB0aGVyZS4NCj4+PiBZb3Ugc2VuZCB0aGUgTVNEL1ZFRFMgYXMgQWRkaXRpb25hbCBEYXRhLCBp biBhIHNlcGFyYXRlIGJvZHkgcGFydCwgDQo+Pj4gd2l0aCB0aGUgYWRkaXRpb25hbCBkYXRhIE1J TUUgdHlwZSBhbmQgY29udGVudCBkaXNwb3NpdGlvbiB1c2luZyBDYWxsLUluZm8uDQo+Pj4NCj4+ PiBTbyB0aGVyZSBhcmUgdHdvIHBhcnRzIGluIHRoZSBib2R5LiAgT25lIGlzIHRoZSBJTkZPIGJs b2NrLCB0aGUgDQo+Pj4gb3RoZXIgaXMgdGhlIEFkZGl0aW9uYWwgRGF0YSBibG9jaywgd2l0aCB0 aGUgQ2FsbC1JbmZvIGhlYWRlciANCj4+PiBwb2ludGluZyB0byBpdC4gIFRoZSBsYXR0ZXIgaXNu wrl0IGxlZ2FjeSB1c2Ugb2YgSU5GTywgaXTCuXMgcGVybWl0dGVkIA0KPj4+IHVzZSBvZiBDYWxs LUluZm8uICA2MDY5IGV4cHJlc3NseSBwZXJtaXRzIHRoaXMuDQo+Pg0KPj4NCj4+IFdoaWxlIFJG QyA2MDg2IGRvZXMgYWxsb3cgdXNhZ2Ugb2Ygb3RoZXIgQy1EIHZhbHVlcyB0aGFuIA0KPj4gwrNp bmZvLXBhY2thZ2XCsiBmb3Igc3BlY2lmaWMgYm9keSBwYXJ0cywgdGhlIGJvZHkgcGFydHMgYXJl IHN0aWxsIA0KPj4gYXNzb2NpYXRlZCB3aXRoIHRoZSBJbmZvIFBhY2thZ2UgLSB3aGljaCBtZWFu cyB5b3Uga25vdyB0aGUgDQo+PiBzZW1hbnRpY3MsIGFuZCB5b3Uga25vdyB0aGF0IHRoZSByZWNl aXZlciB3aWxsIHN1cHBvcnQgdGhlIGJvZHkgcGFydC4gDQo+PiBTbywgSSBzdGlsbCBkb27CuXQg c2VlIHdoYXQgeW91IG5lZWQgQ2FsbC1JbmZvIGZvcj8NCj4+DQo+PiBZZXMsIDYwODYgZG9lcyBj b250YWluIGFuIGV4YW1wbGUgd2hlcmUgb25lIGJvZHkgcGFydCBpcyBub3QgDQo+PiBhc3NvY2lh dGVkIHdpdGggdGhlIEluZm8gUGFja2FnZSB0byBiZWdpbiB3aXRoLiBCdXQsIGFnYWluLCB0aGF0 IGlzIA0KPj4gdG8gYWRkcmVzcyBsZWdhY3kgdXNhZ2VzIG9mIElORk8uDQo+Pg0KPj4gUmVnYXJk cywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj4+IE9uIEF1ZyAxNywgMjAx NiwgYXQgNjoyMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgDQo+Pj4+IDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gSSB0aG91 Z2h0IHdlIGRpc2N1c3NlZCB1c2FnZSBvZiBsZWdhY3kgKG5vbi1JbmZvLVBhY2thZ2UpIElORk9z IA0KPj4+PiBhbHJlYWR5LiBSRkMgNjA4NiBhbGxvd3MgaXQgZm9yIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkuIEFueSBuZXcgDQo+Pj4+IHVzYWdlIE1VU1QgdXNlIGFuIEluZm8gUGFja2FnZS4NCj4+ Pj4NCj4+Pj4gQW5kLCBldmVuIGlmIGl0IHdhcyBhbGxvd2VkLCB1c2luZyB0d28gZGlmZmVyZW50 IElORk8gbWVjaGFuaXNtcyANCj4+Pj4gd291bGQgbWFrZSB0aGluZ3MgZXZlbiBtb3JlIGNvbXBs aWNhdGVkLg0KPj4+Pg0KPj4+PiBJJ2xsIGxldCBvdGhlcnMgZGVjaWRlIG9uIHdoZXRoZXIgTVNE IGlzIGNvbnNpZGVyZWQgYWRkaXRpb25hbCBkYXRhIA0KPj4+PiBvciBub3QsIGJ1dCBJIGRvbid0 IHRoaW5rIGl0J3MgcmVsZXZhbnQgYmVjYXVzZSBhZGRpdGlvbmFsIGRhdGEgaXMgDQo+Pj4+IG5v dCBhIGxlZ2FjeSBJTkZPIHVzYWdlLCBub3IgZG9lcyBhZGRpdGlvbmFsIGRhdGEgdXBkYXRlIFJG QyA2MDg2Lg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0K Pj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBSYW5kYWxs IEdlbGxlbnMgW21haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnXQ0KPj4+PiBTZW50OiAx NyBBdWd1c3QgMjAxNiAyMzo1Nw0KPj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IFBhdWwgDQo+Pj4+IEt5eml2YXQgPHBreXppdmF0QGFs dW0ubWl0LmVkdT47IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgDQo+Pj4+IDxrZWl0aC5kcmFn ZUBub2tpYS5jb20+OyBlY3JpdEBpZXRmLm9yZzsgQnJpYW4gUm9zZW4gDQo+Pj4+IDxCcmlhbi5S b3NlbkBuZXVzdGFyLmJpej4NCj4+Pj4gU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1l Y3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIHVzYWdlIG5vdCANCj4+Pj4gYWxpZ25lZCB3aXRoIFJG QzMyNjEgKHdhcyBSRTogZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xMS0gQ2FsbC1JbmZvIA0KPj4+ PiB1c2FnZSBicmluZ3Mgbm8gdmFsdWUpDQo+Pj4+DQo+Pj4+IEhpIEV2ZXJ5b25lLA0KPj4+Pg0K Pj4+PiBUaGUgYXV0aG9ycyB3aXNoIHRvIHByb3Bvc2UgYSBzb2x1dGlvbiB0byB0aGUgY29uY2Vy bnMgdGhhdCBoYXZlIA0KPj4+PiBiZWVuIHJhaXNlZC4gIFdlIHJlY29nbml6ZSB0aGF0IHRoZSB2 ZWhpY2xlIGRhdGEgKE1TRCBmb3IgZUNhbGwgYW5kIA0KPj4+PiBWRURTIGZvcg0KPj4+PiBjYXIt Y3Jhc2gpIGlzIHByb3Blcmx5IGNvbnNpZGVyZWQgYWRkaXRpb25hbCBkYXRhIGluIHRoZSBjb250 ZXh0IG9mIA0KPj4+PiBSRkMgNzg1Miwgd2hpbGUgdGhlIG1ldGFkYXRhL2NvbnRyb2wgYmxvY2sg Y2FuIGJlIGNvbnNpZGVyZWQgaXRzIA0KPj4+PiBvd24gcmVxdWVzdC9yZXNwb25zZSBwcm90b2Nv bC4gIFdpdGggdGhhdCBpbiBtaW5kLCBvdXIgcHJvcG9zYWwgaXMgDQo+Pj4+IHRvIGhhdmUgdGhl IElORk8gcGFja2FnZSBhc3NvY2lhdGVkIHdpdGggdGhlIG1ldGFkYXRhL2NvbnRyb2wgYmxvY2sg DQo+Pj4+IGJ1dCBub3QgdGhlIE1TRCBub3IgVkVEUy4gIEZvciBhIG1pZC1jYWxsIHVwZGF0ZSBy ZXF1ZXN0LCB0aGUgUFNBUCANCj4+Pj4gc2VuZHMgYSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIHJl cXVlc3RpbmcgYW4gdXBkYXRlZCBNU0QgKG9yIFZFRFMpIGluIElORk8uDQo+Pj4+IFRoZSBJVlMg aW4gdHVybiBzZW5kcyBhbiBJTkZPIHdpdGggYSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIA0KPj4+ PiBhY2tub3dsZWRnaW5nIHRoZSByZXF1ZXN0IHdpdGggYSBzdWNjZXNzZnVsIHJlc3VsdC4gIEJv dGggSU5GTyANCj4+Pj4gbWVzc2FnZXMgY29udGFpbiBhIG1ldGFkYXRhL2NvbnRyb2wgYmxvY2sg YXNzb2NpYXRlZCB3aXRoIHRoZSBJTkZPIA0KPj4+PiBwYWNrYWdlIGFuZCBub3QgcmVmZXJlbmNl ZCBieSBhIENhbGwtSW5mbyBoZWFkZXIgZmllbGQuICBUaGUgSU5GTyANCj4+Pj4gc2VudCBieSB0 aGUgSVZTIGFsc28gY29udGFpbnMgYW4gdXBkYXRlZCBNU0QgKG9yIFZFRFMpIGFzIFJGQyA3ODUy IA0KPj4+PiBhZGRpdGlvbmFsIGRhdGEsIHJlZmVyZW5jZWQgYnkgYSBDYWxsLUluZm8gaGVhZGVy IGZpZWxkLiAgVGhlcmUgDQo+Pj4+IHdvdWxkIGJlIHR3byBib2R5IHBhcnRzIGluIHRoZSBJTkZP IGZyb20gdGhlIElWUyB0byB0aGUgUFNBUCwgZWFjaCANCj4+Pj4gd2l0aCBpdHMgYXBwcm9wcmlh dGUgTUlNRSB0eXBlIGFuZCBDb250ZW50LURpc3Bvc2l0aW9uLiAgT25lIGJvZHkgDQo+Pj4+IHBh cnQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBJTkZPIHBhY2thZ2UgYW5kIGlzIHRoZSByZXNwb25z ZSB0byB0aGUgcmVxdWVzdC4NCj4+Pj4gVGhlIHNlY29uZCBib2R5IHBhcnQgaXMgdGhlIHVwZGF0 ZWQgTVNEIGFuZCBpcyByZWZlcmVuY2VkIGJ5IENhbGwtSW5mby4NCj4+Pj4gVGhpcyBtb3JlIGNs ZWFubHkgc2VwYXJhdGVzIHRoZSByZXF1ZXN0L3Jlc3BvbnNlIHByb3RvY29sIGZyb20gdGhlIA0K Pj4+PiB2ZWhpY2xlIGRhdGEuICBUaGUgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbCB1c2VzIElO Rk8sIGlzIA0KPj4+PiBhc3NvY2lhdGVkIHdpdGggYW4gSU5GTyBwYWNrYWdlLCBhbmQgY2Fycmll cyBkYXRhIHdpdGggdGhlIA0KPj4+PiBJbmZvLVBhY2thZ2UgQ29udGVudC1EaXNwb3NpdGlvbi4g IElORk8gbWVzc2FnZXMgc2VudCBieSB0aGUgSVZTIA0KPj4+PiBtYXkgYWxzbyBjb250YWluIHZl aGljbGUgZGF0YSBub3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBJTkZPIHBhY2thZ2UuICANCj4+Pj4g SW4gZUNhbGwsIHRoaXMgYWxsb3dzIHRoZSBQU0FQIHRvIHJlcXVlc3QgYSBtaWQtY2FsbCB1cGRh dGUgYW5kIHRoZSANCj4+Pj4gSVZTIHRvIHJlc3BvbmQuIEluIGNhci1jcmFzaCwgdGhpcyBhbGxv d3MgdGhlIFBTQVAgdG8gcmVxdWVzdCB0aGUgDQo+Pj4+IHZlaGljbGUgdG8gdGFrZSBvdGhlciBh Y3Rpb25zIChzdWNoIGFzIGZsYXNoaW5nIHRoZSBsaWdodHMpLiAgSW4gDQo+Pj4+IGFsbCBjYXNl cywgdGhlIHZlaGljbGUgcmVzcG9uZHMgdG8gYSByZXF1ZXN0IHdpdGggYW4gYWNrbm93bGVkZ21l bnQgDQo+Pj4+IChhbmQgaW5kaWNhdGVzIGlmIHRoZSByZXF1ZXN0IHdhcyBzdWNjZXNzZnVsbHkg Y2FycmllZCBvdXQpLg0KPj4+Pg0KPj4+PiBOb3RlIHRoYXQgUkZDIDYwODYgcGVybWl0cyBJTkZP IG1lc3NhZ2VzIHRvIGFsc28gY2FycnkgZGF0YSBub3QgDQo+Pj4+IGFzc29jaWF0ZWQgd2l0aCBJ TkZPIHBhY2thZ2VzLg0KPj4+Pg0KPj4+PiBUaGlzIGhhcyBhbiBhZGRpdGlvbmFsIGFkdmFudGFn ZSBvZiBtYWtpbmcgaXQgY2xlYW5lciBhbmQgZWFzaWVyIHRvIA0KPj4+PiByZXVzZSB0aGUgZW1l cmdlbmN5IGNhbGwgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbCBsYXRlciwgaW4gb3RoZXIgDQo+ Pj4+IGRvY3VtZW50cyAoZS5nLiwgc28gdGhlIFBTQVAgY2FuIHJlcXVlc3QgYnVpbGRpbmcgc2Vu c29yIGRhdGEpLg0KPj4+Pg0KPj4+PiAtLQ0KPj4+PiBSYW5kYWxsIEdlbGxlbnMNCj4+Pj4gT3Bp bmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3Ig bXlzZWxmIG9ubHkNCj4+Pj4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAt LS0tLS0tLS0tLS0tLS0gSXQgaXMgZWFzaWVyIA0KPj4+PiB0byBmaWdodCBmb3Igb25lJ3MgcHJp bmNpcGxlcyB0aGFuIHRvIGxpdmUgdXAgdG8gdGhlbS4NCj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tQWxmcmVkIEFkbGVyDQo+Pj4+DQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEVj cml0IG1haWxpbmcgbGlzdA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4NCj4+DQo+DQoNCg== From nobody Thu Aug 18 09:57: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 C8A0F12D86D for ; Thu, 18 Aug 2016 09:57: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 cboy39cGA5Q6 for ; Thu, 18 Aug 2016 09:57:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8282612D7E8 for ; Thu, 18 Aug 2016 09:56:44 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 18 Aug 2016 09:56:44 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Aug 2016 09:56:39 -0700 To: Christer Holmberg , Brian Rosen From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 16:57:11 -0000 Hi Christer, RFC 6086 says: NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned. At 3:49 PM +0000 8/18/16, Christer Holmberg wrote: > Hi, > >> We'll work up an example. >> >> There is no restriction on an INFO carrying=20 >> body parts not associated with the INFO. > > There is a restriction saying that any new INFO=20 > usage must use the info package mechanism. > > The only reason RFC 6086 allows carrying body=20 > parts not associated with an info package is=20 > for backward compatibility with legacy INFO=20 > usages. > > Regards, > > Christer > > > In this case, we would have a body part=20 > associated with the Call-Info CID (the MSD), as=20 > well as the body part that is associated with=20 > the INFO (the ack). As per the prior message,=20 > the MSD wouldn't be limited to to the ACK INFO,=20 > even if it usually occurred there. > > Brian >> On Aug 18, 2016, at 2:23 AM, Christer Holmberg=20 >> wrote: >> >> Hi, >> >> Please see my reply inline. But, I=A9=96d like you to send an INFO examp= le >> according to your example, to make sure we are talking about the same >> thing. >> >>> You are missing the point of the suggested compromise. >>> >>> This is NOT a legacy INFO. It=A9=96s a new-style INFO package, conform= ing >>> to 6086. >>> >>> There is only ONE INFO part. It only carries the metadata/control >>> block, and its ACK. >>> >>> You send an INFO, with the metadata/control body part, with the >>> proper INFO mime type and content disposition. The MSD/VEDS is not the= re. >>> You send the MSD/VEDS as Additional Data, in a separate body part, >>> with the additional data MIME type and content disposition using Call-I= nfo. >>> >>> So there are two parts in the body. One is the INFO block, the other >>> is the Additional Data block, with the Call-Info header pointing to >>> it. The latter isn=A9=96t legacy use of INFO, it=A9=96s permitted use = of >>> Call-Info. 6069 expressly permits this. >> >> >> While RFC 6086 does allow usage of other C-D values than >> =A9=AFinfo-package=A9=97 for specific body parts, the body parts are sti= ll >> associated with the Info Package - which means you know the semantics, >> and you know that the receiver will support the body part. So, I still >> don=A9=96t see what you need Call-Info for? >> >> Yes, 6086 does contain an example where one body part is not >> associated with the Info Package to begin with. But, again, that is to >> address legacy usages of INFO. >> >> Regards, >> >> Christer >> >> >> >>> >>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg >>>> wrote: >>>> >>>> Hi, >>>> >>>> I thought we discussed usage of legacy (non-Info-Package) INFOs >>>> already. RFC 6086 allows it for backward compatibility. Any new >>>> usage MUST use an Info Package. >>>> >>>> And, even if it was allowed, using two different INFO mechanisms >>>> would make things even more complicated. >>>> >>>> I'll let others decide on whether MSD is considered additional data >>>> or not, but I don't think it's relevant because additional data is >>>> not a legacy INFO usage, nor does additional data update RFC 6086. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 17 August 2016 23:57 >>>> To: Christer Holmberg ; Paul Kyzivat >>>> ; Drage, Keith (Nokia - GB) >>>> ; ecrit@ietf.org; Brian Rosen >>>> >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not > >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>> usage brings no value) >>>> >>>> Hi Everyone, >>>> >>>> The authors wish to propose a solution to the concerns that have >>>> been raised. We recognize that the vehicle data (MSD for eCall and >>>> VEDS for >>>> car-crash) is properly considered additional data in the context of >>>> RFC 7852, while the metadata/control block can be considered its own >>>> request/response protocol. With that in mind, our proposal is to >>>> have the INFO package associated with the metadata/control block but >>>> not the MSD nor VEDS. For a mid-call update request, the PSAP sends >>>> a metadata/control block requesting an updated MSD (or VEDS) in INFO. >>>> The IVS in turn sends an INFO with a metadata/control block >>>> acknowledging the request with a successful result. Both INFO >>>> messages contain a metadata/control block associated with the INFO >>>> package and not referenced by a Call-Info header field. The INFO >>>> sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 >>>> additional data, referenced by a Call-Info header field. There >>>> would be two body parts in the INFO from the IVS to the PSAP, each >>>> with its appropriate MIME type and Content-Disposition. One body >>>> part is associated with the INFO package and=20 >>>> is the response to the request. >>>> The second body part is the updated MSD and is referenced by Call-Info= =2E >>>> This more cleanly separates the request/response protocol from the >>>> vehicle data. The request/response protocol uses INFO, is >>>> associated with an INFO package, and carries data with the >>>> Info-Package Content-Disposition. INFO messages sent by the IVS may >>>> also contain vehicle data not associated with the INFO package. In >>>> eCall, this allows the PSAP to request a mid-call update and the IVS >>>> to respond. In car-crash, this allows the PSAP to request the >>>> vehicle to take other actions (such as flashing the lights). In all >>>> cases, the vehicle responds to a request with an acknowledgment (and >>>> indicates if the request was successfully carried out). >>>> >>>> Note that RFC 6086 permits INFO messages to also carry data not >>>> associated with INFO packages. >>>> >>>> This has an additional advantage of making it cleaner and easier to >>>> reuse the emergency call request/response protocol later, in other >>>> documents (e.g., so the PSAP can request building sensor data). >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself onl= y >>>> -------------- Randomly selected tag: --------------- It is easier >>>> to fight for one's principles than to live up to them. >>>> --Alfred Adler >>>> >>>> _______________________________________________ >>>> 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: --------------- Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. From nobody Thu Aug 18 10:03: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 B68C712DB93 for ; Thu, 18 Aug 2016 10:01: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 FgjBthOCWnTK for ; Thu, 18 Aug 2016 10:00:15 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5E12DA75 for ; Thu, 18 Aug 2016 10:00: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, 18 Aug 2016 10:00:04 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC22D76@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> <1c0c6217-481d-6e3f-4db8-9742d92fff83@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC22D76@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Aug 2016 10:00:01 -0700 To: Christer Holmberg , Paul Kyzivat , Brian Rosen From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:01:08 -0000 X-List-Received-Date: Thu, 18 Aug 2016 17:01:08 -0000 At 4:38 PM +0000 8/18/16, Christer Holmberg wrote: > Hi, > >>>> We'll work up an example. >>>> >>>> There is no restriction on an INFO carrying=20 >>>> body parts not associated with the INFO. >>> >>> There is a restriction saying that any new=20 >>> INFO usage must use the info package=20 >>> mechanism. >>> >>> The only reason RFC 6086 allows carrying body=20 >>> parts not associated with an info package is=20 >>> for backward compatibility with legacy INFO=20 >>> usages. >> >> IMO the specification of INFO has no business=20 >> disallowing "extra" body parts that are=20 >> serving other needs that are incidental to the=20 >> primary purpose of INFO. >> >> This is no different than the situation with=20 >> INVITE. INVITE has *one* body part that is=20 >> tightly bound to the function of the >> message. It is identified by=20 >> content-disposition "session" and content-type=20 >> application/sdp. But it doesn't disallow other >> body parts, or the multipart wrapper that is=20 >> needed when there are multiple body parts. >> There is no reason for the situation to be any different for INFO. > > MSD transport is one of the main reasons we=20 > send the INFO to begin - it defines INFO usage,=20 > which means you have to use an info package. > > MSD is *not* some information that is=20 > piggybacked onto the message that someone just=20 > happens to send for some other purpose. Hi Christer, We're saying that INFO will be used for a=20 request/response protocol. If a request is for=20 the IVS to send an updated MSD, the IVS can send=20 that MSD in any convenient SIP message. As Paul=20 says, it might usually be the INFO that contains=20 the response to the request (the ACK) but it=20 isn't required to be, it might for example be in=20 a re-INVITE sent for some other purpose. > > > In this case, we would have a body part=20 > associated with the Call-Info CID (the MSD), as=20 > well as the body part that is associated with=20 > the INFO (the ack). As per the prior message,=20 > the MSD wouldn't be limited to to the ACK INFO,=20 > even if it usually occurred there. >> >> Brian >>> On Aug 18, 2016, at 2:23 AM, Christer=20 >>> Holmberg =20 >>> wrote: >>> >>> Hi, >>> >>> Please see my reply inline. But, I=A9=96d like you to send an INFO exam= ple >>> according to your example, to make sure we are talking about the same >>> thing. >>> >>>> You are missing the point of the suggested compromise. >>>> >>>> This is NOT a legacy INFO. It=A9=96s a new-style INFO package, >>>> conforming to 6086. >>>> >>>> There is only ONE INFO part. It only carries the metadata/control >>>> block, and its ACK. >>>> >>>> You send an INFO, with the metadata/control body part, with the >>>> proper INFO mime type and content disposition. The MSD/VEDS is not th= ere. >>>> You send the MSD/VEDS as Additional Data, in a separate body part, >>>> with the additional data MIME type and=20 >>>> content disposition using Call-Info. >>>> >>>> So there are two parts in the body. One is the INFO block, the >>>> other is the Additional Data block, with the Call-Info header >>>> pointing to it. The latter isn=A9=96t legacy use of INFO, it=A9=96s p= ermitted >>>> use of Call-Info. 6069 expressly permits this. >>> >>> >>> While RFC 6086 does allow usage of other C-D values than >>> =A9=AFinfo-package=A9=97 for specific body parts, the body parts are st= ill >>> associated with the Info Package - which means you know the >>> semantics, and you know that the receiver will support the body part. >>> So, I still don=A9=96t see what you need Call-Info for? >>> >>> Yes, 6086 does contain an example where one body part is not >>> associated with the Info Package to begin with. But, again, that is >>> to address legacy usages of INFO. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> >>>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg > >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I thought we discussed usage of legacy (non-Info-Package) INFOs >>>>> already. RFC 6086 allows it for backward compatibility. Any new >>>>> usage MUST use an Info Package. >>>>> >>>>> And, even if it was allowed, using two different INFO mechanisms >>>>> would make things even more complicated. >>>>> >>>>> I'll let others decide on whether MSD is considered additional data >>>>> or not, but I don't think it's relevant because additional data is >>>>> not a legacy INFO usage, nor does additional data update RFC 6086. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 17 August 2016 23:57 >>>>> To: Christer Holmberg ; Paul >>>>> Kyzivat ; Drage, Keith (Nokia - GB) >>>>> ; ecrit@ietf.org; Brian Rosen >>>>> >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not >>>>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info >>>>> usage brings no value) >>>>> >>>>> Hi Everyone, >>>>> >>>>> The authors wish to propose a solution to the concerns that have >>>>> been raised. We recognize that the vehicle data (MSD for eCall and >>>>> VEDS for >>>>> car-crash) is properly considered additional data in the context of >>>>> RFC 7852, while the metadata/control block can be considered its >>>>> own request/response protocol. With that in mind, our proposal is >>>>> to have the INFO package associated with the metadata/control block >>>>> but not the MSD nor VEDS. For a mid-call update request, the PSAP >>>>> sends a metadata/control block requesting=20 >>>>> an updated MSD (or VEDS) in INFO. >>>>> The IVS in turn sends an INFO with a metadata/control block >>>>> acknowledging the request with a successful result. Both INFO >>>>> messages contain a metadata/control block associated with the INFO >>>>> package and not referenced by a Call-Info header field. The INFO >>>>> sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 >>>>> additional data, referenced by a Call-Info header field. There >>>>> would be two body parts in the INFO from the IVS to the PSAP, each >>>>> with its appropriate MIME type and Content-Disposition. One body >>>>> part is associated with the INFO package=20 >>>>> and is the response to the request. >>>>> The second body part is the updated MSD and is referenced by Call-Inf= o. >>>>> This more cleanly separates the request/response protocol from the >>>>> vehicle data. The request/response protocol uses INFO, is >>>>> associated with an INFO package, and carries data with the >>>>> Info-Package Content-Disposition. INFO messages sent by the IVS >>>>> may also contain vehicle data not associated with the INFO package. >>>>> In eCall, this allows the PSAP to request a mid-call update and the >>>>> IVS to respond. In car-crash, this allows the PSAP to request the >>>>> vehicle to take other actions (such as flashing the lights). In >>>>> all cases, the vehicle responds to a request with an acknowledgment >>>>> (and indicates if the request was successfully carried out). >>>>> >>>>> Note that RFC 6086 permits INFO messages to also carry data not >>>>> associated with INFO packages. >>>>> >>>>> This has an additional advantage of making it cleaner and easier to >>>>> reuse the emergency call request/response protocol later, in other >>>>> documents (e.g., so the PSAP can request building sensor data). >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself on= ly >>>>> -------------- Randomly selected tag: --------------- It is easier >>>>> to fight for one's principles than to live up to them. >>>>> --Alfred Adler >>>>> >>>>> _______________________________________________ >>>>> 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: --------------- George Orwell was an optimist. From nobody Thu Aug 18 10:05: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 DDD0912DA66 for ; Thu, 18 Aug 2016 10:05:44 -0700 (PDT) X-Quarantine-ID: <7aAUr2ctO7N0> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 7aAUr2ctO7N0 for ; Thu, 18 Aug 2016 10:05:43 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0013A12DAC1 for ; Thu, 18 Aug 2016 10:05:42 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 18 Aug 2016 10:05:41 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Thu, 18 Aug 2016 10:05:39 -0700 To: Christer Holmberg , Brian Rosen , Ivo Sedlacek 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:05:45 -0000 Hi, We want there to be one way to transfer the MSD, which uses Call-Info. You've made the argument that we can't use the same Call-Info mechanism in non-INFO and also in INFO. With the compromise proposal, we are complying with this: the MSD is always sent as Additional Data using Call-Info, while INFO is used to transfer a request/response data block. The fact that sometimes an INFO might also have an MSD is essentially besides the point of INFO. INFO is used for INFO package compliant data. --Randy At 4:10 PM +0000 8/18/16, Christer Holmberg wrote: > Hi, > > ... > >>We propose to use Call-Info to "label" the MSD so that all >> instances of this data is treated as Additional Data, which it >> very clearly is. > > When you use INFO you define, within the info package > specification, that when you receive body X you treat it as Y. If > that treatment has some connection to how you treat Additional > Data, fine, but that is a separate issue from how you carry the > information in SIP. > > No need for any Call-Info "label". > > 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: --------------- Creativity is just having enough dots to connect. --Steve Jobs From nobody Thu Aug 18 10:08: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 D441D12D80B for ; Thu, 18 Aug 2016 10:08:24 -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 kIYHW6Vh680b for ; Thu, 18 Aug 2016 10:08:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6825412D801 for ; Thu, 18 Aug 2016 10:08:11 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-06-57b5eb79b2c1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 40.48.04209.97BE5B75; Thu, 18 Aug 2016 19:08:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 19:08:09 +0200 From: Christer Holmberg To: Randall Gellens , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+XGCYvwJ+oRjhkmgia83wSA5l6BO8nhg Date: Thu, 18 Aug 2016 17:08:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC22F37@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@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.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7vW7l663hBvuemVg8vT+NzaJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB53P/2l91jyZKfTB53b11i8th65zFLAGsUl01Kak5m WWqRvl0CV8areUfZCjbZVnz+7tvAeMCgi5GTQ0LAROLSp0PMXYxcHEIC6xkljq67COUsYZRY /3M5kMPBwSZgIdH9TxukQUQgSOL9gulgNcwCTYwS116uYgRxhAUWM0rsWtHKAuKIgHQv/HWR EaLFSGJfez8LiM0ioCrR+rkDLM4r4Cux/t18ZhBbSOAdh8T8MxkgNifQTR8urWcCsRkFxCS+ n1oDZjMLiEvcejKfCeJuAYkle84zQ9iiEi8f/2OFsJUkGpc8YYWo15O4MXUKG4StLbFs4Wtm iL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2M wDg7uOW36g7Gy28cDzEKcDAq8fAqLNsSLsSaWFZcmXuIUYKDWUmEt/3p1nAh3pTEyqrUovz4 otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjEYW9uWPpz5pUpL6wNXeX1cl /lva79qvTIFpPaEzb2z2Pci7XXriqyjjz+IuFf8D2x7GM916vW3V0T2LN+6+uO3j7EXqMud0 Be8vsr3dPaGm4bDd8n/PIx8VHn82yXrjh6vH6lwvfSpSyXfa23er4M3ZktC45smvIgoWz+7e tWPpIpfMwKCZ1Y+VWIozEg21mIuKEwEz9uvNrwIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:08:25 -0000 Hi, >RFC 6086 says: > > NOTE: An INFO request can also contain other body parts that are > meaningful within the context of an invite dialog usage but are > not specifically associated with the INFO method and the > application concerned. The MSD body part *IS* associated with the INFO method. MSD (in addition to= the request/ack) is the reason you send the INFO to begin with. It's the m= ain usage of the INFO. Application foo doesn't send INFO in order to transport bar, and then you j= ust happen to piggyback the MSD because there happens to be an INFO being s= ent where you can piggyback it. Regards, Christer At 3:49 PM +0000 8/18/16, Christer Holmberg wrote: > Hi, > >> We'll work up an example. >> >> There is no restriction on an INFO carrying body parts not=20 >> associated with the INFO. > > There is a restriction saying that any new INFO usage must use the=20 > info package mechanism. > > The only reason RFC 6086 allows carrying body parts not associated=20 > with an info package is for backward compatibility with legacy INFO=20 > usages. > > Regards, > > Christer > > > In this case, we would have a body part associated with the=20 > Call-Info CID (the MSD), as well as the body part that is associated=20 > with the INFO (the ack). As per the prior message, the MSD wouldn't=20 > be limited to to the ACK INFO, even if it usually occurred there. > > Brian >> On Aug 18, 2016, at 2:23 AM, Christer Holmberg=20 >> wrote: >> >> Hi, >> >> Please see my reply inline. But, I=A9-d like you to send an INFO=20 >> example according to your example, to make sure we are talking about=20 >> the same thing. >> >>> You are missing the point of the suggested compromise. >>> >>> This is NOT a legacy INFO. It=A9-s a new-style INFO package,=20 >>> conforming to 6086. >>> >>> There is only ONE INFO part. It only carries the metadata/control =20 >>> block, and its ACK. >>> >>> You send an INFO, with the metadata/control body part, with the =20 >>> proper INFO mime type and content disposition. The MSD/VEDS is not the= re. >>> You send the MSD/VEDS as Additional Data, in a separate body part, =20 >>> with the additional data MIME type and content disposition using Call-I= nfo. >>> >>> So there are two parts in the body. One is the INFO block, the=20 >>> other is the Additional Data block, with the Call-Info header=20 >>> pointing to it. The latter isn=A9-t legacy use of INFO, it=A9-s=20 >>> permitted use of Call-Info. 6069 expressly permits this. >> >> >> While RFC 6086 does allow usage of other C-D values than =20 >> =A9=AFinfo-package=A9- for specific body parts, the body parts are still= =20 >> associated with the Info Package - which means you know the=20 >> semantics, and you know that the receiver will support the body=20 >> part. So, I still don=A9-t see what you need Call-Info for? >> >> Yes, 6086 does contain an example where one body part is not =20 >> associated with the Info Package to begin with. But, again, that is=20 >> to address legacy usages of INFO. >> >> Regards, >> >> Christer >> >> >> >>> >>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg =20 >>>> wrote: >>>> >>>> Hi, >>>> >>>> I thought we discussed usage of legacy (non-Info-Package) INFOs =20 >>>> already. RFC 6086 allows it for backward compatibility. Any new =20 >>>> usage MUST use an Info Package. >>>> >>>> And, even if it was allowed, using two different INFO mechanisms =20 >>>> would make things even more complicated. >>>> >>>> I'll let others decide on whether MSD is considered additional=20 >>>> data or not, but I don't think it's relevant because additional=20 >>>> data is not a legacy INFO usage, nor does additional data update RFC = 6086. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> -----Original Message----- >>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>> Sent: 17 August 2016 23:57 >>>> To: Christer Holmberg ; Paul=20 >>>> Kyzivat ; Drage, Keith (Nokia - GB) =20 >>>> ; ecrit@ietf.org; Brian Rosen =20 >>>> >>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>>> not > >>> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-=20 > Call-Info >>>> usage brings no value) >>>> >>>> Hi Everyone, >>>> >>>> The authors wish to propose a solution to the concerns that have =20 >>>> been raised. We recognize that the vehicle data (MSD for eCall and =20 >>>> VEDS for >>>> car-crash) is properly considered additional data in the context=20 >>>> of RFC 7852, while the metadata/control block can be considered=20 >>>> its own request/response protocol. With that in mind, our=20 >>>> proposal is to have the INFO package associated with the=20 >>>> metadata/control block but not the MSD nor VEDS. For a mid-call=20 >>>> update request, the PSAP sends a metadata/control block requesting an= updated MSD (or VEDS) in INFO. >>>> The IVS in turn sends an INFO with a metadata/control block =20 >>>> acknowledging the request with a successful result. Both INFO =20 >>>> messages contain a metadata/control block associated with the INFO =20 >>>> package and not referenced by a Call-Info header field. The INFO =20 >>>> sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 =20 >>>> additional data, referenced by a Call-Info header field. There =20 >>>> would be two body parts in the INFO from the IVS to the PSAP, each =20 >>>> with its appropriate MIME type and Content-Disposition. One body =20 >>>> part is associated with the INFO package and is the response to the=20 >>>> request. >>>> The second body part is the updated MSD and is referenced by Call-Inf= o. >>>> This more cleanly separates the request/response protocol from the =20 >>>> vehicle data. The request/response protocol uses INFO, is =20 >>>> associated with an INFO package, and carries data with the =20 >>>> Info-Package Content-Disposition. INFO messages sent by the IVS=20 >>>> may also contain vehicle data not associated with the INFO=20 >>>> package. In eCall, this allows the PSAP to request a mid-call=20 >>>> update and the IVS to respond. In car-crash, this allows the PSAP=20 >>>> to request the vehicle to take other actions (such as flashing the=20 >>>> lights). In all cases, the vehicle responds to a request with an=20 >>>> acknowledgment (and indicates if the request was successfully carried= out). >>>> >>>> Note that RFC 6086 permits INFO messages to also carry data not =20 >>>> associated with INFO packages. >>>> >>>> This has an additional advantage of making it cleaner and easier=20 >>>> to reuse the emergency call request/response protocol later, in=20 >>>> other documents (e.g., so the PSAP can request building sensor data). >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself on= ly >>>> -------------- Randomly selected tag: --------------- It is easier =20 >>>> to fight for one's principles than to live up to them. >>>> --Alfred Adler >>>> >>>> _______________________________________________ >>>> 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: --------------- Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. From nobody Thu Aug 18 10:12: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 4819A12DA71 for ; Thu, 18 Aug 2016 10:12: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 4akuRF_-Fm32 for ; Thu, 18 Aug 2016 10:12:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0B47D12D1BE for ; Thu, 18 Aug 2016 10:12:13 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-30-57b5ec691339 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 8E.CF.02553.96CE5B75; Thu, 18 Aug 2016 19:12:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 19:12:09 +0200 From: Christer Holmberg To: Randall Gellens , Brian Rosen , Ivo Sedlacek Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+XLBu9S4IpGUzEKbzZ/n5fRpraBO86Yw Date: Thu, 18 Aug 2016 17:12:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC22F84@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC228D7@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbE9XDfnzdZwgzVTxS2e3p/GZtG46Cmr xffnXYwOzB73v/1l91iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mh7s6WIsWM9bMWPJPaYG xn1cXYwcHBICJhK3OxO7GLk4hATWM0r8+DiDBcJZwihxbO1XZpAiNgELie5/2l2MnBwiAjUS f3/3sYPYzAKqEucaH4PVCwssZpTYtaIVzBEBaV746yIjSLOIgJFEw/sqkAYWoIaPD6cwgti8 Ar4Sez/OYIVY9p5TYtLSSUwgCU6giw4t+gtmMwqISXw/tYYJYpu4xK0n88FsCQEBiSV7zjND 2KISLx//Y4WwlSQalzxhhajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZ haRlASPLKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA6Dm45bfBDsaXzx0PMQpwMCrx8Cbs 3xouxJpYVlyZe4hRgoNZSYS3/SlQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU 7NTUgtQimCwTB6dUA6PzgcZrk9SPPv269Zb/hjOhD2u1FfzdvVrOCiWozldZ++HJHO+G5WUT 7Tb/evU41f5g3cPWFr3DxiwzDRLPKVSsddl8Wuj4PcNolk+TZTYvSdCqfPXiXLP65fPsW6Ju rjzsK9lTkNTiVpaRExPK+TYs5yNLyYe88oPLwgL78if940m9rlzw7bgSS3FGoqEWc1FxIgDB VI7VmgIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:12:16 -0000 Hi, >We want there to be one way to transfer the MSD, which uses Call-Info. Yo= u've made the argument that we can't use the same Call-Info mechanism in no= n-INFO and also >in INFO. With the compromise proposal, we are complying w= ith this: the MSD is always sent as Additional Data using Call-Info, while = INFO is used to transfer a >request/response data block. The fact that som= etimes an INFO might also have an MSD is essentially besides the point of I= NFO.=20 Not since MSD transport is the reason you send the INFO to begin with. And,= sometimes MSD will be the *ONLY* thing you transport in the INFO, which me= ans it is not "might also have an MSD" - in such cases it will ONLY have an= MSD. Regards, Christer At 4:10 PM +0000 8/18/16, Christer Holmberg wrote: > Hi, > > ... > >>We propose to use Call-Info to "label" the MSD so that all instances=20 >>of this data is treated as Additional Data, which it very clearly is. > > When you use INFO you define, within the info package specification,=20 > that when you receive body X you treat it as Y. If that treatment has=20 > some connection to how you treat Additional Data, fine, but that is a=20 > separate issue from how you carry the information in SIP. > > No need for any Call-Info "label". > > 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: --------------- Creativity is just having enough dots to connect. --Steve Jobs From nobody Thu Aug 18 10:19: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 F067212D9FA for ; Thu, 18 Aug 2016 10:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Z4MTX3hQN-qo for ; Thu, 18 Aug 2016 10:19:17 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 16DD412D750 for ; Thu, 18 Aug 2016 10:19:17 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id z190so22786941qkc.0 for ; Thu, 18 Aug 2016 10:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sUbR8qRU/u+hNGkVlsCGdCkBmV9ZvJGPWIhfGkIwplA=; b=wemi8qcudcge0OJOhbvduU4ydCq+CgnPHB6A9AJpNlyKFGbn2NYmqsvf6cCvsgX6Ho 2ITIwOmIs9+34KAECNFMPnL9XZxrSE/E9fPi9jYJQOSwAeLTbdyi2fxvJwjZwWf3owYl uRrjZGr9GyXMn2q4lJxg6E0YHsCMVsNT5TMKWuiepj6yvl6ssCADkSxbBIU9qifdtQDa bJmgzHLTPMfSwnub9h0AKX1+Sc2RoKOWf0bYJoAyh9RjnBqMIQk7r2j4juo5zdrQSgD6 TREAVvPQbLz17afKTxs2YaUzlcajHFblzQ+NESHY81zDN7tgwmIffT6cRmviensBAlva KnOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sUbR8qRU/u+hNGkVlsCGdCkBmV9ZvJGPWIhfGkIwplA=; b=Ijo30TRzzpd7Qvq9WF4BLb8mouhRNoBEVS3IqB+c8HeXv60fNukSbHixbAGyfMD+BZ WYGZinG+UBn3I6sAJ9V453qGgZ/ejgxYUr2KmTYVIMMQTMU+2oFVMgm6Pj5RI3tw8JpE oDy7IajtRTL9ZrzuPZENxYwVqXn0KaRkl29+fPZu0D6mB/rLmo6qcxG4jP6kvy9oIvwK blIDJwcCrEzsglgQ2BfBsLS2iyola8FlQ4vNRQZI00IherHtJ3BsuqRckxdmsDnMjuuK ttCu33SqC176QyXhV2dj5cs9seTolnvxI+7vO/dILD4eWeHQu7xR9+7CbtfsJil8W7X+ WVVg== X-Gm-Message-State: AEkoouvkeiGwufQUJR5PBFDuw3DFI31+AmCq7ZLpw2JR114SflSRZgq0QgmHSjGsTFNj3Q== X-Received: by 10.55.67.139 with SMTP id q133mr3533520qka.71.1471540756160; Thu, 18 Aug 2016 10:19:16 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id f17sm1560731qke.37.2016.08.18.10.19.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Aug 2016 10:19:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC22F84@ESESSMB209.ericsson.se> Date: Thu, 18 Aug 2016 13:19:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC22F84@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:19:20 -0000 The way we would write this, the INFO always has a command request or = response. The MSD can be in any convenient message that can carry a Call-Info. We understand that the MSD is related to the command and it=E2=80=99s = response. But it=E2=80=99s not necessary to get legalistic about it. = We have a valid INFO package, and we=E2=80=99re using it appropriately. = Carrying the MSD in Call-Info doesn=E2=80=99t really violate the spirit = of what 6086 says. Violating the letter is an interpretation. I = interpret it as allowed. I suppose we could ask sippcore for a = consensus call if you insist. And you keep ignoring WHY we=E2=80=99re trying to compromise with you. = The command/response is useful in other domains, and the MSD is = Additional Data. Brian > On Aug 18, 2016, at 1:12 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> We want there to be one way to transfer the MSD, which uses = Call-Info. You've made the argument that we can't use the same = Call-Info mechanism in non-INFO and also >in INFO. With the compromise = proposal, we are complying with this: the MSD is always sent as = Additional Data using Call-Info, while INFO is used to transfer a = >request/response data block. The fact that sometimes an INFO might = also have an MSD is essentially besides the point of INFO.=20 >=20 > Not since MSD transport is the reason you send the INFO to begin with. = And, sometimes MSD will be the *ONLY* thing you transport in the INFO, = which means it is not "might also have an MSD" - in such cases it will = ONLY have an MSD. >=20 > Regards, >=20 > Christer >=20 >=20 > At 4:10 PM +0000 8/18/16, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> ... >>=20 >>> We propose to use Call-Info to "label" the MSD so that all = instances=20 >>> of this data is treated as Additional Data, which it very clearly = is. >>=20 >> When you use INFO you define, within the info package specification,=20= >> that when you receive body X you treat it as Y. If that treatment has=20= >> some connection to how you treat Additional Data, fine, but that is a=20= >> separate issue from how you carry the information in SIP. >>=20 >> No need for any Call-Info "label". >>=20 >> Regards, >>=20 >> Christer >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Creativity is just having enough dots to connect. --Steve Jobs From nobody Thu Aug 18 10:29:02 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 ED96F12D85F for ; Thu, 18 Aug 2016 10:28:53 -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 wuHyOUIiFIYn for ; Thu, 18 Aug 2016 10:28:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 C3DED12DA75 for ; Thu, 18 Aug 2016 10:28:46 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-25-57b5f04b01ad Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 7A.6C.06563.B40F5B75; Thu, 18 Aug 2016 19:28:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 19:28:42 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat , Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+XQjsKbyy/DHr0O1aO7A3aI/6aBO9+6A Date: Thu, 18 Aug 2016 17:28:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC23090@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <8B9B1051-A1FC-49A5-86C2-030D9C60D446@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4BC226FD@ESESSMB209.ericsson.se> <1c0c6217-481d-6e3f-4db8-9742d92fff83@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC22D76@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.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7lq7Ph63hBve3aVo8vT+NzaJx0VNW iw1bjrNYrNhwgNXi+/MuRgdWj7/vPzB53P/2l91jyZKfTB53b11i8th65zFLAGsUl01Kak5m WWqRvl0CV8bPSReYCpa6VZxbtIulgbHFoouRk0NCwETi+apHzF2MXBxCAusZJd4eeMwG4Sxh lGg89RvI4eBgE7CQ6P6nDdIgIlAhMefGWiYQm1kgRuLHsbtg9cICixkldq1oZQFxRECaF/66 yAjRYSQx8fR5dhCbRUBV4vf0TrA4r4CvRMPDo4wQ2xZySsyb8p4VJMEJdNP2TyfZQGxGATGJ 76fWQK0Tl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0k0LnnCClGvJ3Fj6hQ2CFtbYtnC18wQ iwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB kXZwy2/dHYyrXzseYhTgYFTi4U3YvzVciDWxrLgy9xCjBAezkgjvo3dAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYw1bQUyLwtsrz04tG/pzU0N827e qGb8sfS2jvjU1FzfTA7/MrUoDXGZ/DieQ08Xi/izlOpfXO/+8O4b0dXrlCVsLFRSv02c+4R7 oUbK27WX+/9W+gs/mLW4zGhrqs+lTZmFTC/Sl+TLfOmTybuau4ftdfGRTrMPR+6ZndT2NQw0 XiMXcFoq+IUSS3FGoqEWc1FxIgBi5hZPsAIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:28:54 -0000 Hi, >>>>> We'll work up an example. >>>>> >>>>> There is no restriction on an INFO carrying body parts not=20 >>>>> associated with the INFO. >>>> >>>> There is a restriction saying that any new INFO usage must use the=20 >>>> info package mechanism. >>>> >>>> The only reason RFC 6086 allows carrying body parts not associated=20 >>>> with an info package is for backward compatibility with legacy INFO=20 >>>> usages. >>> >>> IMO the specification of INFO has no business disallowing "extra"=20 >>> body parts that are serving other needs that are incidental to the=20 >>> primary purpose of INFO. >>> >>> This is no different than the situation with INVITE. INVITE has=20 >>> *one* body part that is tightly bound to the function of the =20 >>> message. It is identified by content-disposition "session" and=20 >>> content-type application/sdp. But it doesn't disallow other body=20 >>> parts, or the multipart wrapper that is needed when there are=20 >>> multiple body parts. >>> There is no reason for the situation to be any different for INFO. >> >> MSD transport is one of the main reasons we send the INFO to begin -=20 >> it defines INFO usage, which means you have to use an info package. >> >> MSD is *not* some information that is piggybacked onto the message=20 >> that someone just happens to send for some other purpose. > >Hi Christer, > >We're saying that INFO will be used for a request/response protocol. If a= request is for the IVS to send an >updated MSD, the IVS can send that MSD in any convenient SIP message.=20 I don't consider the MSD something can is sent in any convenient SIP messag= e. Sending the MSD is a main part of eCall, and we should use a proper mech= anism for it - we shall not send it "in any convenient SIP message". >As Paul says, it might usually be the INFO that contains the response to t= he request (the ACK) but it isn't required to be, it might for example=20 >be in a re-INVITE sent for some other purpose. So, now you are saying that in cases where MSD is the ONLY thing you send (= i.e. there is no ACK), then you would use re-INVITE????? This is only getting more and more messy... Regards, Christer > > > In this case, we would have a body part=20 > associated with the Call-Info CID (the MSD), as well as the body part=20 > that is associated with the INFO (the ack). As per the prior message,=20 > the MSD wouldn't be limited to to the ACK INFO, even if it usually=20 > occurred there. >> >> Brian >>> On Aug 18, 2016, at 2:23 AM, Christer Holmberg=20 >>> >>> wrote: >>> >>> Hi, >>> >>> Please see my reply inline. But, I=A9-d like you to send an INFO=20 >>> example according to your example, to make sure we are talking=20 >>> about the same thing. >>> >>>> You are missing the point of the suggested compromise. >>>> >>>> This is NOT a legacy INFO. It=A9-s a new-style INFO package, =20 >>>> conforming to 6086. >>>> >>>> There is only ONE INFO part. It only carries the metadata/control =20 >>>> block, and its ACK. >>>> >>>> You send an INFO, with the metadata/control body part, with the =20 >>>> proper INFO mime type and content disposition. The MSD/VEDS is not th= ere. >>>> You send the MSD/VEDS as Additional Data, in a separate body part, =20 >>>> with the additional data MIME type and content disposition using=20 >>>> Call-Info. >>>> >>>> So there are two parts in the body. One is the INFO block, the =20 >>>> other is the Additional Data block, with the Call-Info header =20 >>>> pointing to it. The latter isn=A9-t legacy use of INFO, it=A9-s=20 >>>> permitted use of Call-Info. 6069 expressly permits this. >>> >>> >>> While RFC 6086 does allow usage of other C-D values than =20 >>> =A9=AFinfo-package=A9- for specific body parts, the body parts are stil= l =20 >>> associated with the Info Package - which means you know the =20 >>> semantics, and you know that the receiver will support the body part. >>> So, I still don=A9-t see what you need Call-Info for? >>> >>> Yes, 6086 does contain an example where one body part is not =20 >>> associated with the Info Package to begin with. But, again, that is =20 >>> to address legacy usages of INFO. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> >>>>> On Aug 17, 2016, at 6:20 PM, Christer Holmberg > >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I thought we discussed usage of legacy (non-Info-Package) INFOs =20 >>>>> already. RFC 6086 allows it for backward compatibility. Any new =20 >>>>> usage MUST use an Info Package. >>>>> >>>>> And, even if it was allowed, using two different INFO mechanisms =20 >>>>> would make things even more complicated. >>>>> >>>>> I'll let others decide on whether MSD is considered additional=20 >>>>> data or not, but I don't think it's relevant because additional=20 >>>>> data is not a legacy INFO usage, nor does additional data update RFC= 6086. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >>>>> Sent: 17 August 2016 23:57 >>>>> To: Christer Holmberg ; Paul =20 >>>>> Kyzivat ; Drage, Keith (Nokia - GB) =20 >>>>> ; ecrit@ietf.org; Brian Rosen =20 >>>>> >>>>> Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage=20 >>>>> not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11-=20 >>>>> Call-Info usage brings no value) >>>>> >>>>> Hi Everyone, >>>>> >>>>> The authors wish to propose a solution to the concerns that have =20 >>>>> been raised. We recognize that the vehicle data (MSD for eCall=20 >>>>> and VEDS for >>>>> car-crash) is properly considered additional data in the context=20 >>>>> of RFC 7852, while the metadata/control block can be considered=20 >>>>> its own request/response protocol. With that in mind, our=20 >>>>> proposal is to have the INFO package associated with the=20 >>>>> metadata/control block but not the MSD nor VEDS. For a mid-call=20 >>>>> update request, the PSAP sends a metadata/control block=20 >>>>> requesting an updated MSD (or VEDS) in INFO. >>>>> The IVS in turn sends an INFO with a metadata/control block =20 >>>>> acknowledging the request with a successful result. Both INFO =20 >>>>> messages contain a metadata/control block associated with the INFO =20 >>>>> package and not referenced by a Call-Info header field. The INFO =20 >>>>> sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 =20 >>>>> additional data, referenced by a Call-Info header field. There =20 >>>>> would be two body parts in the INFO from the IVS to the PSAP, each =20 >>>>> with its appropriate MIME type and Content-Disposition. One body =20 >>>>> part is associated with the INFO package and is the response to=20 >>>>> the request. >>>>> The second body part is the updated MSD and is referenced by Call-In= fo. >>>>> This more cleanly separates the request/response protocol from=20 >>>>> the vehicle data. The request/response protocol uses INFO, is =20 >>>>> associated with an INFO package, and carries data with the =20 >>>>> Info-Package Content-Disposition. INFO messages sent by the IVS =20 >>>>> may also contain vehicle data not associated with the INFO package. >>>>> In eCall, this allows the PSAP to request a mid-call update and=20 >>>>> the IVS to respond. In car-crash, this allows the PSAP to request=20 >>>>> the vehicle to take other actions (such as flashing the lights). =20 >>>>> In all cases, the vehicle responds to a request with an=20 >>>>> acknowledgment (and indicates if the request was successfully carrie= d out). >>>>> >>>>> Note that RFC 6086 permits INFO messages to also carry data not =20 >>>>> associated with INFO packages. >>>>> >>>>> This has an additional advantage of making it cleaner and easier=20 >>>>> to reuse the emergency call request/response protocol later, in=20 >>>>> other documents (e.g., so the PSAP can request building sensor data)= . >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself o= nly >>>>> -------------- Randomly selected tag: --------------- It is=20 >>>>> easier to fight for one's principles than to live up to them. >>>>> --Alfred Adler >>>>> >>>>> _______________________________________________ >>>>> 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: --------------- George Orwell was an = optimist. From nobody Thu Aug 18 10:56: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 7A76712D798 for ; Thu, 18 Aug 2016 10:55:37 -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 kCiuFwo7SXHK for ; Thu, 18 Aug 2016 10:55:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7233012D88F for ; Thu, 18 Aug 2016 10:52:12 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-45-57b5f5c94ade Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id C9.7E.06563.9C5F5B75; Thu, 18 Aug 2016 19:52:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 19:52:09 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+XSm7+Lam0WOAkmHBEDMa8VjkqBO+Rmg Date: Thu, 18 Aug 2016 17:52:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC23187@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC22F84@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdTvfU163hBi/fmlk8vT+NzaJx0VNW i+/PuxgdmD3uf/vL7rFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZXya1s5W8Em+4u/rVawN jB3yXYycHBICJhK/lyxg7WLk4hASWM8osXnXAShnCaPE9r+7GbsYOTjYBCwkuv9pgzSICChL 7LzVyQ5iMwvUSTza2wdmCwssZJR4uDwGomYRo8Ti5XIQtpHEop4pzCA2i4CqxOTdnxlBbF4B X4k9aydD7XrNJdG5oQUswSngJNG55zpYA6OAmMT3U2uYIJaJS9x6Mp8J4moBiSV7zjND2KIS Lx//Y4WwlSQalzxhBbmZWUBTYv0ufYhWRYkp3Q/ZIfYKSpyc+YRlAqPoLCRTZyF0zELSMQtJ xwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgZFzcMtv3R2Mq187HmIU4GBU4uFN2L81 XIg1say4MvcQowQHs5II76N3QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNT UwtSi2CyTBycUg2My//d4tfsPZQiEblz9/p5glNSHu/JSohz51snZ2Ry59HG1bf3bJorXi9+ y6R/uhqfBp9/zEl9s6fidx43vj+Yk8fZfTxP54rSUg3xO+2T+4TOFhXLMayfXCUQkR8YF+Dm E6TaW/v26TdzxiU7ubRWmfDIM6WtK9QtaIvmaGfbsKn3ccjaW5JKLMUZiYZazEXFiQCV098i mAIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 18 Aug 2016 17:55:37 -0000 X-List-Received-Date: Thu, 18 Aug 2016 17:55:37 -0000 SGksDQoNCj5UaGUgd2F5IHdlIHdvdWxkIHdyaXRlIHRoaXMsIHRoZSBJTkZPIGFsd2F5cyBoYXMg YSBjb21tYW5kIHJlcXVlc3Qgb3IgcmVzcG9uc2UuDQo+VGhlIE1TRCBjYW4gYmUgaW4gYW55IGNv bnZlbmllbnQgbWVzc2FnZSB0aGF0IGNhbiBjYXJyeSBhIENhbGwtSW5mby4NCj4NCj5XZSB1bmRl cnN0YW5kIHRoYXQgdGhlIE1TRCBpcyByZWxhdGVkIHRvIHRoZSBjb21tYW5kIGFuZCBpdOKAmXMg cmVzcG9uc2UuICBCdXQgaXTigJlzIG5vdCBuZWNlc3NhcnkgdG8gZ2V0IGxlZ2FsaXN0aWMgYWJv dXQgaXQuICBXZSBoYXZlIGEgdmFsaWQgSU5GTyBwYWNrYWdlLCBhbmQgd2XigJlyZSB1c2luZyBp dCA+YXBwcm9wcmlhdGVseS4gIENhcnJ5aW5nIHRoZSBNU0QgaW4gQ2FsbC1JbmZvIGRvZXNu4oCZ dCByZWFsbHkgdmlvbGF0ZSB0aGUgc3Bpcml0IG9mIHdoYXQgNjA4NiBzYXlzLiANCg0KSSdtIGFm cmFpZCBJIHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggdGhhdC4gDQoNClNlbmRpbmcgcmVxL2FjayBh bmQgTVNEIGlzIHRoZSBtYWluIHB1cnBvc2Ugb2YgdGhlIElORk8sIGFuZCBqdXN0IGJlY2F1c2Ug eW91IHVzZSBpbmZvIHBhY2thZ2UgZm9yIHJlcS9hY2sgZG9lc24ndCBtZWFuIHlvdSBkb24ndCBo YXZlIHRvIHVzZSBpdCBmb3IgTVNELg0KDQpJZiBNU0Qgd291bGQgYmUgc29tZXRoaW5nIHBlb3Bs ZSBoYXZlIHVzZWQgSU5GTyBmb3Igc2VuZGluZyBsb25nIGJlZm9yZSA2MDg2LCBJJ2QgYWdyZWUg d2l0aCB5b3UuIEJ1dCwgdGhhdCdzIG5vdCB0aGUgY2FzZS4gU2VuZGluZyBNU0QgZGVmaW5lcyBh IG5ldyBJTkZPIHVzYWdlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQogVmlvbGF0 aW5nIHRoZSBsZXR0ZXIgaXMgYW4gaW50ZXJwcmV0YXRpb24uICBJIGludGVycHJldCBpdCBhcyBh bGxvd2VkLiAgSSBzdXBwb3NlIHdlIGNvdWxkIGFzayBzaXBwY29yZSBmb3IgYSBjb25zZW5zdXMg Y2FsbCBpZiB5b3UgaW5zaXN0Lg0KDQpBbmQgeW91IGtlZXAgaWdub3JpbmcgV0hZIHdl4oCZcmUg dHJ5aW5nIHRvIGNvbXByb21pc2Ugd2l0aCB5b3UuICBUaGUgY29tbWFuZC9yZXNwb25zZSBpcyB1 c2VmdWwgaW4gb3RoZXIgZG9tYWlucywgYW5kIHRoZSBNU0QgaXMgQWRkaXRpb25hbCBEYXRhLg0K DQpCcmlhbg0KDQo+IE9uIEF1ZyAxOCwgMjAxNiwgYXQgMToxMiBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4g DQo+PiBXZSB3YW50IHRoZXJlIHRvIGJlIG9uZSB3YXkgdG8gdHJhbnNmZXIgdGhlIE1TRCwgd2hp Y2ggdXNlcyBDYWxsLUluZm8uICBZb3UndmUgbWFkZSB0aGUgYXJndW1lbnQgdGhhdCB3ZSBjYW4n dCB1c2UgdGhlIHNhbWUgQ2FsbC1JbmZvIG1lY2hhbmlzbSBpbiBub24tSU5GTyBhbmQgYWxzbyA+ aW4gSU5GTy4gIFdpdGggdGhlIGNvbXByb21pc2UgcHJvcG9zYWwsIHdlIGFyZSBjb21wbHlpbmcg d2l0aCB0aGlzOiB0aGUgTVNEIGlzIGFsd2F5cyBzZW50IGFzIEFkZGl0aW9uYWwgRGF0YSB1c2lu ZyBDYWxsLUluZm8sIHdoaWxlIElORk8gaXMgdXNlZCB0byB0cmFuc2ZlciBhID5yZXF1ZXN0L3Jl c3BvbnNlIGRhdGEgYmxvY2suICBUaGUgZmFjdCB0aGF0IHNvbWV0aW1lcyBhbiBJTkZPIG1pZ2h0 IGFsc28gaGF2ZSBhbiBNU0QgaXMgZXNzZW50aWFsbHkgYmVzaWRlcyB0aGUgcG9pbnQgb2YgSU5G Ty4gDQo+IA0KPiBOb3Qgc2luY2UgTVNEIHRyYW5zcG9ydCBpcyB0aGUgcmVhc29uIHlvdSBzZW5k IHRoZSBJTkZPIHRvIGJlZ2luIHdpdGguIEFuZCwgc29tZXRpbWVzIE1TRCB3aWxsIGJlIHRoZSAq T05MWSogdGhpbmcgeW91IHRyYW5zcG9ydCBpbiB0aGUgSU5GTywgd2hpY2ggbWVhbnMgaXQgaXMg bm90ICJtaWdodCBhbHNvIGhhdmUgYW4gTVNEIiAtIGluIHN1Y2ggY2FzZXMgaXQgd2lsbCBPTkxZ IGhhdmUgYW4gTVNELg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiANCj4g QXQgNDoxMCBQTSArMDAwMCA4LzE4LzE2LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gDQo+ PiBIaSwNCj4+IA0KPj4gLi4uDQo+PiANCj4+PiBXZSBwcm9wb3NlIHRvIHVzZSBDYWxsLUluZm8g dG8gImxhYmVsIiB0aGUgTVNEIHNvIHRoYXQgYWxsICANCj4+PiBpbnN0YW5jZXMgb2YgdGhpcyBk YXRhIGlzIHRyZWF0ZWQgYXMgQWRkaXRpb25hbCBEYXRhLCB3aGljaCBpdCAgdmVyeSBjbGVhcmx5 IGlzLg0KPj4gDQo+PiBXaGVuIHlvdSB1c2UgSU5GTyB5b3UgZGVmaW5lLCB3aXRoaW4gdGhlIGlu Zm8gcGFja2FnZSBzcGVjaWZpY2F0aW9uLCANCj4+IHRoYXQgd2hlbiB5b3UgcmVjZWl2ZSBib2R5 IFggeW91IHRyZWF0IGl0IGFzIFkuIElmIHRoYXQgdHJlYXRtZW50IGhhcyANCj4+IHNvbWUgY29u bmVjdGlvbiB0byBob3cgeW91IHRyZWF0IEFkZGl0aW9uYWwgRGF0YSwgZmluZSwgYnV0IHRoYXQg aXMgYSANCj4+IHNlcGFyYXRlIGlzc3VlIGZyb20gaG93IHlvdSBjYXJyeSB0aGUgaW5mb3JtYXRp b24gaW4gU0lQLg0KPj4gDQo+PiBObyBuZWVkIGZvciBhbnkgQ2FsbC1JbmZvICJsYWJlbCIuDQo+ PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IENocmlzdGVyDQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QN Cj4+IEVjcml0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0DQo+IA0KPiANCj4gLS0NCj4gUmFuZGFsbCBHZWxsZW5zDQo+IE9waW5pb25zIGFy ZSBwZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBv bmx5DQo+IC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0t LS0tDQo+IENyZWF0aXZpdHkgaXMganVzdCBoYXZpbmcgZW5vdWdoIGRvdHMgdG8gY29ubmVjdC4g ICAtLVN0ZXZlIEpvYnMNCg0K From nobody Fri Aug 19 00:36: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 81C3B12D92F for ; Fri, 19 Aug 2016 00:36:43 -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 GTz4RPNVwo3e for ; Fri, 19 Aug 2016 00:36:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 F11DD12D126 for ; Fri, 19 Aug 2016 00:36:40 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-0d-57b6b7061bd2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 23.00.06563.607B6B75; Fri, 19 Aug 2016 09:36:39 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 09:36:38 +0200 From: Ivo Sedlacek To: Brian Rosen Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR98ZAcHBCKSc2akOhqFpsiJK/HaBNgrEAgAAXd4CAAAZrAIAAJduAgADMwgCAACJEAIAACAsAgAEoGQA= Date: Fri, 19 Aug 2016 07:36:37 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F12D2@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdXpd9+7Zwg29TeCye3p/GZtG46Cmr xYoNB1gdmD3+vv/A5HH/2192jyVLfjIFMEdx2aSk5mSWpRbp2yVwZfz/PYW94JZKxZSp01ka GB8odzFyckgImEh8v/aFuYuRi0NIYD2jxOYvxxghnCWMEgf+bGACqWIT0JOYuOUIK4gtIqAs sfNWJ3sXIwcHs4C3xNr9kiBhYYGFjBIPl8dAlCxilFi8XA6kREQgSeLUD1uQMIuAqsTuVoiJ vAK+EmfO3GGDWNXIKXFoznQWkASngJPEro/tzCA2o4CsxNU/vYwgNrOAuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1YIW1Fi51mQXpDTNCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis5CMnUWQscs JB2zkHQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYNwe3/Nbdwbj6teMhRgEORiUe 3oT9W8OFWBPLiitzDzFKcDArifCmbNkWLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBA emJJanZqakFqEUyWiYNTqoHR7lno7o8HJJKub2Qwniqw4VXmBLY3zov6SkL353Y+ObDIaPb+ O373JQINnxg/3Dy1+VRqjTmfbFfj3Uc9/c9XeRSsXlzz69usTYfDTf6IC8SXCujy2y6LatAX rOayl1K9x/exPduqxXTqAi7xW8vPcEksVO3UWG1YPG/36W0+lfvTu7of1exXYinOSDTUYi4q TgQAlRPeUpcCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 19 Aug 2016 07:36:43 -0000 SGVsbG8sDQoNCj4gUGxlYXNlIHRyeSB0byBsb29rIGF0IHRoaXMgZnJvbSBhIHdpZGVyIHBlcnNw ZWN0aXZlLiAgWW91IGFyZSBjb25jZW50cmF0aW5nIA0KPiBvbiB2ZXJ5IGxpbWl0ZWQgZXhhbXBs ZSBvZiBhIG1vcmUgZ2VuZXJhbCBwcm9ibGVtIG9mIFBTQVBzIGJlaW5nIGFibGUgdG8gDQo+IG1h bmFnZSBkYXRhIGJlaW5nIHNlbnQgdG8gdGhlbSBmcm9tIGEgZGV2aWNlLg0KDQpXZSBhcmUgc29s dmluZyBlQ2FsbC4NCg0KSWYgeW91IHdpc2ggdG8gc29sdmUgb3RoZXIgcHJvYmxlbXMsIHBsZWFz ZSBicmluZyBhIHNlcGFyYXRlIGRyYWZ0Lg0KDQo+IFRoZSBNU0QgY29tZXMgaW4gbW9yZSB0aGFu IG9uZSB3YXk6IHVuc29saWNpdGVkLCBhbmQgcmVxdWVzdGVkLiAgVGhlIGRhdGEgDQo+IGJsb2Nr LCB0aGUgTVNEIGl0c2VsZiwgaXMgdGhlIHNhbWUuICBJdHMgdXNlIGlzIHRoZSBzYW1lLiAgVGhl IFhNTCBpcyB0aGUgDQo+IHNhbWUuICBJdCBJUyBBZGRpdGlvbmFsIERhdGEuDQoNCk1TRCBpcyBk YXRhIHdob3NlIHNlbmRpbmcgaW4gSU5GTyBpcyBhc3NvY2lhdGVkIHdpdGggdXNhZ2Ugb2YgdGhl IGluZm8gcGFja2FnZSBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QuIA0KDQpBcyBzdWNoLCB0 aGUgaW5mbyBwYWNrYWdlIHByb3ZpZGVzIHRoZSBzZW1hbnRpYyBvZiB0aGUgZGF0YS4gDQoNCldo eSBkbyB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgIkFkZGl0aW9uYWwgRGF0YSI/DQoNCj4gVGhl IGNvbW1hbmQgd2Ugc2VuZCB0byByZXF1ZXN0IGluIG1pZCBjYWxsIGlzIGFuIGFjdGl2ZSBjb21t YW5kL2NvbnRyb2wgYW5kIA0KPiByZXNwb25zZSBwcm90b2NvbCB0aGF0IGhhcyBhIG11Y2ggYmln Z2VyIHVzZSB0aGFuIGp1c3QgZUNhbGwuICBUaGVyZSBhcmUgbWFueSANCj4gZXhhbXBsZXMgb2Yg dGhpcywgaW5jbHVkaW5nIHRoZSBvbmUgUmFuZGFsbCBtZW50aW9uZWQ6IGdldHRpbmcgZW52aXJv bm1lbnRhbCANCj4gaW5mb3JtYXRpb24gZnJvbSBhIGJ1aWxkaW5nLiAgSSBjYW4gZ2l2ZSB5b3Ug cGxlbnR5IG9mIG90aGVycywgZm9yIGV4YW1wbGUsIA0KPiB5b3UgbWF5IGJlIGFibGUgdG8gY29u dHJvbCB0aGUgZWxldmF0b3JzIG9mIHRoYXQgYnVpbGRpbmcsIG9yIGEgY29udGFpbmVyIG1heSAN Cj4gaGF2ZSBzb21lIGtpbmQgb2YgbGVhayBkZXRlY3RvciB0aGF0IHlvdSB3YW50IGFuIHVwZGF0 ZSBmcm9tLiANCg0KVGhlIGluZm8gcGFja2FnZSBpcyBpbnRyb2R1Y2VkIGZvciBlQ2FsbCBhbmQg TVNEIHRyYW5zcG9ydCBhcyBjYW4gYmUgc2VlbiBmcm9tIGl0cyBuYW1lOiANCg0KCWVtZXJnZW5j eUNhbGxEYXRhLmVDYWxsLk1TRA0KDQpHZXR0aW5nIGVudmlyb25tZW50YWwgaW5mb3JtYXRpb24g ZnJvbSBhIGJ1aWxkaW5nIGlzIHVucmVsYXRlZCB0byBlQ2FsbCBhbmQgc2VuZGluZyBvZiBNU0Qs IHNvIEkgd29uZGVyIGhvdyB5b3UgY2FuIHVzZSB0aGlzIGluZm8gcGFja2FnZSBmb3IgaXQuDQoN Cj4gVGhpcyBjb21tYW5kL2NvbnRyb2wgbWVjaGFuaXNtIG5lZWRzIHRvIGJlIHN0YW5kYXJkaXpl ZCwgaW5kZXBlbmRlbnRseSBvZiANCj4gZUNhbGwsIGJ1dCB3ZeKAmXJlIG5vdCBnb2luZyB0byB0 cnkgdG8gZG8gdGhhdCBpbiB0aGlzIGRvY3VtZW50LiAgQWxsIHdlIHdhbnQgDQo+IHRvIGRvIGlz IHNlcGFyYXRlIHRoZSBwaWVjZSB0aGF0IHZlcnkgY2xlYXJseSBpcyBBZGRpdGlvbmFsIERhdGEs IGZyb20gdGhlIA0KPiBjb21tYW5kL2NvbnRyb2wgYW5kIGl04oCZcyBBY2svTmFrIHJlc3BvbnNl LiAgU2luY2Ugd2UgcmVjb2duaXplIHRoYXQgYW55IG90aGVyIA0KPiBpbnN0YW5jZSBvZiBjb21t YW5kL2NvbnRyb2wgdGhhdCBpcyBtaWQgY2FsbCBpbml0aWF0ZWQgd291bGQgbmVlZCBpdHMgb3du IA0KPiBJTkZPIHBhY2thZ2UsIHdlIGRvbuKAmXQgbmVlZCB0byBkbyBtdWNoIHRvIG1ha2UgZUNh bGwgYW4gaW5zdGFuY2Ugb2YgYSBtb3JlIA0KPiBnZW5lcmFsIGNvbW1hbmQvY29udHJvbCBtZWNo YW5pc20uDQo+DQo+IFdlIHByb3Bvc2UgdG8gdXNlIENhbGwtSW5mbyB0byDigJxsYWJlbOKAnSB0 aGUgTVNEIHNvIHRoYXQgYWxsIGluc3RhbmNlcyBvZiB0aGlzIA0KPiBkYXRhIGlzIHRyZWF0ZWQg YXMgQWRkaXRpb25hbCBEYXRhLCB3aGljaCBpdCB2ZXJ5IGNsZWFybHkgaXMuICANCg0KQXMgZWFj aCBkYXRhIGlzIHNlbnQgdXNpbmcgaXRzIG93biBpbmZvIHBhY2thZ2UsIHNlbWFudGljIG9mIHRo aXMgZGF0YSBpcyBpbmRpY2F0ZWQgYnkgdGhlIGluZm8gcGFja2FnZS4gIE5vIG5lZWQgb2YgYWRk aXRpb25hbCBDYWxsLUluZm8gYWdhaW4uDQogDQo+IFdpdGggcmVzcGVjdCB0byBVQVMgYW5kIFBy b3h5IGlzc3VlcywgYWdhaW4sIHBsZWFzZSBjb25zaWRlciB0aGF0IGVDYWxsIGlzIGEgDQo+IHZl cnkgbGltaXRlZCBleGFtcGxlIG9mIGEgbXVjaCBiaWdnZXIgcHJvYmxlbS4gIENvbnNpZGVyLCBm b3IgZXhhbXBsZSwgaWYgYSANCj4gY2FsbCB3YXMgZHJvcHBlZCwgYW5kIHRoZSBQU0FQIGNhbGxl ZCB0aGUgdmVoaWNsZSBiYWNrLiAgV2Ugd291bGQgbGlrZSB0byBiZSANCj4gYWJsZSB0byByZXF1 ZXN0IHRoZSBNU0QsIGJ1dCBub3cgdGhlIGNhbGxlciBpcyB0aGUgUFNBUC4gIEkgZG9u4oCZdCB0 aGluayBhIA0KPiBwcm94eSB3b3VsZCBoYXZlIGFueSBwcm9ibGVtcyB3aXRoLCBvciB3b3VsZCBk byBhbnl0aGluZyB3aXRoIHRoZSBJTkZPIA0KPiBwYWNrYWdlIG90aGVyIHRoYW4gZm9yd2FyZCBp dCBsaWtlIGFueSBvdGhlciBJTkZPLiAgVGhlIHNhbWUgYXMgaXMgd291bGQgd2l0aCBDYWxsLUlu Zm8uDQoNCllvdSBhcmUgc3RpbGwgbm90IGFuc3dlcmluZyB0aGUgcXVlc3Rpb246IA0KDQoJQW5k IEkgc3RpbGwgaGF2ZSBub3QgZ290IGFuIGFuc3dlciB0byBteSBxdWVzdGlvbiBvbiB3aHkgaXMg dXNpbmcgdGhlIENhbGwtSUQgaW4gSU5GTyByZXF1ZXN0PyBVQVMgb2YgSU5GTyByZXF1ZXN0PyBQ cm94eSBoYW5kbGluZyBJTkZPIHJlcXVlc3Q/DQoNClRoZSBxdWVzdGlvbiByZWxhdGVkIHRvIHVz YWdlIG9mIENhbGwtSW5mbyBpbiBJTkZPIHJlcXVlc3QuDQoNClBTQVAgY2FsbC1iYWNrIGlzIG5v dCBkb25lIHVzaW5nIElORk8uDQogDQo+IFRoZSBvbmx5IGNvbXBsZXhpdHkgaXMgdHdvIE1JTUUg Ym9keSBwYXJ0cyBhbmQgdGhlIENhbGwtSW5mbyBoZWFkZXIuICBZZWFoLCANCj4gdGhhdOKAmXMg bW9yZSwgdGhyZWUgbGluZXMsIGFuZCBhIGxpdHRsZSBleHRyYSBwcm9jZXNzaW5nLiAgDQo+IA0K PiBUaGlzIGlzIGEgY29tcHJvbWlzZSBiZXR3ZWVuIHdoYXQgYXV0aG9ycyB3YW50IGFuZCB5b3Ug d2FudC4gIFBsZWFzZSByZWNvbnNpZGVyLg0KDQpUaGlzIGNvbXBsZXhpdHkgaXMgZW50aXJlbHkg dW5uZWNlc3NhcnkuDQoNClBsZWFzZSByZWNvbnNpZGVyLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZv IFNlZGxhY2VrDQo= From nobody Fri Aug 19 00:43: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 C5C9D12D69C for ; Fri, 19 Aug 2016 00:43:04 -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 niPAbZ9ekr4E for ; Fri, 19 Aug 2016 00:43:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2853B12D126 for ; Fri, 19 Aug 2016 00:43:03 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-e7-57b6b88440d1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 0B.4F.04209.488B6B75; Fri, 19 Aug 2016 09:43:01 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 09:42:59 +0200 From: Ivo Sedlacek To: Brian Rosen , Christer Holmberg Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) Thread-Index: AQHR+XSmq56dobq1WUW+XLhzHyGXgKBP52Tw Date: Fri, 19 Aug 2016 07:42:59 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F12FA@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101164BF66F@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C0868@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164C28D8@ESESSMB301.ericsson.se> <16127ff4-872f-7c6d-d4ee-f333e02cf5fe@alum.mit.edu> <39B5E4D390E9BD4890E2B31079006101164C3C20@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101164E6D96@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC1E610@ESESSMB209.ericsson.se> <7C3DA1F8-82DE-46FC-B43D-032B43AA8585@brianrosen.net> <39B5E4D390E9BD4890E2B31079006101164F0C0F@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC228D7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC22F84@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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9XLd1x7Zwg+/vhCye3p/GZtG46Cmr xffnXYwOzB73v/1l91iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mlaea2EsmMFccfrWRfYG xh7mLkYODgkBE4nnvx26GLk4hATWM0ps6p7BCOEsYZTY9fEekMPJwSagJzFxyxFWEFtEIFLi +dnHzCA2s0CIxMtjm8DiwgILGSUeLo+BqFnEKLF4uRyEbSTxpuULWD2LgKrExHPNYDavgK9E T+M0qGWvuSQ6N7SALeMUcJLo3HMdrIhRQFbi6p9eRohl4hK3nsxnArElBAQkluw5zwxhi0q8 fPyPFcJWlNh5th3sM2YBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0L GFlWMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgRGzsEtv1V3MF5+43iIUYCDUYmHd8H3reFC rIllxZW5hxglOJiVRHhTtmwLF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1 tSC1CCbLxMEp1cCYn36x/+t874tHfval7PR7dO6e17RvMntboxaaOjC0MbKf7M17NG1+g2OC f1js4fTJV4Q3qrc9ZcyYE7rpwIRv7N+03Z2853jrzU6QOVwpcmabwoG5+nHOF016Pkbd3vG1 +86UaXL8b09rptz6cYQ75tWdS88Ube/qRXhddyx7u+3+NsGm4A8uSizFGYmGWsxFxYkA+CfS xZgCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value) 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, 19 Aug 2016 07:43:05 -0000 PiBUaGUgTVNEIGNhbiBiZSBpbiBhbnkgY29udmVuaWVudCBtZXNzYWdlIHRoYXQgY2FuIGNhcnJ5 IGEgQ2FsbC1JbmZvLg0KDQpJIGFtIHN0aWxsIHdhaXRpbmcgZm9yIGFuc3dlciBvbiB0aGUgZm9s bG93aW5nOg0KDQoJQW5kIEkgc3RpbGwgaGF2ZSBub3QgZ290IGFuIGFuc3dlciB0byBteSBxdWVz dGlvbiBvbiB3aG8gaXMgdXNpbmcgdGhlIENhbGwtSUQgaW4gSU5GTyByZXF1ZXN0PyBVQVMgb2Yg SU5GTyByZXF1ZXN0PyBQcm94eSBoYW5kbGluZyBJTkZPIHJlcXVlc3Q/DQoNCktpbmQgcmVnYXJk cw0KDQpJdm8NCg== From nobody Fri Aug 19 00:46: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 A8B9C12DA77 for ; Fri, 19 Aug 2016 00:46:21 -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 XMudCPbLb3Am for ; Fri, 19 Aug 2016 00:46:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 ED7B212DA1F for ; Fri, 19 Aug 2016 00:46:19 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-10-57b6b94af6ce Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id A4.77.02553.A49B6B75; Fri, 19 Aug 2016 09:46:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 09:46:16 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9A== Date: Fri, 19 Aug 2016 07:46:15 +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.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D3DC94EDD087christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7t67Xzm3hBus2iVg0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKfn7zEVTBWseLq7k6mBcRFfFyMHh4SAiUTHAscuRi4OIYH1 jBITr29jg3CWMErs7tnCDlLEJmAh0f1Pu4uRk0NEQFViw5mVjCBhYQFriVcn4iHCDhIvLuwF C4sI6EkcP88OEmYBqv4/dwsTiM0rYCWx5sxaFhCbUUBM4vupNWBxZgFxiVtP5oPZEgICEkv2 nGeGsEUlXj7+xwpiiwKN/P51NlRcUaL9aQMjRG+8xI/NfawQ8wUlTs58wjKBUWgWkrGzkJTN QlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEj8PP2ZDVLGDkWMUoWpxanJSbbmSkl1qU mVxcnJ+nl5dasokRGCUHt/w22MH48rnjIUYBDkYlHt6E/VvDhVgTy4orcw8xSnAwK4nwpmzZ Fi7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBkb8pOHnC n2cZv7b18+/QE3ziY7zkSL3UKecZea0/EgKL/4u6Hi3oOflv29H/U1m+HVW86XFp5+pryiYP mOQ3xu7j0uF04zth63LxQcr99oP8nZFbuLLWXW3JUb20tDiv5+BPuYeXnsSZGbRKFwYoro2+ vPKK/okZOgoeVS9L9q5Sr5CYJ9Nfq8RSnJFoqMVcVJwIAPOe+UGOAgAA Archived-At: Subject: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 07:46:22 -0000 --_000_D3DC94EDD087christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (NOTE that this e-mail is not related to the Info Package discussion) Hi, Assume the PSAP sends a request for MSD to the UA. The UA sends the MSD back. Why does the UA needs to send ACK? The MSD will acknowledge the request, wo= n=92t it? I do understand that the UA needs something if it won=92t send the MSD (or = whatever data was requested), e.g. if there was something wrong with the re= quest). But, if the UA does accept the request, and does send the data, I d= on=92t see why the explicit ACK is needed. It will only add message size (a= nd maybe even additional INFO messages). Regards, Christer --_000_D3DC94EDD087christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
(NOTE that this e-mail is not related to the Info Package discussion)<= /div>

Hi,

Assume the PSAP sends a request for MSD to the UA.

The UA sends the MSD back.

Why does the UA needs to send ACK? The MSD will acknowledge the reques= t, won=92t it?

I do understand that the UA needs something if it won=92t send the MSD= (or whatever data was requested), e.g. if there was something wrong with t= he request). But, if the UA does accept the request, and does send the data= , I don=92t see why the explicit ACK is needed. It will only add message size (and maybe even additional INFO m= essages).

Regards,

Christer
--_000_D3DC94EDD087christerholmbergericssoncom_-- From nobody Fri Aug 19 07:20: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 B6D1212DA0D for ; Fri, 19 Aug 2016 07:19:58 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 h0cHCbotkqno for ; Fri, 19 Aug 2016 07:19:57 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 8A53912D9FC for ; Fri, 19 Aug 2016 07:19:57 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-02v.sys.comcast.net with SMTP id akapb5XRP0MKRakeKbmcIo; Fri, 19 Aug 2016 14:19:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with SMTP id akeKbD8xF4L74akeKbuv5l; Fri, 19 Aug 2016 14:19:56 +0000 To: ecrit@ietf.org References: From: Paul Kyzivat Message-ID: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> Date: Fri, 19 Aug 2016 10:19:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEe/pFw3FxsKHX71yJ1TPRB0/cjvSV4ITLVJjj3/NVQ1rGUsLMfySEv/gwZq6LYqeKlw+MSkyjAK8SuuL2Y+OolXpAt+UiiA/fY8pwvjpamf7q/NBx8g pkfVLClQkeK6avkwcSJX4I1C+U8Yjy0GKOV5wHpuUX3Sqt/4vSqEEE/Hpyx4WjvJn6d9E5Egi8ny1g== Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 14:19:59 -0000 On 8/19/16 3:46 AM, Christer Holmberg wrote: > (NOTE that this e-mail is not related to the Info Package discussion) > > Hi, > > Assume the PSAP sends a request for MSD to the UA. > > The UA sends the MSD back. > > Why does the UA needs to send ACK? The MSD will acknowledge the request, > won’t it? > > I do understand that the UA needs something if it won’t send the MSD (or > whatever data was requested), e.g. if there was something wrong with the > request). But, if the UA does accept the request, and does send the > data, I don’t see why the explicit ACK is needed. It will only add > message size (and maybe even additional INFO messages). In one of the long ago original proposals, in response to the request, there was either a NAK or the MSD. That would be potentially ambiguous, since MSD can also be sent unsolicited: after sending a request, if you received an MSD you wouldn't know if it was the one you requested, or if it was an unsolicited one and there might yet be a NAK to follow. The ACK resolves the ambiguity. But such issues depend heavily on the details. Minor tweaks might resolve the ambiguity other ways. Since we are discussing various hypotheticals now, there aren't enough details to know whether an ACK is needed. Thanks, Paul From nobody Fri Aug 19 07:28:15 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 B455312DA9C for ; Fri, 19 Aug 2016 07:28:12 -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 TT-3yDY27G3m for ; Fri, 19 Aug 2016 07:28:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DA3D312D1A1 for ; Fri, 19 Aug 2016 07:28:10 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-bd-57b7177827dc Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id FE.3C.06563.87717B75; Fri, 19 Aug 2016 16:28:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 16:28:07 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwA= Date: Fri, 19 Aug 2016 14:28:07 +0000 Message-ID: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> In-Reply-To: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7uG6l+PZwgwWbOSwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx6/YnloJ+noota+exNzAe5exi5OSQEDCR ONm3mKWLkYtDSGA9o8T5I18ZIZwljBKvXi5l7mLk4GATsJDo/qcN0iAi4C3x5/c3NhBbWMBd 4u3mBUwQcQ+JHZtvskPYVhJ31h5gBbFZBFQl7q89wwhi8wLFl77uYgQZKSRQIPHiQTFImFPA QWLNlzdgrYwCYhLfT60BG8ksIC5x68l8Jog7BSSW7DnPDGGLSrx8/A9svKiAnsT3r7PBrpQQ UJKYtjUNolVP4sbUKWwQtrXE67cH2CFsbYllC18zQ1wjKHFy5hOWCYxis5Bsm4WkfRaS9llI 2mchaV/AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCmDm75rbuDcfVrx0OMAhyMSjy8 Cfu3hguxJpYVV+YeYpTgYFYS4VUERqQQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJ JanZqakFqUUwWSYOTqkGRtX0cxLKak+u84d6cGhMs7fOsNttP3f66x0FPfdzZ+1ce17z/0uj Ttvsg/H+m2YkuG618fh+25Hjm/ckpU1srp3PVl+6/FRk0vyP7/iblrR6VDlkRGyVSk0Rmyjh ktVdyZdyuNa2Ik3Z9WcxF+ejq/x7GBQ/a7nsmfZySVeaqIPSfHNmI+0PSizFGYmGWsxFxYkA EmXyoqUCAAA= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 14:28:13 -0000 Hi, >> Assume the PSAP sends a request for MSD to the UA. >> >> The UA sends the MSD back. >> >> Why does the UA needs to send ACK? The MSD will acknowledge the request, >> won=B9t it? >> >> I do understand that the UA needs something if it won=B9t send the MSD (= or >> whatever data was requested), e.g. if there was something wrong with the >> request). But, if the UA does accept the request, and does send the >> data, I don=B9t see why the explicit ACK is needed. It will only add >> message size (and maybe even additional INFO messages). > >In one of the long ago original proposals, in response to the request, >there was either a NAK or the MSD. That would be potentially ambiguous, >since MSD can also be sent unsolicited: after sending a request, if you >received an MSD you wouldn't know if it was the one you requested, or if >it was an unsolicited one and there might yet be a NAK to follow. The >ACK resolves the ambiguity. Not sure I understand. There must be some identifier that matches the MSD with the request - in the same way there must be some identifier that matches the ACK with the request. >But such issues depend heavily on the details. Minor tweaks might >resolve the ambiguity other ways. > >Since we are discussing various hypotheticals now, there aren't enough >details to know whether an ACK is needed. If you refer to the Call-Info discussion, I don=B9t think this has anything to do with that. This is not about how you transport the stuff in SIP. Regards, Christer From nobody Fri Aug 19 07:31:50 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 DBE9112DAFA for ; Fri, 19 Aug 2016 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 VfV_aVGOZntP for ; Fri, 19 Aug 2016 07:31:43 -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 1D48F12DAF6 for ; Fri, 19 Aug 2016 07:31:42 -0700 (PDT) X-AuditID: 1207440d-bf7ff700000008af-ef-57b7184e69ec Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id FE.C7.02223.E4817B75; Fri, 19 Aug 2016 10:31:42 -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 u7JEVfWs011535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 19 Aug 2016 10:31:42 -0400 To: ECRIT From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 10:31:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixO6iqOsnsT3cYP08RYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseblWZaCTSwVe6c2MDcw7mPuYuTkkBAwkXg44RhjFyMXh5DA VkaJY88vMEM4v5gkri74ClYlIiAlcf/ddCYQm01AS2LOof8sILawgIrEhf8n2UFsXgF7ifmz mlm7GDk4WARUJS61aIKERQXSJKYf7meEKBGUODnzCVgrs4CZxLzND5khbHmJ7W/nME9g5JmF pGwWkrJZSMoWMDKvYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI10svNLNFLTSndxAgJGt4djP/X yRxiFOBgVOLhTdi/NVyINbGsuDL3EKMkB5OSKO8v/W3hQnxJ+SmVGYnFGfFFpTmpxYcYJTiY lUR4FcW3hwvxpiRWVqUW5cOkpDlYlMR51Zao+wkJpCeWpGanphakFsFkZTg4lCR4J4gBNQoW paanVqRl5pQgpJk4OEGG8wANnw5Sw1tckJhbnJkOkT/FqMux4MfttUxCLHn5ealS4rw/RIGK BECKMkrz4ObAov0VozjQW8K8tiB38gATBdykV0BLmICW8PJvAVlSkoiQkmpgjHGJOr5qafrV 2duu35/adKck3O3EAYmK+aVvP0aV8d9aFJRtEdhz33Ti9gvbD0nzSsSyKnd49DqxSkXncVhG 3jHUrC932xKQvtt5+/yJqySXPOayFbyVHx64XZSLk31eoKy104PpPer9cnseSO0RF7+wpMT2 YMeL90Enbe5sd3siWvVSr6RXiaU4I9FQi7moOBEAuJ0pIdECAAA= Archived-At: Subject: [Ecrit] Reaching consensus on 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, 19 Aug 2016 14:31:49 -0000 The discussion on ecall has become quite heated, with people dug in on all sides. Can we calm it down a bit? IMO a couple of different approaches have been described that would work and not violate any specs. The differences between these reflect differences of philosophy and taste. Perhaps others don't agree with me on this. But can we separate these concerns? - narrow down the number of alternatives, - reach agreement that each is workable and standards compliant, - *then* debate the philosophical and taste issues. Thanks, Paul From nobody Fri Aug 19 07:43:15 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 1194E12D7BF for ; Fri, 19 Aug 2016 07:43:14 -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 8YELz2ntzL_3 for ; Fri, 19 Aug 2016 07:43:12 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 C64FB12D8B5 for ; Fri, 19 Aug 2016 07:43:11 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-ff-57b71afc3e6e Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 7A.5E.06563.CFA17B75; Fri, 19 Aug 2016 16:43:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 16:43:08 +0200 From: Christer Holmberg To: Paul Kyzivat , ECRIT Thread-Topic: [Ecrit] Reaching consensus on ecall Thread-Index: AQHR+iZuVWjdbhxzhECCd9vn9JDmg6BQbZwA Date: Fri, 19 Aug 2016 14:43:07 +0000 Message-ID: References: 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.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <299383A57D226C49AFAB808290FABDA0@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7t+5fqe3hBr/X21g0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj58pCtoLj7BUTbjxhbWDsZuti5OSQEDCR aDn/nLGLkYtDSGA9o8T7B3vYIJwljBJfe58CZTg42AQsJLr/aYM0iAg4SMxu3sUKEhYWMJDY cj8dImwoMf1gPyOEbSTxa8lOdhCbRUBVYnbrJlYQm1fASmJT11OwGiEBe4l7hzaDTecEGrns bTRImFFATOL7qTVMIDazgLjErSfzmSDOFJBYsuc8M4QtKvHy8T+wkaICehLfv86GiitKtD9t YITo1ZO4MXUKG4RtLdF/7g7UTG2JZQtfM0OcIyhxcuYTlgmMYrOQrJuFpH0WkvZZSNpnIWlf wMi6ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwpg5u+a27g3H1a8dDjAIcjEo8vAn7t4YL sSaWFVfmHmKU4GBWEuH1FN8eLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZq akFqEUyWiYNTqoHRd9O8RZkXTtk+XPelcYv2l66LqUum6XXe0y98EW8odyYve564uF0iS33o ol0rHnJ/sZOVEzltzcoydUOHf6Sv63uDXO5e5wdaEqznD9u9rMrOV1RsCfORnsr54LibKtPl r1L2vbpePIckAvyWvZq5bWewwYycVXMPN8qbuZoszpTJnuDMqaDEUpyRaKjFXFScCABfloHd pQIAAA== Archived-At: Subject: Re: [Ecrit] Reaching consensus on 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, 19 Aug 2016 14:43:14 -0000 Hi Paul, >The discussion on ecall has become quite heated, with people dug in on >all sides. Can we calm it down a bit? > >IMO a couple of different approaches have been described that would work >and not violate any specs. The differences between these reflect >differences of philosophy and taste. I don=B9t think we have an agreement on the would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086. But, I do agree we need to try to figure out how to move forward. Regards, Christer >Perhaps others don't agree with me on this. But can we separate these >concerns? > >- narrow down the number of alternatives, >- reach agreement that each is workable and standards compliant, >- *then* debate the philosophical and taste issues. > > Thanks, > Paul > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 19 07:48: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 4CEF812D7A6 for ; Fri, 19 Aug 2016 07:48:48 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 j-rXWpxtGbqt for ; Fri, 19 Aug 2016 07:48:47 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 1D1AF12D14B for ; Fri, 19 Aug 2016 07:48:47 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with SMTP id al5kbwRXJ2dNjal6EbN52l; Fri, 19 Aug 2016 14:48:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-06v.sys.comcast.net with SMTP id al6DbMtxcfh8gal6EbiT2V; Fri, 19 Aug 2016 14:48:46 +0000 To: Christer Holmberg , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> From: Paul Kyzivat Message-ID: <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> Date: Fri, 19 Aug 2016 10:48:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIVUVECueKr47sws8BKUFx00fs8Rtp4wLqQotGXYbUXinutShfza0mvwe+pPSpx3cjQwVjEK7lF0FhDDidpqosNYXtPjXhBrEYy/xvKSe/X974q1Qzho 5RUPjm2z3dIFgI7e+K1FOvZQ221eU6lUcnAaTkxRVODWx6IVGeZyhPv2Vp790or8AnT6Kge/5GHvpVobBoHNZrQOQFW/PNOs12GBJnWVLSm6b6ST1ZRs6nbA Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 14:48:48 -0000 On 8/19/16 10:28 AM, Christer Holmberg wrote: > Hi, > >>> Assume the PSAP sends a request for MSD to the UA. >>> >>> The UA sends the MSD back. >>> >>> Why does the UA needs to send ACK? The MSD will acknowledge the request, >>> wonąt it? >>> >>> I do understand that the UA needs something if it wonąt send the MSD (or >>> whatever data was requested), e.g. if there was something wrong with the >>> request). But, if the UA does accept the request, and does send the >>> data, I donąt see why the explicit ACK is needed. It will only add >>> message size (and maybe even additional INFO messages). >> >> In one of the long ago original proposals, in response to the request, >> there was either a NAK or the MSD. That would be potentially ambiguous, >> since MSD can also be sent unsolicited: after sending a request, if you >> received an MSD you wouldn't know if it was the one you requested, or if >> it was an unsolicited one and there might yet be a NAK to follow. The >> ACK resolves the ambiguity. > > Not sure I understand. There must be some identifier that matches the MSD > with the request - in the same way there must be some identifier that > matches the ACK with the request. Yes. AFAIK there is nothing in the MSD itself that links it to the request, so if the MSD is intended to implicitly acknowledge the request then there needs to be *something* with it that links it to the request. >> But such issues depend heavily on the details. Minor tweaks might >> resolve the ambiguity other ways. >> >> Since we are discussing various hypotheticals now, there aren't enough >> details to know whether an ACK is needed. > > If you refer to the Call-Info discussion, I donąt think this has anything > to do with that. This is not about how you transport the stuff in SIP. You could go with a philosophy where successful requests are never acknowledged - only failed ones. I find such protocols to be fragile. Thanks, Paul From nobody Fri Aug 19 08:00:14 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 B2DDA12DB41 for ; Fri, 19 Aug 2016 08:00:12 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 lN95ks6Abok5 for ; Fri, 19 Aug 2016 08:00:11 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 9A32A12DB26 for ; Fri, 19 Aug 2016 08:00:09 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-04v.sys.comcast.net with SMTP id alGcb51688PeaalHEb14Qp; Fri, 19 Aug 2016 15:00:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with SMTP id alHDb2gmfeKs6alHEbAhpc; Fri, 19 Aug 2016 15:00:08 +0000 To: Christer Holmberg , ECRIT References: From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 11:00:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfA9G/joV5Gb+EtSMJlDBK6zevEsz+wv0OphSbRqYlSVWbUHa4RMGEbzWk6dPaVSTjY6nipZL5FZf/HAGmfGJlWYjKhZmEptFFGeeChqWaAKseqXTpvT3 97L1gxZlfaWupFjaAJgDspX4jmXIdtkypMt+iJMUNDwg9+k9RkqFYWfn0zQRizvmgT7tJ25y2zP56nZHc9JS4dftomrKd68sWXREAhJGjl+K2iqg6grmtE4A Archived-At: Subject: [Ecrit] Multipart with INFO 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, 19 Aug 2016 15:00:13 -0000 On 8/19/16 10:43 AM, Christer Holmberg wrote: > Hi Paul, > >> The discussion on ecall has become quite heated, with people dug in on >> all sides. Can we calm it down a bit? >> >> IMO a couple of different approaches have been described that would work >> and not violate any specs. The differences between these reflect >> differences of philosophy and taste. > > I donąt think we have an agreement on the would-not-violate-any-specs > part. We clearly have different views on what is allowed by RFC 6086. > > But, I do agree we need to try to figure out how to move forward. OK. Maybe we should start there. I guess there is some dispute on whether it is valid for an INFO message to contain a multipart body, where one part contains the info package (C-D: info-package) and another part (C-D: by-reference) is referenced by a cid: uri in some sip header field. In my mind there is no question that this is valid. Do you disagree, and if so, on what basis? Thanks, Paul > Regards, > > Christer > > > >> Perhaps others don't agree with me on this. But can we separate these >> concerns? >> >> - narrow down the number of alternatives, >> - reach agreement that each is workable and standards compliant, >> - *then* debate the philosophical and taste issues. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From nobody Fri Aug 19 08:03: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 4069612DB32 for ; Fri, 19 Aug 2016 08:02:59 -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 QNbsZjpSdd0X for ; Fri, 19 Aug 2016 08:02:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7A03412DB38 for ; Fri, 19 Aug 2016 08:02:31 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-79-57b71f84f0a6 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id FB.E0.06563.48F17B75; Fri, 19 Aug 2016 17:02:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 17:02:28 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAN0aA Date: Fri, 19 Aug 2016 15:02:28 +0000 Message-ID: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> In-Reply-To: <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: <34B374C77B951F4AB89A49BC03F33759@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7vW6r/PZwg4XNGhaNi56yWqzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY/Mq24IN0xat3z1gbGKdIdzFyckgImEjs 2/iesYuRi0NIYD2jxKUtV1kgnCWMEpsvrwJyODjYBCwkuv9pgzSICHhL/Pn9jQ3EFhZwl3i7 eQETRNxDYsfmm+wQtpvEy/0zmUFsFgFViX+n+sHqeQWsJPYcmwY1/zqjxJ2GV4wgCU4BB4mX B7+CNTAKiEl8P7UGbCizgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WEFtUQE/i+9fZUHFFiZ1n 25kherUkvvzYxwZhW0s82NvPDmErSkzpfsgOcZCgxMmZT1gmMIrNQrJuFpL2WUjaZyFpn4Wk fQEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwLg6uOW37g7G1a8dDzEKcDAq8fAm7N8a LsSaWFZcmXuIUYKDWUmEN0Rue7gQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZ qakFqUUwWSYOTqkGxtZ333yPCsbcXtn44dSivxdXshXPSN8R+WbJn93M2kle2+YzVM9MUmuP 3vGbKXbq9NZXM7SWuwScuqyz4X/13YwY1eCNh8r/xz77u/WUxdmS5owzFfMPPdWW35t4mjFh 3ktGzit3l3YJ63za8OTOXqPc/YITM9OPTbQ0y9LYkyRx+lJx+O4b03WVWIozEg21mIuKEwHN ZTjhpwIAAA== Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 15:02:59 -0000 SGksDQoNCj4+Pj5Bc3N1bWUgdGhlIFBTQVAgc2VuZHMgYSByZXF1ZXN0IGZvciBNU0QgdG8gdGhl IFVBLg0KPj4+Pg0KPj4+PiBUaGUgVUEgc2VuZHMgdGhlIE1TRCBiYWNrLg0KPj4+Pg0KPj4+PiBX aHkgZG9lcyB0aGUgVUEgbmVlZHMgdG8gc2VuZCBBQ0s/IFRoZSBNU0Qgd2lsbCBhY2tub3dsZWRn ZSB0aGUNCj4+Pj5yZXF1ZXN0LA0KPj4+PiB3b26p9nQgaXQ/DQo+Pj4+DQo+Pj4+IEkgZG8gdW5k ZXJzdGFuZCB0aGF0IHRoZSBVQSBuZWVkcyBzb21ldGhpbmcgaWYgaXQgd29uqfZ0IHNlbmQgdGhl IE1TRA0KPj4+Pihvcg0KPj4+PiB3aGF0ZXZlciBkYXRhIHdhcyByZXF1ZXN0ZWQpLCBlLmcuIGlm IHRoZXJlIHdhcyBzb21ldGhpbmcgd3Jvbmcgd2l0aA0KPj4+PnRoZQ0KPj4+PiByZXF1ZXN0KS4g QnV0LCBpZiB0aGUgVUEgZG9lcyBhY2NlcHQgdGhlIHJlcXVlc3QsIGFuZCBkb2VzIHNlbmQgdGhl DQo+Pj4+IGRhdGEsIEkgZG9uqfZ0IHNlZSB3aHkgdGhlIGV4cGxpY2l0IEFDSyBpcyBuZWVkZWQu IEl0IHdpbGwgb25seSBhZGQNCj4+Pj4gbWVzc2FnZSBzaXplIChhbmQgbWF5YmUgZXZlbiBhZGRp dGlvbmFsIElORk8gbWVzc2FnZXMpLg0KPj4+DQo+Pj4gSW4gb25lIG9mIHRoZSBsb25nIGFnbyBv cmlnaW5hbCBwcm9wb3NhbHMsIGluIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0LA0KPj4+IHRoZXJl IHdhcyBlaXRoZXIgYSBOQUsgb3IgdGhlIE1TRC4gVGhhdCB3b3VsZCBiZSBwb3RlbnRpYWxseSBh bWJpZ3VvdXMsDQo+Pj4gc2luY2UgTVNEIGNhbiBhbHNvIGJlIHNlbnQgdW5zb2xpY2l0ZWQ6IGFm dGVyIHNlbmRpbmcgYSByZXF1ZXN0LCBpZiB5b3UNCj4+PiByZWNlaXZlZCBhbiBNU0QgeW91IHdv dWxkbid0IGtub3cgaWYgaXQgd2FzIHRoZSBvbmUgeW91IHJlcXVlc3RlZCwgb3INCj4+PmlmDQo+ Pj4gaXQgd2FzIGFuIHVuc29saWNpdGVkIG9uZSBhbmQgdGhlcmUgbWlnaHQgeWV0IGJlIGEgTkFL IHRvIGZvbGxvdy4gVGhlDQo+Pj4gQUNLIHJlc29sdmVzIHRoZSBhbWJpZ3VpdHkuDQo+Pg0KPj4g Tm90IHN1cmUgSSB1bmRlcnN0YW5kLiBUaGVyZSBtdXN0IGJlIHNvbWUgaWRlbnRpZmllciB0aGF0 IG1hdGNoZXMgdGhlDQo+Pk1TRA0KPj4gd2l0aCB0aGUgcmVxdWVzdCAtIGluIHRoZSBzYW1lIHdh eSB0aGVyZSBtdXN0IGJlIHNvbWUgaWRlbnRpZmllciB0aGF0DQo+PiBtYXRjaGVzIHRoZSBBQ0sg d2l0aCB0aGUgcmVxdWVzdC4NCj4NCj5ZZXMuIEFGQUlLIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhl IE1TRCBpdHNlbGYgdGhhdCBsaW5rcyBpdCB0byB0aGUNCj5yZXF1ZXN0LCBzbyBpZiB0aGUgTVNE IGlzIGludGVuZGVkIHRvIGltcGxpY2l0bHkgYWNrbm93bGVkZ2UgdGhlIHJlcXVlc3QNCj50aGVu IHRoZXJlIG5lZWRzIHRvIGJlICpzb21ldGhpbmcqIHdpdGggaXQgdGhhdCBsaW5rcyBpdCB0byB0 aGUgcmVxdWVzdC4NCg0KQ2FuIHdlIHVzZSB0aGUgQ29udGVudC1JRCBoZWFkZXIgZmllbGQgdmFs dWU/IFdvdWxkIGl0IGJlIGFsbG93ZWQgdG8gdXNlDQp0aGUgc2FtZSBoZWFkZXIgZmllbGQgdmFs dWUgaW4gdGhlIHJlcXVlc3QgYW5kIHRoZSBhc3NvY2lhdGVkIE1TRD8gVGhlbg0KeW91IGRvbqGv dCBuZWVkIHRvIGRlZmluZSBhIHNlcGFyYXRlIGluZGljYXRvciBmb3IgZWFjaCB0eXBlIG9mIGRh dGEsIGFzDQppdKGvcyBhIE1JTUUgaGVhZGVyIGZpZWxkLg0KDQo+Pj4gQnV0IHN1Y2ggaXNzdWVz IGRlcGVuZCBoZWF2aWx5IG9uIHRoZSBkZXRhaWxzLiBNaW5vciB0d2Vha3MgbWlnaHQNCj4+PiBy ZXNvbHZlIHRoZSBhbWJpZ3VpdHkgb3RoZXIgd2F5cy4NCj4+Pg0KPj4+IFNpbmNlIHdlIGFyZSBk aXNjdXNzaW5nIHZhcmlvdXMgaHlwb3RoZXRpY2FscyBub3csIHRoZXJlIGFyZW4ndCBlbm91Z2gN Cj4+PiBkZXRhaWxzIHRvIGtub3cgd2hldGhlciBhbiBBQ0sgaXMgbmVlZGVkLg0KPj4NCj4+IElm IHlvdSByZWZlciB0byB0aGUgQ2FsbC1JbmZvIGRpc2N1c3Npb24sIEkgZG9uqfZ0IHRoaW5rIHRo aXMgaGFzDQo+PmFueXRoaW5nDQo+PiB0byBkbyB3aXRoIHRoYXQuIFRoaXMgaXMgbm90IGFib3V0 IGhvdyB5b3UgdHJhbnNwb3J0IHRoZSBzdHVmZiBpbiBTSVAuDQo+DQo+WW91IGNvdWxkIGdvIHdp dGggYSBwaGlsb3NvcGh5IHdoZXJlIHN1Y2Nlc3NmdWwgcmVxdWVzdHMgYXJlIG5ldmVyDQo+YWNr bm93bGVkZ2VkIC0gb25seSBmYWlsZWQgb25lcy4gSSBmaW5kIHN1Y2ggcHJvdG9jb2xzIHRvIGJl IGZyYWdpbGUuDQoNCkJ1dCB0aGUgd2hvbGUgaWRlYSB3YXMgdGhhdCB0aGUgTVNEL2RhdGEgYWNr bm93bGVkZ2VzIHRoZSByZXF1ZXN0Lg0KDQpCdXQsIElGIHdlIHdhbnQgc29tZXRoaW5nIG1vcmUg ZXhwbGljaXQsIHdoeSBub3QgZS5nLiBhIEluZm8tUGFja2FnZQ0KaGVhZGVyIGZpZWxkIHBhcmFt ZXRlcj8gQW5kLCByZWdhcmRpbmcgobBuZXZlciBhY2tub3dsZWRnZWShsSwgd2UgYW55d2F5DQpu ZWVkIHNvbWUgZ3VpZGFuY2Ugb24gZm9yIGhvdyBsb25nIHRoZSByZXF1ZXN0ZXIgc2hvdWxkIHdh aXQgZm9yIHRoZQ0KYWNrbm93bGVkZ21lbnQgKG5vIG1hdHRlciBpZiBpdKGvcyBpbXBsaWNpdCBv ciBleHBsaWNpdCkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Fri Aug 19 08:22: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 862B412D8D3 for ; Fri, 19 Aug 2016 08:22:21 -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 VnG3Vd0eaY4z for ; Fri, 19 Aug 2016 08:22:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F2C6E12D79C for ; Fri, 19 Aug 2016 08:22:18 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-63-57b724292085 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 8A.C8.02553.92427B75; Fri, 19 Aug 2016 17:22:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 17:22:16 +0200 From: Christer Holmberg To: Paul Kyzivat , ECRIT Thread-Topic: Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA Date: Fri, 19 Aug 2016 15:22:16 +0000 Message-ID: References: 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.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <38294326CA2A484BB57E4CA15DEA3A97@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7sa6myvZwg53rhC0aFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx7uND5oIFshXrmwMaGA/IdDFyckgImEgs ffaQvYuRi0NIYD2jxOm5nawQzhJGiaMnn7N1MXJwsAlYSHT/0wZpEBFwkJjdvIsVxBYWUJDY u2ouE0RcUWLahPlg5SICRhKnVuWDhFkEVCWOfpvPCGLzClhJXHn8jA1i/DJGiSfLG9lBEpxA MxdP/gg2h1FATOL7qTVgNrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP7AbRAX0JL5/nc0MsldC QEli2tY0iFYtiS8/9rFB2NYSTRu+s0PYihJTuh+yQ9wjKHFy5hOWCYxis5Bsm4WkfRaS9llI 2mchaV/AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCmDm75bbCD8eVzx0OMAhyMSjy8 Cfu3hguxJpYVV+YeYpTgYFYS4V2rsD1ciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0 xJLU7NTUgtQimCwTB6dUA+OGPtO1+ssVnSt5T1tGW5+euPz//lmnvlSkN92NfCdjcHWXh7mn 5pzcL2/1T/DvnZ60g52tP/d7uGPoOlMbaQX9961vljHaTb86qfLSu7L5O2/Nvd7zOcslImRD /5+WeNbJ7JNKH1699twnvTmxfcuEv2ahH2fwiinFbdG60xZ9tf7F7Sa31AlKLMUZiYZazEXF iQAt6Q4FpQIAAA== Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 15:22:21 -0000 SGksDQoNCj4+PlRoZSBkaXNjdXNzaW9uIG9uIGVjYWxsIGhhcyBiZWNvbWUgcXVpdGUgaGVhdGVk LCB3aXRoIHBlb3BsZSBkdWcgaW4gb24NCj4+PiBhbGwgc2lkZXMuIENhbiB3ZSBjYWxtIGl0IGRv d24gYSBiaXQ/DQo+Pj4NCj4+PiBJTU8gYSBjb3VwbGUgb2YgZGlmZmVyZW50IGFwcHJvYWNoZXMg aGF2ZSBiZWVuIGRlc2NyaWJlZCB0aGF0IHdvdWxkDQo+Pj53b3JrDQo+Pj4gYW5kIG5vdCB2aW9s YXRlIGFueSBzcGVjcy4gVGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlc2UgcmVmbGVjdA0KPj4+ IGRpZmZlcmVuY2VzIG9mIHBoaWxvc29waHkgYW5kIHRhc3RlLg0KPj4NCj4+IEkgZG9uqfZ0IHRo aW5rIHdlIGhhdmUgYW4gYWdyZWVtZW50IG9uIHRoZSB3b3VsZC1ub3QtdmlvbGF0ZS1hbnktc3Bl Y3MNCj4+IHBhcnQuIFdlIGNsZWFybHkgaGF2ZSBkaWZmZXJlbnQgdmlld3Mgb24gd2hhdCBpcyBh bGxvd2VkIGJ5IFJGQyA2MDg2Lg0KPj4NCj4+IEJ1dCwgSSBkbyBhZ3JlZSB3ZSBuZWVkIHRvIHRy eSB0byBmaWd1cmUgb3V0IGhvdyB0byBtb3ZlIGZvcndhcmQuDQo+DQo+T0suIE1heWJlIHdlIHNo b3VsZCBzdGFydCB0aGVyZS4NCj4NCj5JIGd1ZXNzIHRoZXJlIGlzIHNvbWUgZGlzcHV0ZSBvbiB3 aGV0aGVyIGl0IGlzIHZhbGlkIGZvciBhbiBJTkZPIG1lc3NhZ2UNCj50byBjb250YWluIGEgbXVs dGlwYXJ0IGJvZHksIHdoZXJlIG9uZSBwYXJ0IGNvbnRhaW5zIHRoZSBpbmZvIHBhY2thZ2UNCj4o Qy1EOiBpbmZvLXBhY2thZ2UpIGFuZCBhbm90aGVyIHBhcnQgKEMtRDogYnktcmVmZXJlbmNlKSBp cyByZWZlcmVuY2VkDQo+YnkgYSBjaWQ6IHVyaSBpbiBzb21lIHNpcCBoZWFkZXIgZmllbGQuDQo+ DQo+SW4gbXkgbWluZCB0aGVyZSBpcyBubyBxdWVzdGlvbiB0aGF0IHRoaXMgaXMgdmFsaWQuIERv IHlvdSBkaXNhZ3JlZSwgYW5kDQo+aWYgc28sIG9uIHdoYXQgYmFzaXM/DQoNClRoZSBkaXNwdXRl IGlzIHdoZXRoZXIgYSBtZXNzYWdlIGJvZHkgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggYW4gSW5m bw0KUGFja2FnZS4NCg0KSW4gbXkgdmlldzogDQoNCi0gUkZDIDYwODYgYWxsb3dzIGJvZGllcyBu b3QgYXNzb2NpYXRlZCB3aXRoIGFuIEluZm8gUGFja2FnZSBpbiBJTkZPcyBpbg0Kb3JkZXIgdG8g YmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHByZS02MDg2IElORk8gdXNhZ2Vz Lg0KLSBBbnkgTkVXIHVzYWdlIE1VU1QgYmUgYXNzb2NpYXRlZCB3aXRoIGFuIEluZm8gUGFja2Fn ZS4gU2VuZGluZyBvZiBNU0QgaXMNCmEgbmV3IElORk8gdXNhZ2UuDQoNClNvbWUgaGF2ZSBzYWlk IHRoYXQgdGhlcmUgbWlnaHQgZXZlbiBiZSBuZXcgdXNhZ2VzIHdoZXJlIGluZm9ybWF0aW9uLA0K d2l0aG91dCBiZWluZyBhc3NvY2lhdGVkIHdpdGggYW4gSW5mbyBQYWNrYWdlLCBpcyBwaWdneWJh Y2tlZCBpbiBJTkZPcw0Kc2VudCBmb3Igc29tZSBvdGhlciBwdXJwb3NlLiBJdCBjYW4gYmUgZGlz Y3Vzc2VkIHdoZXRoZXIgc3VjaCB1c2FnZSBpcw0KNjA2OCBjb21wbGlhbnQsIGJ1dCBuZXZlciB0 aGUgbGVzczogaW4gbXkgb3BpbmlvbiBNU0QgaXMgbm90IKGwcGlnZ3liYWNrZWQNCmluZm9ybWF0 aW9uIi4gVGhlIHJlYXNvbiB0aGUgSU5GTyBpcyBzZW50IHRvIGJlZ2luIHdpdGggaXMgdG8gdHJh bnNwb3J0DQp0aGUgcmVxdWVzdGVkIE1TRCAoYW5kIHRoZSBhY2sgdG8gdGhlIHJlcXVlc3QpIC0g dGhhdCBpcyBub3QgcGlnZ3liYWNraW5nDQppbiBteSBvcGluaW9uLg0KDQpOb3csIGluIHRoZSBj dXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0LCB0aGUgTVNEIHdhcyBzdGlsbCBhc3NvY2lhdGVk DQp3aXRoIGFuIEluZm8gUGFja2FnZSwgYW5kIHRoZSBkaXNwdXRlIHdhcyBtb3N0bHkgcmVnYXJk aW5nIHVzYWdlIG9mDQpDYWxsLUluZm8uIEJ1dCwgYmFzZWQgb24gdGhlIHN1Z2dlc3Rpb24gcHJl c2VudGVkIGEgZmV3IGRheXMgYWdvLCB0aGUgTVNEDQppcyBubyBsb25nZXIgZXZlbiBhc3NvY2lh dGVkIHdpdGggYW4gSW5mbyBQYWNrYWdlLCBzbyB1bmZvcnR1YW50ZWx5IEkNCnRoaW5rIG91dCB2 aWV3cyBhcmUgZXZlbiBtb3JlIGRpZmZlcmVudCBub3cgdGhhbiBiZWZvcmUuDQoNCk15IGFwb2xv Z2llcyBpZiB0aGF0IHdhcyBtb3JlIHRleHQgdGhhbiB5b3UgaG9wZWQgZm9yLCBidXQgSSBqdXN0 IHdhbnQgdG8NCnRyeSB0byBtYWtlIG15IHZpZXcgb2YgdGhlIHNpdHVhdGlvbiBhcyBjbGVhciBh cyBwb3NzaWJsZSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KIA0KDQoNCg0KPj4+IFBlcmhh cHMgb3RoZXJzIGRvbid0IGFncmVlIHdpdGggbWUgb24gdGhpcy4gQnV0IGNhbiB3ZSBzZXBhcmF0 ZSB0aGVzZQ0KPj4+IGNvbmNlcm5zPw0KPj4+DQo+Pj4gLSBuYXJyb3cgZG93biB0aGUgbnVtYmVy IG9mIGFsdGVybmF0aXZlcywNCj4+PiAtIHJlYWNoIGFncmVlbWVudCB0aGF0IGVhY2ggaXMgd29y a2FibGUgYW5kIHN0YW5kYXJkcyBjb21wbGlhbnQsDQo+Pj4gLSAqdGhlbiogZGViYXRlIHRoZSBw aGlsb3NvcGhpY2FsIGFuZCB0YXN0ZSBpc3N1ZXMuDQo+Pj4NCj4+PiAJVGhhbmtzLA0KPj4+IAlQ YXVsDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+IEVjcml0QGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4NCj4+DQo+DQoNCg== From nobody Fri Aug 19 08:31:04 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 2289F12D51F for ; Fri, 19 Aug 2016 08:31:01 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 xMbtBRW_M05J for ; Fri, 19 Aug 2016 08:30:59 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 CC87412DB59 for ; Fri, 19 Aug 2016 08:30:48 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-01v.sys.comcast.net with SMTP id alj0bJeEqTaLwalkubmWIz; Fri, 19 Aug 2016 15:30:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with SMTP id alktbuTUSm7dBalktbTaQM; Fri, 19 Aug 2016 15:30:48 +0000 To: Christer Holmberg , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> From: Paul Kyzivat Message-ID: <6d5223f3-b0bb-452f-1c8f-33307d3f0baf@alum.mit.edu> Date: Fri, 19 Aug 2016 11:30:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfA9BqRGfu0ddj+vrilzXPTi0yUb9kiTnpEilQtUoR2e5TFlYRKwZIuPlRoOOkW7fRbMF4XnVc121f+Jw66jorevGcETvhu4urdH2Ua7eV6Ar/CyUJtgc zMVUcpEaGoMebBf3Rpblz5kvoQfMd6qlv1lcY8g9CP2S7spytv+LBKHhvr8/tgwxP/o1TE1mWw0FiFEwP7pWmJzcMuoWDSpJW5WF63ngSpd/MrRyKlBpyyo0 Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 15:31:02 -0000 Christer, On 8/19/16 11:02 AM, Christer Holmberg wrote: > Hi, > >>>>> Assume the PSAP sends a request for MSD to the UA. >>>>> >>>>> The UA sends the MSD back. >>>>> >>>>> Why does the UA needs to send ACK? The MSD will acknowledge the >>>>> request, >>>>> won©öt it? >>>>> >>>>> I do understand that the UA needs something if it won©öt send the MSD >>>>> (or >>>>> whatever data was requested), e.g. if there was something wrong with >>>>> the >>>>> request). But, if the UA does accept the request, and does send the >>>>> data, I don©öt see why the explicit ACK is needed. It will only add >>>>> message size (and maybe even additional INFO messages). >>>> >>>> In one of the long ago original proposals, in response to the request, >>>> there was either a NAK or the MSD. That would be potentially ambiguous, >>>> since MSD can also be sent unsolicited: after sending a request, if you >>>> received an MSD you wouldn't know if it was the one you requested, or >>>> if >>>> it was an unsolicited one and there might yet be a NAK to follow. The >>>> ACK resolves the ambiguity. >>> >>> Not sure I understand. There must be some identifier that matches the >>> MSD >>> with the request - in the same way there must be some identifier that >>> matches the ACK with the request. >> >> Yes. AFAIK there is nothing in the MSD itself that links it to the >> request, so if the MSD is intended to implicitly acknowledge the request >> then there needs to be *something* with it that links it to the request. > > Can we use the Content-ID header field value? Would it be allowed to use > the same header field value in the request and the associated MSD? Then > you donˇŻt need to define a separate indicator for each type of data, as > itˇŻs a MIME header field. Use it *how*? I have generally assumed that the scope/lifetime of a Content-ID is limited to a single message. (I don't think there is any expectation the the Content-ID values are unique beyond the message they are contained in.) But I don't know if that is well defined. In any case, if you wanted to reference it from another message containing the MSD you would need some place to put it. *In* the MSD would be an obvious place, but is there any way to do that? If not, then *with* the MSD. Alternatively, you can define that the request for a new MSD is just a hint to send one "unsolicited". (E.g., something like the CANCEL message. It gets a response that indicates it was received and understood, but that response doesn't indicate it was acted upon. It is just a hint that you would be happy to have the recipient do something. And it may lead to some other subsequent actions, like a 487 indicating that another request was terminated. But you never know, or expect to know, for certain whether that action was the result of your CANCEL, or happened for some other reason.) >>>> But such issues depend heavily on the details. Minor tweaks might >>>> resolve the ambiguity other ways. >>>> >>>> Since we are discussing various hypotheticals now, there aren't enough >>>> details to know whether an ACK is needed. >>> >>> If you refer to the Call-Info discussion, I don©öt think this has >>> anything >>> to do with that. This is not about how you transport the stuff in SIP. >> >> You could go with a philosophy where successful requests are never >> acknowledged - only failed ones. I find such protocols to be fragile. > > But the whole idea was that the MSD/data acknowledges the request. > > But, IF we want something more explicit, why not e.g. a Info-Package > header field parameter? And, regarding ˇ°never acknowledgedˇ±, we anyway > need some guidance on for how long the requester should wait for the > acknowledgment (no matter if itˇŻs implicit or explicit). It is really hard to discuss this stuff piecemeal. All the moving parts need to fit together into a coherent and unambiguous whole. Thanks, Paul From nobody Fri Aug 19 08:42: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 D796912DB39 for ; Fri, 19 Aug 2016 08:42:16 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 do8OBDH4y-Z3 for ; Fri, 19 Aug 2016 08:42:15 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 A7CE612DB20 for ; Fri, 19 Aug 2016 08:42:14 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with SMTP id alvQbUdKdff8qalvxbe3Mn; Fri, 19 Aug 2016 15:42:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id alvxbgMw46coJalvxbGdL6; Fri, 19 Aug 2016 15:42:13 +0000 To: Christer Holmberg , ECRIT References: From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 11:42:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEsCuIcjWTKDiG/rmYsb07cKBYtlYb9abMX9e4lLnaD/e611Dh4EqzkPRt2NhcEW8qoHTQ3eKKQZYUhYzF8OUhhhUelMScUqMNv1LxaZ7BzAucOtsTd9 YJQTK4fJHnQDV7K0oy9OFWOAfQP8p2TX1QHDUY8GID03Ho127Wl5ihxvxeJbQmM+jGY9mhXeefZk9unhf9wjkVPX+YB9TRE7W/bGYMwEbsk15AwKcubQoxb1 Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 15:42:17 -0000 Christer, On 8/19/16 11:22 AM, Christer Holmberg wrote: > Hi, > >>>> The discussion on ecall has become quite heated, with people dug in on >>>> all sides. Can we calm it down a bit? >>>> >>>> IMO a couple of different approaches have been described that would >>>> work >>>> and not violate any specs. The differences between these reflect >>>> differences of philosophy and taste. >>> >>> I don©öt think we have an agreement on the would-not-violate-any-specs >>> part. We clearly have different views on what is allowed by RFC 6086. >>> >>> But, I do agree we need to try to figure out how to move forward. >> >> OK. Maybe we should start there. >> >> I guess there is some dispute on whether it is valid for an INFO message >> to contain a multipart body, where one part contains the info package >> (C-D: info-package) and another part (C-D: by-reference) is referenced >> by a cid: uri in some sip header field. >> >> In my mind there is no question that this is valid. Do you disagree, and >> if so, on what basis? > > The dispute is whether a message body must be associated with an Info > Package. > > In my view: > > - RFC 6086 allows bodies not associated with an Info Package in INFOs in > order to be backward compatible with existing pre-6086 INFO usages. > - Any NEW usage MUST be associated with an Info Package. Sending of MSD is > a new INFO usage. I disagree. I find the following in 6086: NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned. A body part referenced by call-info falls into that category. > Some have said that there might even be new usages where information, > without being associated with an Info Package, is piggybacked in INFOs > sent for some other purpose. It can be discussed whether such usage is > 6068 compliant, but never the less: in my opinion MSD is not ˇ°piggybacked > information". The reason the INFO is sent to begin with is to transport > the requested MSD (and the ack to the request) - that is not piggybacking > in my opinion. That may be your concept of how the particular info package is defined. I think the people who disagree have a different concept. For purposes of evaluation these should be considered alternative proposals. > Now, in the current version of the draft, the MSD was still associated > with an Info Package, and the dispute was mostly regarding usage of > Call-Info. But, based on the suggestion presented a few days ago, the MSD > is no longer even associated with an Info Package, so unfortuantely I > think out views are even more different now than before. Exactly. > My apologies if that was more text than you hoped for, but I just want to > try to make my view of the situation as clear as possible :) As long as we are making progress towards understanding each other. Thanks, Paul From nobody Fri Aug 19 08:47: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 2292112DB20 for ; Fri, 19 Aug 2016 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 2o4jM7bpnrWN for ; Fri, 19 Aug 2016 08:47:25 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 80C0712D8D3 for ; Fri, 19 Aug 2016 08:47:25 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id v123so46667701qkh.2 for ; Fri, 19 Aug 2016 08:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Olna7Rxsh9Lt4+RAvcdzEkjhd0mKa0hRxi6cxgNGb8g=; b=CPbaMhXWis5YA3tY5JY6wnMV9MAoE38QbtEwAskmCkjiLcc2e8x004hNUgG2Netiv1 annsUe0XWF6HSRg/msyvF2tvzz40rWcHK/Pfw+cve/jj4s5H0WhUrfS1mh4vETLIAgoS 8aq4xVszFazANDzQMIIGNtLhosegtNIn7NTTj1LgzQ+msJaFzKLgytwQdLPyLvfzIzHV +xJ+5X5UpqQ5cblmogt7fcKYsq6C64el81ldPYkSGlUQdkmM8FVpjxqkNh5/77jQoeuU +jcPhilIrCKNJvmdKYkWEyb/ii+PduUIBS7wfxs0gv5Mbzcg2uy/HDhYK5e15Wub8TaG QlCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Olna7Rxsh9Lt4+RAvcdzEkjhd0mKa0hRxi6cxgNGb8g=; b=OmBDDN7AKQdZdERzfS2Hat8Sn9KKvrmH5URC5ki+g6ybXOJIlnBTKobGXCDkPpiyvM PwpO44lTxFtEuqkb7FHcJV68nC7ON99+FFwoi6/x5mJoWDQoHXepjHSUJYxSNRu0H7zD 165kEnmvDfyFhv2DYrafB2unMln0ghKaZ+cTiq6C2SjuWmfH574Y/Eyf10OBdMXYu3ML 7vqujZIDNYBBwoyK/lEHQxBof4ddrO4uU9aG5jk3nE461XUV8Ev9HWSdWppejXDTWmKv 76VjbS26nd/7LvoF7FPPwnxnVYwaJ05wmi6Wp2Pp9taUtiSeHhAbzRS1SwRgASFb4ihG QnAw== X-Gm-Message-State: AEkoouvgnTS5q+lCp+ReBBs0x1Cz7zCq8f9NLBK5h6fWVXrxMfwLQ3vVt5U6taQRLxUeUg== X-Received: by 10.55.156.135 with SMTP id f129mr9551885qke.160.1471621644636; Fri, 19 Aug 2016 08:47:24 -0700 (PDT) Received: from [10.33.192.45] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id a63sm4104934qkb.26.2016.08.19.08.47.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 08:47:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4FDF074-EF0C-4000-9062-DB68AFBEEED2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 19 Aug 2016 11:47:22 -0400 Message-Id: <82B78D41-B890-4918-A0F1-2DF713FCB445@brianrosen.net> References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 15:47:28 -0000 --Apple-Mail=_C4FDF074-EF0C-4000-9062-DB68AFBEEED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Suppose we wanted to create an INFO package that would trigger an update = of the caller=E2=80=99s location mid call. Caller Location is carried in the Geolocation header, and can either be = a URI to a location dereferenced using HELD or SIP Presence, or it can = be a content indirect with a body. Would you say we would have to send the location, if sent by reference, = in an INFO block? What if it was sent by value? Brian > On Aug 19, 2016, at 11:42 AM, Paul Kyzivat = wrote: >=20 > Christer, >=20 > On 8/19/16 11:22 AM, Christer Holmberg wrote: >> Hi, >>=20 >>>>> The discussion on ecall has become quite heated, with people dug = in on >>>>> all sides. Can we calm it down a bit? >>>>>=20 >>>>> IMO a couple of different approaches have been described that = would >>>>> work >>>>> and not violate any specs. The differences between these reflect >>>>> differences of philosophy and taste. >>>>=20 >>>> I don=C2=B9t think we have an agreement on the = would-not-violate-any-specs >>>> part. We clearly have different views on what is allowed by RFC = 6086. >>>>=20 >>>> But, I do agree we need to try to figure out how to move forward. >>>=20 >>> OK. Maybe we should start there. >>>=20 >>> I guess there is some dispute on whether it is valid for an INFO = message >>> to contain a multipart body, where one part contains the info = package >>> (C-D: info-package) and another part (C-D: by-reference) is = referenced >>> by a cid: uri in some sip header field. >>>=20 >>> In my mind there is no question that this is valid. Do you disagree, = and >>> if so, on what basis? >>=20 >> The dispute is whether a message body must be associated with an Info >> Package. >>=20 >> In my view: >>=20 >> - RFC 6086 allows bodies not associated with an Info Package in INFOs = in >> order to be backward compatible with existing pre-6086 INFO usages. >> - Any NEW usage MUST be associated with an Info Package. Sending of = MSD is >> a new INFO usage. >=20 > I disagree. I find the following in 6086: >=20 > NOTE: An INFO request can also contain other body parts that are > meaningful within the context of an invite dialog usage but are > not specifically associated with the INFO method and the > application concerned. >=20 > A body part referenced by call-info falls into that category. >=20 >> Some have said that there might even be new usages where information, >> without being associated with an Info Package, is piggybacked in = INFOs >> sent for some other purpose. It can be discussed whether such usage = is >> 6068 compliant, but never the less: in my opinion MSD is not = =E2=80=9Cpiggybacked >> information". The reason the INFO is sent to begin with is to = transport >> the requested MSD (and the ack to the request) - that is not = piggybacking >> in my opinion. >=20 > That may be your concept of how the particular info package is = defined. I think the people who disagree have a different concept. For = purposes of evaluation these should be considered alternative proposals. >=20 >> Now, in the current version of the draft, the MSD was still = associated >> with an Info Package, and the dispute was mostly regarding usage of >> Call-Info. But, based on the suggestion presented a few days ago, the = MSD >> is no longer even associated with an Info Package, so unfortuantely I >> think out views are even more different now than before. >=20 > Exactly. >=20 >> My apologies if that was more text than you hoped for, but I just = want to >> try to make my view of the situation as clear as possible :) >=20 > As long as we are making progress towards understanding each other. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_C4FDF074-EF0C-4000-9062-DB68AFBEEED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Suppose we wanted to create an INFO package that would = trigger an update of the caller=E2=80=99s location mid call.

Caller Location is carried in the Geolocation = header, and can either be a URI to a location dereferenced using HELD or = SIP Presence, or it can be a content indirect with a body.

Would you say we would have to send the = location, if sent by reference, in an INFO block?  What if it was = sent by value?

Brian
On = Aug 19, 2016, at 11:42 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Christer,

On 8/19/16 11:22 AM, Christer Holmberg = wrote:
Hi,

The = discussion on ecall has become quite heated, with people dug in on
all sides. Can we calm it down a bit?

IMO a couple of different approaches have been described that = would
work
and not violate any specs. The = differences between these reflect
differences of = philosophy and taste.

I don=C2=B9= t think we have an agreement on the would-not-violate-any-specs
part. We clearly have different views on what is allowed by = RFC 6086.

But, I do agree we need to try to = figure out how to move forward.

OK. Maybe we should start there.

I= guess there is some dispute on whether it is valid for an INFO = message
to contain a multipart body, where one part = contains the info package
(C-D: info-package) and another = part (C-D: by-reference) is referenced
by a cid: uri in = some sip header field.

In my mind there is = no question that this is valid. Do you disagree, and
if = so, on what basis?

The dispute = is whether a message body must be associated with an Info
Package.

In my view:

- RFC 6086 allows bodies not associated with = an Info Package in INFOs in
order to be backward = compatible with existing pre-6086 INFO usages.
- Any NEW = usage MUST be associated with an Info Package. Sending of MSD is
a new INFO usage.

I disagree. I find = the following in 6086:

     NOTE: An INFO = request can also contain other body parts that are
     meaningful within the context = of an invite dialog usage but are
     not = specifically associated with the INFO method and the
     application = concerned.

A body part = referenced by call-info falls into that category.

Some have said that there might even be new usages = where information,
without being associated with an Info = Package, is piggybacked in INFOs
sent for some other = purpose. It can be discussed whether such usage is
6068 = compliant, but never the less: in my opinion MSD is not = =E2=80=9Cpiggybacked
information". The reason the INFO is = sent to begin with is to transport
the requested MSD (and = the ack to the request) - that is not piggybacking
in my = opinion.

That may be your concept of how the = particular info package is defined. I think the people who disagree have = a different concept. For purposes of evaluation these should be = considered alternative proposals.

Now, in = the current version of the draft, the MSD was still associated
with an Info Package, and the dispute was mostly regarding = usage of
Call-Info. But, based on the suggestion presented = a few days ago, the MSD
is no longer even associated with = an Info Package, so unfortuantely I
think out views are = even more different now than before.

Exactly.

My apologies if that was more text than you hoped for, = but I just want to
try to make my view of the situation as = clear as possible :)

As long as we are making progress towards = understanding each other.

Thanks,
= Paul

_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_C4FDF074-EF0C-4000-9062-DB68AFBEEED2-- From nobody Fri Aug 19 09:33: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 0DE6D12D0A7 for ; Fri, 19 Aug 2016 09:33:34 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 zwQ6gfK0Ammu for ; Fri, 19 Aug 2016 09:33:32 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 46AC512D19E for ; Fri, 19 Aug 2016 09:33:32 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with SMTP id amiKbUht0ff8qamjbbeEm0; Fri, 19 Aug 2016 16:33:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with SMTP id amjab0lAHpwEGamjabs0Kb; Fri, 19 Aug 2016 16:33:31 +0000 To: Brian Rosen References: <82B78D41-B890-4918-A0F1-2DF713FCB445@brianrosen.net> From: Paul Kyzivat Message-ID: <752ae9e8-a836-c2ac-fc4c-91d20e9bf8d2@alum.mit.edu> Date: Fri, 19 Aug 2016 12:33:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <82B78D41-B890-4918-A0F1-2DF713FCB445@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCMOtCKvYJIwsAlTJILGRS/PWTgb8/HPEe7eSRmvbEAo6A5K+aOs80b28PZJoX+WQcjo2zOSVCi+OZ9WMfVE44XwbIU5YVO3HMhURkKU/ojnNLwadGNQ 3pcqUl/ma7QXKEKZf28UmWDQtVfEsQXkywM7bWIUNrK85YgJ7YZ4q5hVH/cBUDr5+8Qd89T70mDkJ2tuZyWsz1BoqI9hLvB2IUqYj+CWuoP8tSlEplN+zrRX 5bHJKGZu89B7nIXu2Je35y11EJglkDyxth0/xQm+JUU= Archived-At: Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 16:33:34 -0000 On 8/19/16 11:47 AM, Brian Rosen wrote: > Suppose we wanted to create an INFO package that would trigger an update > of the caller’s location mid call. > > Caller Location is carried in the Geolocation header, and can either be > a URI to a location dereferenced using HELD or SIP Presence, or it can > be a content indirect with a body. > > Would you say we would have to send the location, if sent by reference, > in an INFO block? What if it was sent by value? Did you intentionally send the same query twice, once to me and once to Christer? IMO, with this approach, clearly geoloc header would be used with a location in an external server, and for consistency should also be used with a cid uri. What message that goes in is a question. I assert it can go in any convenient message that permits it. The most immediately available one that would work is the response to the INFO. I *do* think this is an allowable usage, even though an info-package body is not permitted in the response to an INFO. But it could also go in a subsequent INVITE or UPDATE, or INFO. It is a little dicey whether it should be kosher to send a "no-op" info package as a vehicle to piggyback a geoloc with body. Thanks, Paul > Brian >> On Aug 19, 2016, at 11:42 AM, Paul Kyzivat > > wrote: >> >> Christer, >> >> On 8/19/16 11:22 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>>> The discussion on ecall has become quite heated, with people dug in on >>>>>> all sides. Can we calm it down a bit? >>>>>> >>>>>> IMO a couple of different approaches have been described that would >>>>>> work >>>>>> and not violate any specs. The differences between these reflect >>>>>> differences of philosophy and taste. >>>>> >>>>> I donÂąt think we have an agreement on the would-not-violate-any-specs >>>>> part. We clearly have different views on what is allowed by RFC 6086. >>>>> >>>>> But, I do agree we need to try to figure out how to move forward. >>>> >>>> OK. Maybe we should start there. >>>> >>>> I guess there is some dispute on whether it is valid for an INFO message >>>> to contain a multipart body, where one part contains the info package >>>> (C-D: info-package) and another part (C-D: by-reference) is referenced >>>> by a cid: uri in some sip header field. >>>> >>>> In my mind there is no question that this is valid. Do you disagree, and >>>> if so, on what basis? >>> >>> The dispute is whether a message body must be associated with an Info >>> Package. >>> >>> In my view: >>> >>> - RFC 6086 allows bodies not associated with an Info Package in INFOs in >>> order to be backward compatible with existing pre-6086 INFO usages. >>> - Any NEW usage MUST be associated with an Info Package. Sending of >>> MSD is >>> a new INFO usage. >> >> I disagree. I find the following in 6086: >> >> NOTE: An INFO request can also contain other body parts that are >> meaningful within the context of an invite dialog usage but are >> not specifically associated with the INFO method and the >> application concerned. >> >> A body part referenced by call-info falls into that category. >> >>> Some have said that there might even be new usages where information, >>> without being associated with an Info Package, is piggybacked in INFOs >>> sent for some other purpose. It can be discussed whether such usage is >>> 6068 compliant, but never the less: in my opinion MSD is not “piggybacked >>> information". The reason the INFO is sent to begin with is to transport >>> the requested MSD (and the ack to the request) - that is not piggybacking >>> in my opinion. >> >> That may be your concept of how the particular info package is >> defined. I think the people who disagree have a different concept. For >> purposes of evaluation these should be considered alternative proposals. >> >>> Now, in the current version of the draft, the MSD was still associated >>> with an Info Package, and the dispute was mostly regarding usage of >>> Call-Info. But, based on the suggestion presented a few days ago, the MSD >>> is no longer even associated with an Info Package, so unfortuantely I >>> think out views are even more different now than before. >> >> Exactly. >> >>> My apologies if that was more text than you hoped for, but I just want to >>> try to make my view of the situation as clear as possible :) >> >> As long as we are making progress towards understanding each other. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From nobody Fri Aug 19 11:37: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 45CBD12DA2B for ; Fri, 19 Aug 2016 11:37:30 -0700 (PDT) X-Quarantine-ID: <9ethTuWoIVWk> 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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 9ethTuWoIVWk for ; Fri, 19 Aug 2016 11:37:28 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 78ADB12D9F0 for ; Fri, 19 Aug 2016 11:37:28 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Aug 2016 11:37:27 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 19 Aug 2016 11:37:25 -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] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 18:37:30 -0000 Hi Christer, You are correct: In the compromise proposal, since the metadata/control object is associated with the INFO package, while the MSD is not, then if the PSAP sends an INFO request to the IVS containing a metadata/control object requesting an MSD, the IVS can return the MSD in the INFO response. In this case, there is no need for an ACK. At 7:46 AM +0000 8/19/16, Christer Holmberg wrote: > (NOTE that this e-mail is not related to the Info Package discussion) > > Hi, > > Assume the PSAP sends a request for MSD to the UA. > > The UA sends the MSD back. > > Why does the UA needs to send ACK? The MSD will acknowledge the > request, won't it? > > I do understand that the UA needs something if it won't send the > MSD (or whatever data was requested), e.g. if there was something > wrong with the request). But, if the UA does accept the request, > and does send the data, I don't see why the explicit ACK is needed. > It will only add message size (and maybe even additional INFO > messages). > > 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: --------------- ...neither the whole of truth nor the whole of good is revealed to any single observer, although each observer gains a partial superiority of insight from the peculiar position in which he stands.' --William James, 1899 From nobody Fri Aug 19 11:42: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 B225912DAAE for ; Fri, 19 Aug 2016 11:42: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 WCUG6kdgGhFn for ; Fri, 19 Aug 2016 11:42:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C807712DA9C for ; Fri, 19 Aug 2016 11:42:48 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Aug 2016 11:42:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Fri, 19 Aug 2016 11:42:45 -0700 To: Paul Kyzivat , 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] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 18:42:51 -0000 At 10:48 AM -0400 8/19/16, Paul Kyzivat wrote: > On 8/19/16 10:28 AM, Christer Holmberg wrote: >> Hi, >> >>>> Assume the PSAP sends a request for MSD to the UA. >>>> >>>> The UA sends the MSD back. >>>> >>>> Why does the UA needs to send ACK? The MSD will acknowledge the request, >>>> won1t it? >>>> >>>> I do understand that the UA needs something if it won1t send the MSD (or >>>> whatever data was requested), e.g. if there was something wrong with the >>>> request). But, if the UA does accept the request, and does send the >>>> data, I don1t see why the explicit ACK is needed. It will only add >>>> message size (and maybe even additional INFO messages). >>> >>> In one of the long ago original proposals, in response to the request, >>> there was either a NAK or the MSD. That would be potentially ambiguous, >>> since MSD can also be sent unsolicited: after sending a request, if you >>> received an MSD you wouldn't know if it was the one you requested, or if >>> it was an unsolicited one and there might yet be a NAK to follow. The >>> ACK resolves the ambiguity. >> >> Not sure I understand. There must be some identifier that matches the MSD >> with the request - in the same way there must be some identifier that >> matches the ACK with the request. > > Yes. AFAIK there is nothing in the MSD itself that links it to the > request, so if the MSD is intended to implicitly acknowledge the > request then there needs to be *something* with it that links it to > the request. In the compromise proposal that I sent, the MSD was sent in its own INFO, along with a metadata/control object acknowledging the request. However, since RFC 6086 permits INFO responses to contain data that is not associated with the INFO package, and since per the compromise proposal the metadata/control object is associated with the INFO package but the MSD is not, then the IVS can send a requested MSD in the INFO response, which removes any ambiguity (and also saves an extra INFO message). In the car-crash draft, if the PSAP requests the vehicle to perform an action (e.g., flash the lights), then the IVS would send an INFO request to the PSAP containing a metadata/control object acknowledging the request and indicating if it was carried out. --Randy > >>> But such issues depend heavily on the details. Minor tweaks might >>> resolve the ambiguity other ways. >>> >>> Since we are discussing various hypotheticals now, there aren't enough >>> details to know whether an ACK is needed. >> >> If you refer to the Call-Info discussion, I don1t think this has anything >> to do with that. This is not about how you transport the stuff in SIP. > > You could go with a philosophy where successful requests are never > acknowledged - only failed ones. I find such protocols to be > fragile. > > Thanks, > Paul > > _______________________________________________ > 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: --------------- You might have mail. From nobody Fri Aug 19 11: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 5403E12DAE1 for ; Fri, 19 Aug 2016 11:46:13 -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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 iBLJVC6Rt3XD for ; Fri, 19 Aug 2016 11:46:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9970012D92B for ; Fri, 19 Aug 2016 11:46:11 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Aug 2016 11:46:11 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 19 Aug 2016 11:46:08 -0700 To: Christer Holmberg , Paul Kyzivat , ECRIT From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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] Multipart with INFO 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, 19 Aug 2016 18:46:13 -0000 Hi Christer, At 3:22 PM +0000 8/19/16, Christer Holmberg wrote: > Hi, > >>>>The discussion on ecall has become quite heated, with people dug in on >>>> all sides. Can we calm it down a bit? >>>> >>>> IMO a couple of different approaches have been described that would >>>>work >>>> and not violate any specs. The differences between these reflect >>>> differences of philosophy and taste. >>> >>> I don=A9=96t think we have an agreement on the would-not-violate-any-sp= ecs >>> part. We clearly have different views on what is allowed by RFC 6086. >>> >>> But, I do agree we need to try to figure out how to move forward. >> >>OK. Maybe we should start there. >> >>I guess there is some dispute on whether it is valid for an INFO message >>to contain a multipart body, where one part contains the info package >>(C-D: info-package) and another part (C-D: by-reference) is referenced >>by a cid: uri in some sip header field. >> >>In my mind there is no question that this is valid. Do you disagree, and >>if so, on what basis? > > The dispute is whether a message body must be associated with an Info > Package. > > In my view: > > - RFC 6086 allows bodies not associated with an Info Package in INFOs in > order to be backward compatible with existing pre-6086 INFO usages. > - Any NEW usage MUST be associated with an Info Package. Sending of MSD i= s > a new INFO usage. My reading of RFC 6086 does not support your view. Specifically: NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned. And also: A UA MAY include a message body that is not associated with an Info Package in an INFO response. --Randy > > Some have said that there might even be new usages where information, > without being associated with an Info Package, is piggybacked in INFOs > sent for some other purpose. It can be discussed whether such usage is > 6068 compliant, but never the less: in my opinion MSD is not "piggybacked > information". The reason the INFO is sent to begin with is to transport > the requested MSD (and the ack to the request) - that is not piggybacking > in my opinion. > > Now, in the current version of the draft, the MSD was still associated > with an Info Package, and the dispute was mostly regarding usage of > Call-Info. But, based on the suggestion presented a few days ago, the MSD > is no longer even associated with an Info Package, so unfortuantely I > think out views are even more different now than before. > > My apologies if that was more text than you hoped for, but I just want to > try to make my view of the situation as clear as possible :) > > Regards, > > Christer > > > > >>>> Perhaps others don't agree with me on this. But can we separate these >>>> concerns? >>>> >>>> - narrow down the number of alternatives, >>>> - reach agreement that each is workable and standards compliant, >>>> - *then* debate the philosophical and taste issues. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Procedures! Of course, that's what you'd use with a *sophisticated* machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ From nobody Fri Aug 19 13:07:15 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 DDFBC12D965 for ; Fri, 19 Aug 2016 13:07:13 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ZPAlI_MrN8U8 for ; Fri, 19 Aug 2016 13:07:12 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 7B60A12DC98 for ; Fri, 19 Aug 2016 12:51:54 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-08v.sys.comcast.net with SMTP id apoIbwrQI2dNjappZbNyiD; Fri, 19 Aug 2016 19:51:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-07v.sys.comcast.net with SMTP id appXbiexZMIR7appYbci0F; Fri, 19 Aug 2016 19:51:53 +0000 To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 15:51:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGY3VMyWgQboYkJHZn5TO7olSpDWIc5ZI3D6EbhF4wvMvOm4B9PLPedkR3/QDeJZhAv3WrJ7WHxWiqmper++9Ac39UpekWkEc7UHq6L772bDp8qnRx41 EPapV32KJNzYcc2SjIaK5pWRbS/NN1Qma+w3q3JWMvFO953Hyx6jU2EQMF6qxSxzU0Il51rPujRqRZ9oamlHBtyL+++mc5xmbOLF3d1FDzNSKL8Ld24tnJI6 x+hZqmS5ZygcQMziz5hajTjfGYk/kfuXe2jGwL00m5s= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 20:07:14 -0000 On 8/19/16 2:42 PM, Randall Gellens wrote: > At 10:48 AM -0400 8/19/16, Paul Kyzivat wrote: > >> On 8/19/16 10:28 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> Assume the PSAP sends a request for MSD to the UA. >>>>> >>>>> The UA sends the MSD back. >>>>> >>>>> Why does the UA needs to send ACK? The MSD will acknowledge the >>>>> request, >>>>> won1t it? >>>>> >>>>> I do understand that the UA needs something if it won1t send the >>>>> MSD (or >>>>> whatever data was requested), e.g. if there was something wrong >>>>> with the >>>>> request). But, if the UA does accept the request, and does send the >>>>> data, I don1t see why the explicit ACK is needed. It will only add >>>>> message size (and maybe even additional INFO messages). >>>> >>>> In one of the long ago original proposals, in response to the request, >>>> there was either a NAK or the MSD. That would be potentially >>>> ambiguous, >>>> since MSD can also be sent unsolicited: after sending a request, if >>>> you >>>> received an MSD you wouldn't know if it was the one you requested, >>>> or if >>>> it was an unsolicited one and there might yet be a NAK to follow. The >>>> ACK resolves the ambiguity. >>> >>> Not sure I understand. There must be some identifier that matches >>> the MSD >>> with the request - in the same way there must be some identifier that >>> matches the ACK with the request. >> >> Yes. AFAIK there is nothing in the MSD itself that links it to the >> request, so if the MSD is intended to implicitly acknowledge the >> request then there needs to be *something* with it that links it to >> the request. > > > In the compromise proposal that I sent, the MSD was sent in its own > INFO, along with a metadata/control object acknowledging the request. > However, since RFC 6086 permits INFO responses to contain data that is > not associated with the INFO package, and since per the compromise > proposal the metadata/control object is associated with the INFO package > but the MSD is not, then the IVS can send a requested MSD in the INFO > response, which removes any ambiguity (and also saves an extra INFO > message). In the car-crash draft, if the PSAP requests the vehicle to > perform an action (e.g., flash the lights), then the IVS would send an > INFO request to the PSAP containing a metadata/control object > acknowledging the request and indicating if it was carried out. I am ok with sending the MSD as additional data on the INFO response. But I don't think that should be taken as an affirmative statement that the MSD is specifically in response to the request. Doing that would tightly couple two mechanisms that should only be loosely coupled. Consider the following following sequence of events: - caller is in a call with the PSAP - caller prepares to send a reINVITE (for codec change, or session timer, or whatever), but hasn't yet sent it. It decides, independently, to include a fresh MSD in it. - caller receives an INFO from PSAP, requesting an MSD. Now, what does the caller do? Potentially these are being processed concurrently in different threads. Can the MSD in the INVITE satisfy the request in the INFO? Does it matter whether it sends the INVITE before or after the INFO response? Thanks, Paul > --Randy > >> >>>> But such issues depend heavily on the details. Minor tweaks might >>>> resolve the ambiguity other ways. >>>> >>>> Since we are discussing various hypotheticals now, there aren't enough >>>> details to know whether an ACK is needed. >>> >>> If you refer to the Call-Info discussion, I don1t think this has >>> anything >>> to do with that. This is not about how you transport the stuff in SIP. >> >> You could go with a philosophy where successful requests are never >> acknowledged - only failed ones. I find such protocols to be fragile. >> >> Thanks, >> Paul >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From nobody Fri Aug 19 13:11: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 ADC8412D751 for ; Fri, 19 Aug 2016 13:11:02 -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 SHFCBZWEAbnS for ; Fri, 19 Aug 2016 13:10:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3087812D59D for ; Fri, 19 Aug 2016 13:02:19 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-51-57b765c95454 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 57.7A.04209.9C567B75; Fri, 19 Aug 2016 22:02:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 22:02:16 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAN0aA///UdoCAAGtwQA== Date: Fri, 19 Aug 2016 20:02:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27527@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <6d5223f3-b0bb-452f-1c8f-33307d3f0baf@alum.mit.edu> In-Reply-To: <6d5223f3-b0bb-452f-1c8f-33307d3f0baf@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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7ge7J1O3hBjuXqVk0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjc+cz5oKDKhXLr79gaWCcJNvFyMEhIWAi sWaKQxcjF4eQwHpGiW3/3zNBOEsYJe6++MIMUsQmYCHR/U+7i5GTQ0TAW+LP729sILawgLvE htnz2SHiHhI7Nt+EssMkvszeC2azCKhKPG7cwApi8wr4SjSs62UBsYUE9jFJbNwlCGJzCjhI tB+dA1bPKCAm8f3UGiYQm1lAXOLWk/lgtoSAgMSSPeeZIWxRiZeP/7FC2EoSi25/hqrXk7gx dQobhK0tsWzha2aIvYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTipNx0I2O91KLM 5OLi/Dy9vNSSTYzAaDi45bfqDsbLbxwPMQpwMCrx8Cp4bg8XYk0sK67MPcQowcGsJMI7Kwko xJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgTE61yGf/zST 6oQ/pWeC9RgEb57pTSy8/vRja8DylDMJ76rdvZJfpeTNk3JNrNj4oOja+7LVu/aHHPSO6hH4 aekw4cMbcRez7w3nbIKNP5y8e09HuVr61Rez4D+r/NZzVgYLLS1OOquy+dnN+bw2mVPexTpv n/5QJ6atmzU+UDn3aniWqqvjZSWW4oxEQy3mouJEAK/W0T6CAgAA Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 20:11:03 -0000 Hi, >>>>>> Assume the PSAP sends a request for MSD to the UA. >>>>>> >>>>>> The UA sends the MSD back. >>>>>> >>>>>> Why does the UA needs to send ACK? The MSD will acknowledge the=20 >>>>>> request, won=B9t it? >>>>>> >>>>>> I do understand that the UA needs something if it won=B9t send the=20 >>>>>> MSD (or whatever data was requested), e.g. if there was something=20 >>>>>> wrong with the request). But, if the UA does accept the request,=20 >>>>>> and does send the data, I don=B9t see why the explicit ACK is=20 >>>>>> needed. It will only add message size (and maybe even additional=20 >>>>>> INFO messages). >>>>> >>>>> In one of the long ago original proposals, in response to the=20 >>>>> request, there was either a NAK or the MSD. That would be=20 >>>>> potentially ambiguous, since MSD can also be sent unsolicited:=20 >>>>> after sending a request, if you received an MSD you wouldn't know=20 >>>>> if it was the one you requested, or if it was an unsolicited one=20 >>>>> and there might yet be a NAK to follow. The ACK resolves the=20 >>>>> ambiguity. >>>> >>>> Not sure I understand. There must be some identifier that matches=20 >>>> the MSD with the request - in the same way there must be some=20 >>>> identifier that matches the ACK with the request. >>> >>> Yes. AFAIK there is nothing in the MSD itself that links it to the=20 >>> request, so if the MSD is intended to implicitly acknowledge the=20 >>> request then there needs to be *something* with it that links it to the= request. >> >> Can we use the Content-ID header field value? Would it be allowed to=20 >> use the same header field value in the request and the associated MSD?=20 >> Then you don't need to define a separate indicator for each type of=20 >> data, as it's a MIME header field. > > Use it *how*? I have generally assumed that the scope/lifetime of a Conte= nt-ID is limited to a single=20 > message. (I don't think there is any expectation the the Content-ID value= s are unique beyond the message they are contained in.)=20 > But I don't know if that is well defined. I wouldn't be surprised if that was the case. >In any case, if you wanted to reference it from another message containing= the MSD you would need some place=20 >to put it. *In* the MSD would be an obvious place, but is there any way to= do that? If not, then >*with* the MSD. If we place in *in* the MSD it would be MSD-specific, and we'd have to defi= ne another mechanism once a new type of data comes along. I'd prefer to pla= ce it *with* the MSD - either associated with the MSD message body or the I= NFO request carrying it. >Alternatively, you can define that the request for a new MSD is just a hin= t to send one "unsolicited". > > (E.g., something like the CANCEL message. It gets a response that indicat= es it was received and understood, but that response doesn't indicate it wa= s acted upon. It is just a > hint that you would be happy to have the recip= ient do something. And it may lead to some other subsequent actions, like a= 487 indicating that another request was=20 > terminated. But you never know, or expect to know, for certain whether th= at action was the result of your CANCEL, or happened for some other > reason.) Since we explicitly request the MSD, I think there should be an explicit re= ference to the request in/with the MSD. >>>>> But such issues depend heavily on the details. Minor tweaks might=20 >>>>> resolve the ambiguity other ways. >>>>> >>>>> Since we are discussing various hypotheticals now, there aren't=20 >>>>> enough details to know whether an ACK is needed. >>>> >>>> If you refer to the Call-Info discussion, I don=B9t think this has=20 >>>> anything to do with that. This is not about how you transport the=20 >>>> stuff in SIP. >>> >>> You could go with a philosophy where successful requests are never=20 >>> acknowledged - only failed ones. I find such protocols to be fragile. >> >> But the whole idea was that the MSD/data acknowledges the request. >> >> But, IF we want something more explicit, why not e.g. a Info-Package=20 >> header field parameter? And, regarding "never acknowledged", we anyway=20 >> need some guidance on for how long the requester should wait for the=20 >> acknowledgment (no matter if it's implicit or explicit). > > It is really hard to discuss this stuff piecemeal. All the moving parts n= eed to fit together into a coherent and unambiguous whole. I guess the first question is whether we need *A* reference. Or, do we assu= me that, if an MSD comes along, it is what we requested? Regards, Christer From nobody Fri Aug 19 13:13:19 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 A2E5812D829 for ; Fri, 19 Aug 2016 13:13: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 qv54nv5QlFDw for ; Fri, 19 Aug 2016 13:13:15 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1F48212D7D0 for ; Fri, 19 Aug 2016 13:06:48 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-9f-57b766d77221 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id C1.DA.04209.7D667B75; Fri, 19 Aug 2016 22:06:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 22:06:46 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQfBOAgAA5gBA= Date: Fri, 19 Aug 2016 20:06:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC2754C@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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7q+71tO3hBv1vlCwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4Mr4dHwae8EZvoqbL98wNzAu4O5i5OSQEDCR uNN5lqmLkYtDSGA9o8Te8w0sEM4SRonpu1oZuxg5ONgELCS6/2mDmCICIRIt77lAeoUF3CU2 zJ7PDmKLCHhI7Nh8E8q2kpjW+o8VxGYRUJXY9GYDWJxXwFdiz5GPzCC2kECKxPFXSxhBbE6g G1oWvwWrYRQQk/h+ag0TiM0sIC5x68l8Jog7BSSW7DnPDGGLSrx8DDFfQkBJYtHtz1D1OhIL dn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSsl1qU mVxcnJ+nl5dasokRGA0Ht/xW3cF4+Y3jIUYBDkYlHl4Fz+3hQqyJZcWVuYcYJTiYlUR4ZyUB hXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTAqTNF3af2v OslcfUmZekzEmzdbbF3nLm83kH9dsPH18rB3N/tnLy+xcTeZZ+DE2Fu69OaGHw8+CZSeLN3t PdVTvl9ya/3pyT3Pljupvc8uv9U5S1GTie3kyd0yEWHC4SV+25I1fR4vy6s5tPdBi/FH3R3v roarbvOMP/ZdzOODxuyX31lfFVQqsRRnJBpqMRcVJwIAMgnjHYICAAA= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 20:13:18 -0000 Hi, >You are correct: In the compromise proposal, since the metadata/control ob= ject is associated with the INFO package, while the MSD is not, then if the= PSAP sends an INFO >request to the IVS containing a metadata/control objec= t requesting an MSD, the IVS can return the MSD in the INFO response. In t= his case, there is no need for an ACK. My question was whether the MSD implicitly acknowledges the request, and wh= ether we therefor need the ACK. I REALLY don't see what the Info Package is= sue has to do with that... Regards, Christer At 7:46 AM +0000 8/19/16, Christer Holmberg wrote: > (NOTE that this e-mail is not related to the Info Package discussion) > > Hi, > > Assume the PSAP sends a request for MSD to the UA. > > The UA sends the MSD back. > > Why does the UA needs to send ACK? The MSD will acknowledge the=20 > request, won't it? > > I do understand that the UA needs something if it won't send the MSD=20 > (or whatever data was requested), e.g. if there was something wrong=20 > with the request). But, if the UA does accept the request, and does=20 > send the data, I don't see why the explicit ACK is needed. > It will only add message size (and maybe even additional INFO=20 > messages). > > 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: --------------- ...neither the whole = of truth nor the whole of good is revealed to any single observer, although= each observer gains a partial superiority of insight from the peculiar pos= ition in which he stands.' --William James, 1899 From nobody Fri Aug 19 13:14:50 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 8746912D6AE for ; Fri, 19 Aug 2016 13:14:48 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 KbIoeIKkeaYP for ; Fri, 19 Aug 2016 13:14:47 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 35F1912D615 for ; Fri, 19 Aug 2016 13:10:14 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-12v.sys.comcast.net with SMTP id aq7HbugO3lHMYaq7JbJ9KW; Fri, 19 Aug 2016 20:10:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-01v.sys.comcast.net with SMTP id aq7JbhxhudYnnaq7JbKvmd; Fri, 19 Aug 2016 20:10:13 +0000 To: Christer Holmberg , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <6d5223f3-b0bb-452f-1c8f-33307d3f0baf@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27527@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 16:10:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC27527@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfGkjfkgspq600adVYiQ5w0kk9z0j7RzOGZfgV909kA3EXJJ6MHp4PNYE6Y3Vo2hBAkMxwWWhAQzW4nvl7dfUjjiaFzE47NtHRiRoJhgmnGCZRELcs+tF jlMVdfbWvoFQQUCVplNCQEnLbdaUvxl2VG3aPg/J75DRJJETODTMESFCrva08IKVMT2uMuPNO9sX0ARsEQPX++i0DWxiYLk9BD5/L9kQRizMXYzb2pb7aCY6 Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 20:14:48 -0000 On 8/19/16 4:02 PM, Christer Holmberg wrote: > Hi, > >>>>>>> Assume the PSAP sends a request for MSD to the UA. >>>>>>> >>>>>>> The UA sends the MSD back. >>>>>>> >>>>>>> Why does the UA needs to send ACK? The MSD will acknowledge the >>>>>>> request, wonąt it? >>>>>>> >>>>>>> I do understand that the UA needs something if it wonąt send the >>>>>>> MSD (or whatever data was requested), e.g. if there was something >>>>>>> wrong with the request). But, if the UA does accept the request, >>>>>>> and does send the data, I donąt see why the explicit ACK is >>>>>>> needed. It will only add message size (and maybe even additional >>>>>>> INFO messages). >>>>>> >>>>>> In one of the long ago original proposals, in response to the >>>>>> request, there was either a NAK or the MSD. That would be >>>>>> potentially ambiguous, since MSD can also be sent unsolicited: >>>>>> after sending a request, if you received an MSD you wouldn't know >>>>>> if it was the one you requested, or if it was an unsolicited one >>>>>> and there might yet be a NAK to follow. The ACK resolves the >>>>>> ambiguity. >>>>> >>>>> Not sure I understand. There must be some identifier that matches >>>>> the MSD with the request - in the same way there must be some >>>>> identifier that matches the ACK with the request. >>>> >>>> Yes. AFAIK there is nothing in the MSD itself that links it to the >>>> request, so if the MSD is intended to implicitly acknowledge the >>>> request then there needs to be *something* with it that links it to the request. >>> >>> Can we use the Content-ID header field value? Would it be allowed to >>> use the same header field value in the request and the associated MSD? >>> Then you don't need to define a separate indicator for each type of >>> data, as it's a MIME header field. >> >> Use it *how*? I have generally assumed that the scope/lifetime of a Content-ID is limited to a single >> message. (I don't think there is any expectation the the Content-ID values are unique beyond the message they are contained in.) >> But I don't know if that is well defined. > > I wouldn't be surprised if that was the case. > >> In any case, if you wanted to reference it from another message containing the MSD you would need some place >> to put it. *In* the MSD would be an obvious place, but is there any way to do that? If not, then >> *with* the MSD. > > If we place in *in* the MSD it would be MSD-specific, and we'd have to define another mechanism once a new type of data comes along. I'd prefer to place it *with* the MSD - either associated with the MSD message body or the INFO request carrying it. > >> Alternatively, you can define that the request for a new MSD is just a hint to send one "unsolicited". >> >> (E.g., something like the CANCEL message. It gets a response that indicates it was received and understood, but that response doesn't indicate it was acted upon. It is just a > hint that you would be happy to have the recipient do something. And it may lead to some other subsequent actions, like a 487 indicating that another request was >> terminated. But you never know, or expect to know, for certain whether that action was the result of your CANCEL, or happened for some other >> reason.) > > Since we explicitly request the MSD, I think there should be an explicit reference to the request in/with the MSD. > >>>>>> But such issues depend heavily on the details. Minor tweaks might >>>>>> resolve the ambiguity other ways. >>>>>> >>>>>> Since we are discussing various hypotheticals now, there aren't >>>>>> enough details to know whether an ACK is needed. >>>>> >>>>> If you refer to the Call-Info discussion, I donąt think this has >>>>> anything to do with that. This is not about how you transport the >>>>> stuff in SIP. >>>> >>>> You could go with a philosophy where successful requests are never >>>> acknowledged - only failed ones. I find such protocols to be fragile. >>> >>> But the whole idea was that the MSD/data acknowledges the request. >>> >>> But, IF we want something more explicit, why not e.g. a Info-Package >>> header field parameter? And, regarding "never acknowledged", we anyway >>> need some guidance on for how long the requester should wait for the >>> acknowledgment (no matter if it's implicit or explicit). >> >> It is really hard to discuss this stuff piecemeal. All the moving parts need to fit together into a coherent and unambiguous whole. > > I guess the first question is whether we need *A* reference. Or, do we assume that, if an MSD comes along, it is what we requested? I think it is bad to do that unless there is something that ties it to the request. But it may not be necessary to know if the one you get is in response to your request for a new one. You want a new one, and you get a new one. Isn't that good enough? Later you might get another new one, even without asking again. Thanks, Paul From nobody Fri Aug 19 13:15: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 A7E2B12D9A1 for ; Fri, 19 Aug 2016 13:14: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 5CahYXshFr7L for ; Fri, 19 Aug 2016 13:14:48 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E431712DB3A for ; Fri, 19 Aug 2016 13:10:21 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-76-57b767aa7461 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 35.1B.04209.AA767B75; Fri, 19 Aug 2016 22:10:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 22:10:18 +0200 From: Christer Holmberg To: Brian Rosen Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///TFwCAAGrJIA== Date: Fri, 19 Aug 2016 20:10:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27572@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdVHdN+vZwg2n/OCymHdvAbtG46Cmr xYoNB1gdmD3+vv/A5LFkyU8mj0WHfrAGMEdx2aSk5mSWpRbp2yVwZVz+v4W1YJZ6xba/5Q2M M9S6GDk5JARMJGasm8DUxcjFISSwnlFi74I9zBDOEkaJOWe/snQxcnCwCVhIdP/TBmkQEVCS WDtxAxuIzSzgIHF92zJ2EFtYQEPi8IQZTBA1mhKTr71ghrCdJJZ96WcEsVkEVCU+L94LZvMK +Erc2LmRDWJXH5PE9DnLwRKcAo4S03r2gg1lFBCT+H5qDRPEMnGJW0/mM0FcLSCxZM95Zghb VOLl43+sELaSxKLbn5lAbmYGOmL9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2chdMxC0jEL SccCRpZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFxc3DLb9UdjJffOB5iFOBgVOLhVfDc Hi7EmlhWXJl7iFGCg1lJhHdWElCINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs 1NSC1CKYLBMHp1QD4xSJeJNQZfVU3S2q6xMXbJbdYN1wia1VVXXCyZn9Ez8Jvbu0evnWhQ2T zFzW1r3j2WM2S3huqv6SNcsn23qLv9wfFvgm/+/msjs+Sm2G1mmeviLiys9yVLnFG+dqWrAa B0pIiHak9fAavf6xd3e3d29La+kJgXc3WRUmN+fXTy1N7VTLUWxQYinOSDTUYi4qTgQAW5zp 3pcCAAA= Archived-At: Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 20:14:51 -0000 SGksDQoNCj4gU3VwcG9zZSB3ZSB3YW50ZWQgdG8gY3JlYXRlIGFuIElORk8gcGFja2FnZSB0aGF0 IHdvdWxkIHRyaWdnZXIgYW4gdXBkYXRlIG9mIHRoZSBjYWxsZXLigJlzIGxvY2F0aW9uIG1pZCBj YWxsLg0KPg0KPiBDYWxsZXIgTG9jYXRpb24gaXMgY2FycmllZCBpbiB0aGUgR2VvbG9jYXRpb24g aGVhZGVyLCBhbmQgY2FuIGVpdGhlciBiZSBhIFVSSSB0byBhIGxvY2F0aW9uIGRlcmVmZXJlbmNl ZCB1c2luZyANCj4gSEVMRCBvciBTSVAgUHJlc2VuY2UsIG9yIGl0IGNhbiBiZSBhIGNvbnRlbnQg aW5kaXJlY3Qgd2l0aCBhIGJvZHkuDQo+DQo+IFdvdWxkIHlvdSBzYXkgd2Ugd291bGQgaGF2ZSB0 byBzZW5kIHRoZSBsb2NhdGlvbiwgaWYgc2VudCBieSByZWZlcmVuY2UsIGluIGFuIElORk8gYmxv Y2s/ICBXaGF0IGlmIGl0IHdhcyBzZW50IGJ5IHZhbHVlPw0KDQpJIGFtIG5vdCBzdXJlIEkgdW5k ZXJzdGFuZCB0aGUgcXVlc3Rpb24uIFdoYXQgZG8geW91IG1lYW4gYnkgIklORk8gYmxvY2siPw0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4gT24gQXVnIDE5LCAyMDE2LCBhdCAxMToyMiBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQo+IA0KPiBIaSwNCj4gDQo+Pj4+IFRoZSBkaXNjdXNzaW9uIG9uIGVjYWxsIGhhcyBiZWNv bWUgcXVpdGUgaGVhdGVkLCB3aXRoIHBlb3BsZSBkdWcgaW4gDQo+Pj4+IG9uIGFsbCBzaWRlcy4g Q2FuIHdlIGNhbG0gaXQgZG93biBhIGJpdD8NCj4+Pj4gDQo+Pj4+IElNTyBhIGNvdXBsZSBvZiBk aWZmZXJlbnQgYXBwcm9hY2hlcyBoYXZlIGJlZW4gZGVzY3JpYmVkIHRoYXQgd291bGQgDQo+Pj4+ IHdvcmsgYW5kIG5vdCB2aW9sYXRlIGFueSBzcGVjcy4gVGhlIGRpZmZlcmVuY2VzIGJldHdlZW4g dGhlc2UgDQo+Pj4+IHJlZmxlY3QgZGlmZmVyZW5jZXMgb2YgcGhpbG9zb3BoeSBhbmQgdGFzdGUu DQo+Pj4gDQo+Pj4gSSBkb27CuXQgdGhpbmsgd2UgaGF2ZSBhbiBhZ3JlZW1lbnQgb24gdGhlIA0K Pj4+IHdvdWxkLW5vdC12aW9sYXRlLWFueS1zcGVjcyBwYXJ0LiBXZSBjbGVhcmx5IGhhdmUgZGlm ZmVyZW50IHZpZXdzIG9uIHdoYXQgaXMgYWxsb3dlZCBieSBSRkMgNjA4Ni4NCj4+PiANCj4+PiBC dXQsIEkgZG8gYWdyZWUgd2UgbmVlZCB0byB0cnkgdG8gZmlndXJlIG91dCBob3cgdG8gbW92ZSBm b3J3YXJkLg0KPj4gDQo+PiBPSy4gTWF5YmUgd2Ugc2hvdWxkIHN0YXJ0IHRoZXJlLg0KPj4gDQo+ PiBJIGd1ZXNzIHRoZXJlIGlzIHNvbWUgZGlzcHV0ZSBvbiB3aGV0aGVyIGl0IGlzIHZhbGlkIGZv ciBhbiBJTkZPIA0KPj4gbWVzc2FnZSB0byBjb250YWluIGEgbXVsdGlwYXJ0IGJvZHksIHdoZXJl IG9uZSBwYXJ0IGNvbnRhaW5zIHRoZSBpbmZvIA0KPj4gcGFja2FnZQ0KPj4gKEMtRDogaW5mby1w YWNrYWdlKSBhbmQgYW5vdGhlciBwYXJ0IChDLUQ6IGJ5LXJlZmVyZW5jZSkgaXMgDQo+PiByZWZl cmVuY2VkIGJ5IGEgY2lkOiB1cmkgaW4gc29tZSBzaXAgaGVhZGVyIGZpZWxkLg0KPj4gDQo+PiBJ biBteSBtaW5kIHRoZXJlIGlzIG5vIHF1ZXN0aW9uIHRoYXQgdGhpcyBpcyB2YWxpZC4gRG8geW91 IGRpc2FncmVlLCANCj4+IGFuZCBpZiBzbywgb24gd2hhdCBiYXNpcz8NCj4gDQo+IFRoZSBkaXNw dXRlIGlzIHdoZXRoZXIgYSBtZXNzYWdlIGJvZHkgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggYW4g SW5mbyANCj4gUGFja2FnZS4NCj4gDQo+IEluIG15IHZpZXc6IA0KPiANCj4gLSBSRkMgNjA4NiBh bGxvd3MgYm9kaWVzIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4gSW5mbyBQYWNrYWdlIGluIElORk9z IA0KPiBpbiBvcmRlciB0byBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgcHJl LTYwODYgSU5GTyB1c2FnZXMuDQo+IC0gQW55IE5FVyB1c2FnZSBNVVNUIGJlIGFzc29jaWF0ZWQg d2l0aCBhbiBJbmZvIFBhY2thZ2UuIFNlbmRpbmcgb2YgDQo+IE1TRCBpcyBhIG5ldyBJTkZPIHVz YWdlLg0KPiANCj4gU29tZSBoYXZlIHNhaWQgdGhhdCB0aGVyZSBtaWdodCBldmVuIGJlIG5ldyB1 c2FnZXMgd2hlcmUgaW5mb3JtYXRpb24sIA0KPiB3aXRob3V0IGJlaW5nIGFzc29jaWF0ZWQgd2l0 aCBhbiBJbmZvIFBhY2thZ2UsIGlzIHBpZ2d5YmFja2VkIGluIElORk9zIA0KPiBzZW50IGZvciBz b21lIG90aGVyIHB1cnBvc2UuIEl0IGNhbiBiZSBkaXNjdXNzZWQgd2hldGhlciBzdWNoIHVzYWdl IGlzDQo+IDYwNjggY29tcGxpYW50LCBidXQgbmV2ZXIgdGhlIGxlc3M6IGluIG15IG9waW5pb24g TVNEIGlzIG5vdCANCj4g4oCccGlnZ3liYWNrZWQgaW5mb3JtYXRpb24iLiBUaGUgcmVhc29uIHRo ZSBJTkZPIGlzIHNlbnQgdG8gYmVnaW4gd2l0aCANCj4gaXMgdG8gdHJhbnNwb3J0IHRoZSByZXF1 ZXN0ZWQgTVNEIChhbmQgdGhlIGFjayB0byB0aGUgcmVxdWVzdCkgLSB0aGF0IA0KPiBpcyBub3Qg cGlnZ3liYWNraW5nIGluIG15IG9waW5pb24uDQo+IA0KPiBOb3csIGluIHRoZSBjdXJyZW50IHZl cnNpb24gb2YgdGhlIGRyYWZ0LCB0aGUgTVNEIHdhcyBzdGlsbCBhc3NvY2lhdGVkIA0KPiB3aXRo IGFuIEluZm8gUGFja2FnZSwgYW5kIHRoZSBkaXNwdXRlIHdhcyBtb3N0bHkgcmVnYXJkaW5nIHVz YWdlIG9mIA0KPiBDYWxsLUluZm8uIEJ1dCwgYmFzZWQgb24gdGhlIHN1Z2dlc3Rpb24gcHJlc2Vu dGVkIGEgZmV3IGRheXMgYWdvLCB0aGUgDQo+IE1TRCBpcyBubyBsb25nZXIgZXZlbiBhc3NvY2lh dGVkIHdpdGggYW4gSW5mbyBQYWNrYWdlLCBzbyANCj4gdW5mb3J0dWFudGVseSBJIHRoaW5rIG91 dCB2aWV3cyBhcmUgZXZlbiBtb3JlIGRpZmZlcmVudCBub3cgdGhhbiBiZWZvcmUuDQo+IA0KPiBN eSBhcG9sb2dpZXMgaWYgdGhhdCB3YXMgbW9yZSB0ZXh0IHRoYW4geW91IGhvcGVkIGZvciwgYnV0 IEkganVzdCB3YW50IA0KPiB0byB0cnkgdG8gbWFrZSBteSB2aWV3IG9mIHRoZSBzaXR1YXRpb24g YXMgY2xlYXIgYXMgcG9zc2libGUgOikNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0K PiANCj4gDQo+IA0KPiANCj4+Pj4gUGVyaGFwcyBvdGhlcnMgZG9uJ3QgYWdyZWUgd2l0aCBtZSBv biB0aGlzLiBCdXQgY2FuIHdlIHNlcGFyYXRlIA0KPj4+PiB0aGVzZSBjb25jZXJucz8NCj4+Pj4g DQo+Pj4+IC0gbmFycm93IGRvd24gdGhlIG51bWJlciBvZiBhbHRlcm5hdGl2ZXMsDQo+Pj4+IC0g cmVhY2ggYWdyZWVtZW50IHRoYXQgZWFjaCBpcyB3b3JrYWJsZSBhbmQgc3RhbmRhcmRzIGNvbXBs aWFudCwNCj4+Pj4gLSAqdGhlbiogZGViYXRlIHRoZSBwaGlsb3NvcGhpY2FsIGFuZCB0YXN0ZSBp c3N1ZXMuDQo+Pj4+IA0KPj4+PiAJVGhhbmtzLA0KPj4+PiAJUGF1bA0KPj4+PiANCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRWNyaXQg bWFpbGluZyBsaXN0DQo+Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+PiANCj4+PiANCj4+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGlu ZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCg0K From nobody Fri Aug 19 13:17: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 5CD8612D144 for ; Fri, 19 Aug 2016 13:17:31 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 vCWB1AsNoyT9 for ; Fri, 19 Aug 2016 13:17:29 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 C7CF412D15E for ; Fri, 19 Aug 2016 13:15:53 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-05v.sys.comcast.net with SMTP id aqCdbkH0O2FGMaqCnbdALw; Fri, 19 Aug 2016 20:15:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with SMTP id aqCmbDS0IEilmaqCmbhdBt; Fri, 19 Aug 2016 20:15:53 +0000 To: Christer Holmberg , Brian Rosen References: <7594FB04B1934943A5C02806D1A2204B4BC27572@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 16:15:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC27572@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFTVswg6AXf/r9Qwx1qFRmQ6TNwqhYXlYpi1zZ73VDsMmhUYNDqSJ32PcxySThsogHrtUcqavSXhxnHtO5NOuleM4g+tqpD46WvtoGk1kQNHFBm8wbHk 02uo1yN6Ykkyv/FjOgjVBEodE8Sa7Q3oJprF0RhodTioPdiqE7f3MzCSA+vJt3q2i2zbiSMtxvMPa0L3EZ6GF1uKERXqgoJtwO+z3/AFoFlq/DLtvlmP1f3h c7rzOnXuCfaekKYfJmCLCWwC6tnbevMgMSbVX/eBtZc= Archived-At: Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 20:17:31 -0000 On 8/19/16 4:10 PM, Christer Holmberg wrote: > Hi, > >> Suppose we wanted to create an INFO package that would trigger an update of the caller’s location mid call. >> >> Caller Location is carried in the Geolocation header, and can either be a URI to a location dereferenced using >> HELD or SIP Presence, or it can be a content indirect with a body. >> >> Would you say we would have to send the location, if sent by reference, in an INFO block? What if it was sent by value? > > I am not sure I understand the question. What do you mean by "INFO block"? > Sorry. S/INFO block/INFO message/ > Regards, > > Christer > > >> On Aug 19, 2016, at 11:22 AM, Christer Holmberg wrote: >> >> Hi, >> >>>>> The discussion on ecall has become quite heated, with people dug in >>>>> on all sides. Can we calm it down a bit? >>>>> >>>>> IMO a couple of different approaches have been described that would >>>>> work and not violate any specs. The differences between these >>>>> reflect differences of philosophy and taste. >>>> >>>> I donÂąt think we have an agreement on the >>>> would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086. >>>> >>>> But, I do agree we need to try to figure out how to move forward. >>> >>> OK. Maybe we should start there. >>> >>> I guess there is some dispute on whether it is valid for an INFO >>> message to contain a multipart body, where one part contains the info >>> package >>> (C-D: info-package) and another part (C-D: by-reference) is >>> referenced by a cid: uri in some sip header field. >>> >>> In my mind there is no question that this is valid. Do you disagree, >>> and if so, on what basis? >> >> The dispute is whether a message body must be associated with an Info >> Package. >> >> In my view: >> >> - RFC 6086 allows bodies not associated with an Info Package in INFOs >> in order to be backward compatible with existing pre-6086 INFO usages. >> - Any NEW usage MUST be associated with an Info Package. Sending of >> MSD is a new INFO usage. >> >> Some have said that there might even be new usages where information, >> without being associated with an Info Package, is piggybacked in INFOs >> sent for some other purpose. It can be discussed whether such usage is >> 6068 compliant, but never the less: in my opinion MSD is not >> “piggybacked information". The reason the INFO is sent to begin with >> is to transport the requested MSD (and the ack to the request) - that >> is not piggybacking in my opinion. >> >> Now, in the current version of the draft, the MSD was still associated >> with an Info Package, and the dispute was mostly regarding usage of >> Call-Info. But, based on the suggestion presented a few days ago, the >> MSD is no longer even associated with an Info Package, so >> unfortuantely I think out views are even more different now than before. >> >> My apologies if that was more text than you hoped for, but I just want >> to try to make my view of the situation as clear as possible :) >> >> Regards, >> >> Christer >> >> >> >> >>>>> Perhaps others don't agree with me on this. But can we separate >>>>> these concerns? >>>>> >>>>> - narrow down the number of alternatives, >>>>> - reach agreement that each is workable and standards compliant, >>>>> - *then* debate the philosophical and taste issues. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> 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 Aug 19 13:20: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 1CF6512D121 for ; Fri, 19 Aug 2016 13:20:29 -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 mmDtlIVVLnJ5 for ; Fri, 19 Aug 2016 13:20:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 F19CD12D0DB for ; Fri, 19 Aug 2016 13:20:26 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-17-57b76a076ab3 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id CC.8D.06563.70A67B75; Fri, 19 Aug 2016 22:20:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 22:20:23 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAN0aA///UdoCAAGtwQP//4qOAAARdS5A= Date: Fri, 19 Aug 2016 20:20:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC2766D@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <6d5223f3-b0bb-452f-1c8f-33307d3f0baf@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27527@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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7jS5H1vZwgyN/TS0aFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxdcUl9oJXmhU/P2o2MB5U7GLk5JAQMJG4 2nOHrYuRi0NIYD2jxINbB5kgnCWMEs9PX2bvYuTgYBOwkOj+pw3SICLgLfHn9zc2EFtYwF1i w+z57BBxD4kdm29C2UkSN14vYgJpZRFQlVi20A8kzCvgK7Fm9ixGiPE7mCXufD8GVs8p4CCx ePZrJhCbUUBM4vupNWA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSWLR7c9Q9XoSN6ZO YYOwtYH2vmaGWCwocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4u zs/Ty0st2cQIjIaDW37r7mBc/drxEKMAB6MSD6+C5/ZwIdbEsuLK3EOMEhzMSiK8fulAId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYwcodnJMtPj5roW qv+b8XRO132Dg/LnlkzIPh7X61s8+99+16zXoS4yrJEL6u4ZrHlwfq3+umlOW5vSy2M/rpOv yTPfFWW/38JEKPK47+9n5/6s0hC982qm7Fpd3qA5ZnvFhfdxvzy7d6K72g7pBfO8m43nmGXk Bf6bffFAiyiLdnt1+TfG43lKLMUZiYZazEXFiQDCg61jggIAAA== Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 20:20:29 -0000 Hi, >>>>>>>> Assume the PSAP sends a request for MSD to the UA. >>>>>>>> >>>>>>>> The UA sends the MSD back. >>>>>>>> >>>>>>>> Why does the UA needs to send ACK? The MSD will acknowledge the=20 >>>>>>>> request, won=B9t it? >>>>>>>> >>>>>>>> I do understand that the UA needs something if it won=B9t send the= =20 >>>>>>>> MSD (or whatever data was requested), e.g. if there was=20 >>>>>>>> something wrong with the request). But, if the UA does accept=20 >>>>>>>> the request, and does send the data, I don=B9t see why the=20 >>>>>>>> explicit ACK is needed. It will only add message size (and maybe=20 >>>>>>>> even additional INFO messages). >>>>>>> >>>>>>> In one of the long ago original proposals, in response to the=20 >>>>>>> request, there was either a NAK or the MSD. That would be=20 >>>>>>> potentially ambiguous, since MSD can also be sent unsolicited: >>>>>>> after sending a request, if you received an MSD you wouldn't know=20 >>>>>>> if it was the one you requested, or if it was an unsolicited one=20 >>>>>>> and there might yet be a NAK to follow. The ACK resolves the=20 >>>>>>> ambiguity. >>>>>> >>>>>> Not sure I understand. There must be some identifier that matches=20 >>>>>> the MSD with the request - in the same way there must be some=20 >>>>>> identifier that matches the ACK with the request. >>>>> >>>>> Yes. AFAIK there is nothing in the MSD itself that links it to the=20 >>>>> request, so if the MSD is intended to implicitly acknowledge the=20 >>>>> request then there needs to be *something* with it that links it to t= he request. >>>> >>>> Can we use the Content-ID header field value? Would it be allowed to=20 >>>> use the same header field value in the request and the associated MSD? >>>> Then you don't need to define a separate indicator for each type of=20 >>>> data, as it's a MIME header field. >>> >>> Use it *how*? I have generally assumed that the scope/lifetime of a=20 >>> Content-ID is limited to a single message. (I don't think there is=20 >>> any expectation the the Content-ID values are unique beyond the message= they are contained in.) But I don't know if that is well defined. >> >> I wouldn't be surprised if that was the case. >> >>> In any case, if you wanted to reference it from another message=20 >>> containing the MSD you would need some place to put it. *In* the MSD=20 >>> would be an obvious place, but is there any way to do that? If not,=20 >>> then *with* the MSD. >> >> If we place in *in* the MSD it would be MSD-specific, and we'd have to d= efine another mechanism=20 >> once a new type of data comes along. I'd prefer to place it *with* the M= SD - either associated with=20 >> the MSD message body or the INFO request carrying it. >> >>> Alternatively, you can define that the request for a new MSD is just a = hint to send one "unsolicited". >>> >>> (E.g., something like the CANCEL message. It gets a response that=20 >>> indicates it was received and understood, but that response doesn't=20 >>> indicate it was acted upon. It is just a > hint that you would be=20 >>> happy to have the recipient do something. And it may lead to some=20 >>> other subsequent actions, like a 487 indicating that another request=20 >>> was terminated. But you never know, or expect to know, for certain=20 >>> whether that action was the result of your CANCEL, or happened for=20 >>> some other reason.) >> >> Since we explicitly request the MSD, I think there should be an explicit= reference to the request in/with the MSD. >> >>>>>>> But such issues depend heavily on the details. Minor tweaks might=20 >>>>>>> resolve the ambiguity other ways. >>>>>>> >>>>>>> Since we are discussing various hypotheticals now, there aren't=20 >>>>>>> enough details to know whether an ACK is needed. >>>>>> >>>>>> If you refer to the Call-Info discussion, I don=B9t think this has=20 >>>>>> anything to do with that. This is not about how you transport the=20 >>>>>> stuff in SIP. >>>>> >>>>> You could go with a philosophy where successful requests are never=20 >>>>> acknowledged - only failed ones. I find such protocols to be fragile. >>>> >>>> But the whole idea was that the MSD/data acknowledges the request. >>>> >>>> But, IF we want something more explicit, why not e.g. a Info-Package=20 >>>> header field parameter? And, regarding "never acknowledged", we=20 >>>> anyway need some guidance on for how long the requester should wait=20 >>>> for the acknowledgment (no matter if it's implicit or explicit). >>> >>> It is really hard to discuss this stuff piecemeal. All the moving parts= need to fit together into a coherent and unambiguous whole. >> >> I guess the first question is whether we need *A* reference. Or, do we a= ssume that, if an MSD comes along, it is what we requested? > > I think it is bad to do that unless there is something that ties it to th= e request. > > But it may not be necessary to know if the one you get is in response to = your request for a new one. You want a new one, and you get a new one.=20 > Isn't that good enough? Later you might get another new one, even without= asking again. I just think it's good protocol design to be able to match the delivered da= ta with the request for the data to be delivered.=20 Regards, Christer From nobody Fri Aug 19 13:55: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 7263E12D18D for ; Fri, 19 Aug 2016 13:55:22 -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 rpIHxDSv2UOV for ; Fri, 19 Aug 2016 13:55:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 54D2112D098 for ; Fri, 19 Aug 2016 13:55:20 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-67-57b772362c48 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 15.2E.04209.63277B75; Fri, 19 Aug 2016 22:55:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 22:55:18 +0200 From: Christer Holmberg To: Paul Kyzivat , ECRIT Thread-Topic: Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///SIgCAAHCnoA== Date: Fri, 19 Aug 2016 20:55:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27707@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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7lK5Z0fZwg6u7dS0aFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxdPdX9oLLkhU/PixhaWDsEOli5OSQEDCR mHh8HVsXIxeHkMB6Rok3T76ygCSEBJYwSky4GtzFyMHBJmAh0f1PGyQsIuAgMbt5FyuILSyg IPF5/1JGiLiixLQJ89kgbCeJVQ8ngsVZBFQlvrb1sIOM4RXwlTj3nR1iVS+TxMoLLSwgcU6g md+OKYKUMwqISXw/tYYJxGYWEJe49WQ+E8SZAhJL9pxnhrBFJV4+/scKYStJLLr9GapeT+LG 1ClsELa2xLKFr8HqeQUEJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMosWpxUm56UbGeqlF mcnFxfl5enmpJZsYgbFwcMtv1R2Ml984HmIU4GBU4uFV8NweLsSaWFZcmXuIUYKDWUmEt7kA KMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoGRrf2QZJ/V 2R9LXt8o1lusZsu+uvTY5CJHjt1rp613PTTbwOFQ5tm08M2ai+ds7l8j8WfheqXPrLaOmq5P 2CKcbq7ydZ3cndPZ3/4u9qLWtvDTjkxtf5YrHL/UsGTbVt3bUpNu1r6J/njQv5G/ZIlw/rrL c1X+Zxeyly/4v/1MX75Y+sMpmt/nKbEUZyQaajEXFScCAG9butyBAgAA Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 20:55:22 -0000 Hi, >>>>> The discussion on ecall has become quite heated, with people dug in=20 >>>>> on all sides. Can we calm it down a bit? >>>>> >>>>> IMO a couple of different approaches have been described that would=20 >>>>> work and not violate any specs. The differences between these=20 >>>>> reflect differences of philosophy and taste. >>>> >>>> I don=B9t think we have an agreement on the=20 >>>> would-not-violate-any-specs part. We clearly have different views on w= hat is allowed by RFC 6086. >>>> >>>> But, I do agree we need to try to figure out how to move forward. >>> >>> OK. Maybe we should start there. >>> >>> I guess there is some dispute on whether it is valid for an INFO=20 >>> message to contain a multipart body, where one part contains the info=20 >>> package >>> (C-D: info-package) and another part (C-D: by-reference) is=20 >>> referenced by a cid: uri in some sip header field. >>> >>> In my mind there is no question that this is valid. Do you disagree,=20 >>> and if so, on what basis? >> >> The dispute is whether a message body must be associated with an Info=20 >> Package. >> >> In my view: >> >> - RFC 6086 allows bodies not associated with an Info Package in INFOs=20 >> in order to be backward compatible with existing pre-6086 INFO usages. >> - Any NEW usage MUST be associated with an Info Package. Sending of=20 >> MSD is a new INFO usage. > > I disagree. I find the following in 6086: > > NOTE: An INFO request can also contain other body parts that are > meaningful within the context of an invite dialog usage but are > not specifically associated with the INFO method and the > application concerned. So, you are saying that the MSD is not associated with the ecall applicatio= n??? RFC 6086 also says: "Any new usage MUST use the Info Package mechanism defined in this specification, since it does not share the issues associated with legacy INFO usage, and since Info Packages can be registered with IANA." And, in my opinion, sending of MSD *is* part of the new INFO usage. It's no= t something else that we add to the INFO. Otherwise, why did we do RFC 6086 in the first place? We can just allow peo= ple to use - and standardize such usage - as in the past, with all the prob= lems associated, just by saying the content is not associated with the appl= ication... >> Some have said that there might even be new usages where information,=20 >> without being associated with an Info Package, is piggybacked in INFOs=20 >> sent for some other purpose. It can be discussed whether such usage is >> 6068 compliant, but never the less: in my opinion MSD is not=20 >> "piggybacked information". The reason the INFO is sent to begin with=20 >> is to transport the requested MSD (and the ack to the request) - that=20 >> is not piggybacking in my opinion. > > That may be your concept of how the particular info package is defined.=20 > I think the people who disagree have a different concept. For purposes of= evaluation these should be considered alternative proposals. Well, I have always assumed that we agreed that one of the main reason we s= end the INFO is to transport the MSD... Regards, Christer From nobody Fri Aug 19 14:00: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 402BA12B039 for ; Fri, 19 Aug 2016 14:00:21 -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 4-kmRyfo9hdS for ; Fri, 19 Aug 2016 14:00:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A13D012D150 for ; Fri, 19 Aug 2016 14:00:18 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-3a-57b7735fdab8 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id C3.8C.02493.F5377B75; Fri, 19 Aug 2016 23:00:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Fri, 19 Aug 2016 23:00:15 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat , ECRIT Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMAgAAFhgCAAEXjAA== Date: Fri, 19 Aug 2016 21:00:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27740@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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7vW5C8fZwgwnT5SwaFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mu787mcruMdWcefkF6YG xgbWLkZODgkBE4m33avZuhi5OIQE1jNKnH3+lxnCWcIocfV5A2MXIwcHm4CFRPc/bZAGEYF8 ifl7etlBbGEBDYnDE2YwQcQ1JSZfe8EMYTtJLDr5BWwBi4CqxJGVS9lAxvAK+EpMny4HEhYS aGSSWLIzHcTmBLqh8f1TsJGMAmIS30+tARvJLCAucevJfCaIOwUkluw5zwxhi0q8fPwP6n4l iUW3P0PV60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKUbQ4 tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzBCDm75bbWD8eBzx0OMAhyMSjy8Cp7bw4VYE8uKK3MP MUpwMCuJ8DYXAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFw SjUwCm1Ol3u8zaI4Ut3n8LzNrQc0/+2RcL/g6NDgK1VxsmURV0b/UcvWiCvS/kcS9r7+dunu 2a1q+mf0XwbNvLJjmxXDnQrRmt6ouZt502dfuFRkc8T6hrS4q/uvh4xc5rYlm5XOqbDknXt4 LWRua/qS/Geqilvz03YrXVENeV657+rGfbvYvB6UK7EUZyQaajEXFScCAD64VSOMAgAA Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 21:00:21 -0000 Hi, ... >My reading of RFC 6086 does not support your view. Specifically: > > NOTE: An INFO request can also contain other body parts that are > meaningful within the context of an invite dialog usage but are > not specifically associated with the INFO method and the > application concerned. MSD is not associated with the application concerned? MSD is not associated with the INFO method, even though the main reason we = send the INFO in order to deliver the MSD? >And also: > > A UA MAY include a message body that is not associated with an Info > Package in an INFO response. And also: "A UA MUST NOT include a message body associated with an Info Package in an INFO response. Message bodies associated with Info Packages MUST only be sent in INFO requests." Regards, Christer From nobody Fri Aug 19 15:09:26 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 5C75112D523 for ; Fri, 19 Aug 2016 15:09: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 EeGecFRJxgGp for ; Fri, 19 Aug 2016 15:09:23 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0B12D0B0 for ; Fri, 19 Aug 2016 15:09:22 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Aug 2016 15:09:22 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Fri, 19 Aug 2016 15:09:20 -0700 To: Paul Kyzivat , 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] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 22:09:25 -0000 Hi Paul, At 3:51 PM -0400 8/19/16, Paul Kyzivat wrote: > On 8/19/16 2:42 PM, Randall Gellens wrote: >> At 10:48 AM -0400 8/19/16, Paul Kyzivat wrote: >> >>> On 8/19/16 10:28 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>>>> Assume the PSAP sends a request for MSD to the UA. >>>>>> >>>>>> The UA sends the MSD back. >>>>>> >>>>>> Why does the UA needs to send ACK? The MSD will acknowledge the >>>>>> request, >>>>>> won1t it? >>>>>> >>>>>> I do understand that the UA needs something if it won1t send the >>>>>> MSD (or >>>>>> whatever data was requested), e.g. if there was something wrong >>>>>> with the >>>>>> request). But, if the UA does accept the request, and does send the >>>>>> data, I don1t see why the explicit ACK is needed. It will only add >>>>>> message size (and maybe even additional INFO messages). >>>>> >>>>> In one of the long ago original proposals, in response to the request, >>>>> there was either a NAK or the MSD. That would be potentially >>>>> ambiguous, >>>>> since MSD can also be sent unsolicited: after sending a request, if >>>>> you >>>>> received an MSD you wouldn't know if it was the one you requested, >>>>> or if >>>>> it was an unsolicited one and there might yet be a NAK to follow. The >>>>> ACK resolves the ambiguity. >>>> >>>> Not sure I understand. There must be some identifier that matches >>>> the MSD >>>> with the request - in the same way there must be some identifier that >>>> matches the ACK with the request. >>> >>> Yes. AFAIK there is nothing in the MSD itself that links it to the >>> request, so if the MSD is intended to implicitly acknowledge the >>> request then there needs to be *something* with it that links it to >>> the request. >> >> >> In the compromise proposal that I sent, the MSD was sent in its own >> INFO, along with a metadata/control object acknowledging the request. >> However, since RFC 6086 permits INFO responses to contain data that is >> not associated with the INFO package, and since per the compromise >> proposal the metadata/control object is associated with the INFO package >> but the MSD is not, then the IVS can send a requested MSD in the INFO >> response, which removes any ambiguity (and also saves an extra INFO >> message). In the car-crash draft, if the PSAP requests the vehicle to >> perform an action (e.g., flash the lights), then the IVS would send an >> INFO request to the PSAP containing a metadata/control object >> acknowledging the request and indicating if it was carried out. > > I am ok with sending the MSD as additional data on the INFO > response. But I don't think that should be taken as an affirmative > statement that the MSD is specifically in response to the request. I'm fine with that. As you said in a different response, the PSAP asks for an updated MSD, and gets an updated MSD. I'm not sure it matters if the MSD is specifically in response to the request or not. Especially given the context: we expect the PSAP to request an MSD only when the call taker thinks something may have changed, which we expect will be fairly uncommon. So, the call taker asks for an updated MSD, and the PSAP receives a new MSD and updates the display. The call taker doesn't care if the MSD was specifically in response to the request or not. > Doing that would tightly couple two mechanisms that should only be > loosely coupled. > > Consider the following following sequence of events: > > - caller is in a call with the PSAP > - caller prepares to send a reINVITE (for codec change, or > session timer, or whatever), but hasn't yet sent it. > It decides, independently, to include a fresh MSD in it. > - caller receives an INFO from PSAP, requesting an MSD. > > Now, what does the caller do? Potentially these are being processed > concurrently in different threads. Can the MSD in the INVITE > satisfy the request in the INFO? Does it matter whether it sends > the INVITE before or after the INFO response? I think that if the IVS receives a request for an MSD, it needs to respond with an MSD, even if it had just sent one. However, the IVS would have no reason to send an MSD except in the initial INVITE or after a request, so I don't think this situation would ever arise. --Randy >> >> >>> >>>>> But such issues depend heavily on the details. Minor tweaks might >>>>> resolve the ambiguity other ways. >>>>> >>>>> Since we are discussing various hypotheticals now, there aren't enough >>>>> details to know whether an ACK is needed. >>>> >>>> If you refer to the Call-Info discussion, I don1t think this has >>>> anything >>>> to do with that. This is not about how you transport the stuff in SIP. >>> >>> You could go with a philosophy where successful requests are never >>> acknowledged - only failed ones. I find such protocols to be fragile. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> 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: --------------- People that are really very weird can get into sensitive positions and have a tremendous impact on history. --then U.S. Vice President Dan Quayle From nobody Fri Aug 19 15:19: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 729E212D151 for ; Fri, 19 Aug 2016 15:19:06 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 DIeRqU5xeDXI for ; Fri, 19 Aug 2016 15:19:05 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 1126B128E19 for ; Fri, 19 Aug 2016 15:19:04 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-04v.sys.comcast.net with SMTP id as6rb5bAZ8Peaas7zb2RXp; Fri, 19 Aug 2016 22:19:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id as7zbi1Qh6coJas7zbHVor; Fri, 19 Aug 2016 22:19:04 +0000 To: Christer Holmberg , ECRIT References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> Date: Fri, 19 Aug 2016 18:19:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCrJj978ffZgXsRCbzu1/y3J1Y59+MVgtnCAtHXtqoHTBWIHcbmt8F3bO19TX3SwnQmS20rpD83b1OnK1ilPoWaQs1JwcYr+BahCI6N6QsBAnnKeUGeZ VFayQwuZDU+JRIdZXQgws5pdSjb2WJdAnhqy5DpcML9KPMBne8PT9D0YEZcShdmro697C5YyHlTJHVsYj7n232BibL3ulED238Qmm85DqlfEASsGANRFSTgj Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 22:19:06 -0000 On 8/19/16 4:55 PM, Christer Holmberg wrote: > Hi, > >>>>>> The discussion on ecall has become quite heated, with people dug in >>>>>> on all sides. Can we calm it down a bit? >>>>>> >>>>>> IMO a couple of different approaches have been described that would >>>>>> work and not violate any specs. The differences between these >>>>>> reflect differences of philosophy and taste. >>>>> >>>>> I donąt think we have an agreement on the >>>>> would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086. >>>>> >>>>> But, I do agree we need to try to figure out how to move forward. >>>> >>>> OK. Maybe we should start there. >>>> >>>> I guess there is some dispute on whether it is valid for an INFO >>>> message to contain a multipart body, where one part contains the info >>>> package >>>> (C-D: info-package) and another part (C-D: by-reference) is >>>> referenced by a cid: uri in some sip header field. >>>> >>>> In my mind there is no question that this is valid. Do you disagree, >>>> and if so, on what basis? >>> >>> The dispute is whether a message body must be associated with an Info >>> Package. >>> >>> In my view: >>> >>> - RFC 6086 allows bodies not associated with an Info Package in INFOs >>> in order to be backward compatible with existing pre-6086 INFO usages. >>> - Any NEW usage MUST be associated with an Info Package. Sending of >>> MSD is a new INFO usage. >> >> I disagree. I find the following in 6086: >> >> NOTE: An INFO request can also contain other body parts that are >> meaningful within the context of an invite dialog usage but are >> not specifically associated with the INFO method and the >> application concerned. > > So, you are saying that the MSD is not associated with the ecall application??? > > RFC 6086 also says: > > "Any new usage MUST use the Info Package mechanism defined in this > specification, since it does not share the issues associated with > legacy INFO usage, and since Info Packages can be registered with > IANA." > > And, in my opinion, sending of MSD *is* part of the new INFO usage. It's not something else that we add to the INFO. > > Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just by saying the content is not associated with the application... We did 6086 so that the usage if INFO to carry associated body parts could be negotiated. IMO if something is in the message, but not in the info-package body part, then it isn't specifically part of the INFO usage. For instance, any random header field that you happen to include isn't. >>> Some have said that there might even be new usages where information, >>> without being associated with an Info Package, is piggybacked in INFOs >>> sent for some other purpose. It can be discussed whether such usage is >>> 6068 compliant, but never the less: in my opinion MSD is not >>> "piggybacked information". The reason the INFO is sent to begin with >>> is to transport the requested MSD (and the ack to the request) - that >>> is not piggybacking in my opinion. >> >> That may be your concept of how the particular info package is defined. >> I think the people who disagree have a different concept. For purposes of evaluation these should be considered alternative proposals. > > Well, I have always assumed that we agreed that one of the main reason we send the INFO is to transport the MSD... Remember that *that* was in response to earlier proposals that didn't use INFO. And some people are having trouble with the way it ended up. So it isn't cast in stone. Brian's proposal that it be a request/response protocol that can trigger what would otherwise be an unsolicited MSD update is a plausible alternative. Thanks, Paul From nobody Fri Aug 19 15:36: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 78E1C12D0C2 for ; Fri, 19 Aug 2016 15:36:47 -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 pVTGGshO0lWh for ; Fri, 19 Aug 2016 15:36:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 39EFD12B076 for ; Fri, 19 Aug 2016 15:36:45 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-95-57b789fb2c33 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 69.D2.02493.BF987B75; Sat, 20 Aug 2016 00:36:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Sat, 20 Aug 2016 00:36:43 +0200 From: Christer Holmberg To: Paul Kyzivat , ECRIT Thread-Topic: Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///SIgCAAHCnoP///jkAgAAjmWA= Date: Fri, 19 Aug 2016 22:36:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> In-Reply-To: <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7se7vzu3hBm+3qFs0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjXH8Dc8EalYrP2y8wNjBekuli5OSQEDCR OP7uKFsXIxeHkMB6RomOLw+YIJwljBJdk7cydzFycLAJWEh0/9MGaRARcJCY3byLFcQWFlCQ +Lx/KSNEXFFi2oT5bBC2n8SeH6eYQWwWAVWJjb032EHG8Ar4SrQ+qYEY384scf/DJbB6TqCZ 5/ZtBpvJKCAm8f3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSSx9vB2Foh6PYkb U6ewQdjaEssWvgar5xUQlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUW ZSYXF+fn6eWllmxiBMbDwS2/rXYwHnzueIhRgINRiYdXwXN7uBBrYllxZe4hRgkOZiURXr8O oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQZGEYNYs6gz 6nz33nHOeiOzzOiUwNc7BRPDfLZUuEx6/eDRjk/r/3y5fsbhK+srZXWnO92FKz9Uyf87sUth q3jedI5NacsrtFffi5hnP5WtucKqZfX3Pe+k2T7Pk5DQyn3z7ux3wcLcpdvvhU1wLTi1iPvO /i+br3zc8e+VgfPHu60N/6qj9ea/ZFBiKc5INNRiLipOBAClcIJqgwIAAA== Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 22:36:47 -0000 Hi, >>>>>>> The discussion on ecall has become quite heated, with people dug=20 >>>>>>> in on all sides. Can we calm it down a bit? >>>>>>> >>>>>>> IMO a couple of different approaches have been described that=20 >>>>>>> would work and not violate any specs. The differences between=20 >>>>>>> these reflect differences of philosophy and taste. >>>>>> >>>>>> I don=B9t think we have an agreement on the=20 >>>>>> would-not-violate-any-specs part. We clearly have different views on= what is allowed by RFC 6086. >>>>>> >>>>>> But, I do agree we need to try to figure out how to move forward. >>>>> >>>>> OK. Maybe we should start there. >>>>> >>>>> I guess there is some dispute on whether it is valid for an INFO=20 >>>>> message to contain a multipart body, where one part contains the=20 >>>>> info package >>>>> (C-D: info-package) and another part (C-D: by-reference) is=20 >>>>> referenced by a cid: uri in some sip header field. >>>>> >>>>> In my mind there is no question that this is valid. Do you=20 >>>>> disagree, and if so, on what basis? >>>> >>>> The dispute is whether a message body must be associated with an=20 >>>> Info Package. >>>> >>>> In my view: >>>> >>>> - RFC 6086 allows bodies not associated with an Info Package in=20 >>>> INFOs in order to be backward compatible with existing pre-6086 INFO u= sages. >>>> - Any NEW usage MUST be associated with an Info Package. Sending of=20 >>>> MSD is a new INFO usage. >>> >>> I disagree. I find the following in 6086: >>> >>> NOTE: An INFO request can also contain other body parts that are >>> meaningful within the context of an invite dialog usage but are >>> not specifically associated with the INFO method and the >>> application concerned. >> >> So, you are saying that the MSD is not associated with the ecall applica= tion??? >> >> RFC 6086 also says: >> >> "Any new usage MUST use the Info Package mechanism defined in this >> specification, since it does not share the issues associated wit= h >> legacy INFO usage, and since Info Packages can be registered wit= h >> IANA." >> >> And, in my opinion, sending of MSD *is* part of the new INFO usage. It's= not something else that we add to the INFO. >> >> Otherwise, why did we do RFC 6086 in the first place? We can just allow = people to use - and standardize such usage - as in the past, with all the p= roblems associated, just >> by saying the content is not associated with th= e application... > > We did 6086 so that the usage if INFO to carry associated body parts coul= d be negotiated. You don't need 6086 to indicate what body parts you support. There is a SIP= header field for that. We defined 6086 so that you could define and indicate the semantics associa= ted with the INFO request (including body parts), and to negotiate support = of processing that semantics. >IMO if something is in the message, but not in the info-package body part,= then it isn't specifically part=20 >of the INFO usage. For instance, any random header field that you happen t= o include isn't. MSD is not "something random that you happen to include" in an INFO associa= ted with the ecall application. Or, again, are you saying that MSD is not associated with the ecall applica= tion? >>>> Some have said that there might even be new usages where=20 >>>> information, without being associated with an Info Package, is=20 >>>> piggybacked in INFOs sent for some other purpose. It can be=20 >>>> discussed whether such usage is >>>> 6068 compliant, but never the less: in my opinion MSD is not=20 >>>> "piggybacked information". The reason the INFO is sent to begin with=20 >>>> is to transport the requested MSD (and the ack to the request) -=20 >>>> that is not piggybacking in my opinion. >>> >>> That may be your concept of how the particular info package is defined. >>> I think the people who disagree have a different concept. For purposes = of evaluation these should be considered alternative proposals. >> >> Well, I have always assumed that we agreed that one of the main reason w= e send the INFO is to transport the MSD... > > Remember that *that* was in response to earlier proposals that didn't use= INFO. And some people are having trouble with the way it ended up.=20 > So it isn't cast in stone. > > Brian's proposal that it be a request/response protocol that can trigger = what would otherwise be an unsolicited MSD update is a plausible alternativ= e. My proposal is to send the MSD as part of an Info Package. Regards, Christer From nobody Fri Aug 19 15:44:47 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 77FD512D0B6 for ; Fri, 19 Aug 2016 15:44:46 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 E9sAqMyA25oa for ; Fri, 19 Aug 2016 15:44:45 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 6292912B05D for ; Fri, 19 Aug 2016 15:44:45 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-09v.sys.comcast.net with SMTP id asWib8vuF1XXBasWqb4Vrq; Fri, 19 Aug 2016 22:44:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with SMTP id asWpbWV8dnqiCasWpbLd8N; Fri, 19 Aug 2016 22:44:44 +0000 To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 18:44:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCor7mR4sP8U1gca6l9pt6oYsO+jRBOhcqAspiEyURiexyZQljAOJZLQXUG9s5v1iMJAo/iLDUiGVt9zGlSoxef1GoNPvG0wrFGR9lKxhzus5vgbnDqh fQivMjU4IZWLUjtfzFotJyyiqsWnuOlO185+BEYHAi31iACm7u68Qbl3UgCXNQCQcT0RrIMZrSldl00IpHynwoctttNp65sFBDc30kYURWdcwhuwdvrkZHQb 7eYkOm0A7kwhYsLJubWhe1tFw0B0ocG81wPl3Wpnaz0= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 22:44:46 -0000 On 8/19/16 6:09 PM, Randall Gellens wrote: > I think that if the IVS receives a request for an MSD, it needs to > respond with an MSD, even if it had just sent one. However, the IVS > would have no reason to send an MSD except in the initial INVITE or > after a request, so I don't think this situation would ever arise. ISTM that the IVS *could* realize that something has changed, and spontaneously send a new MSD. (E.g., sometime after the crash perhaps the car catches fire, or starts moving because it is sliding down an embankment.) (I don't know what is *in* an MSD, since that seems to be defined in EN 15722, and that apparently isn't freely available. Maybe there is nothing in it that *could* change. But then this whole discussion is moot.) Thanks, Paul From nobody Fri Aug 19 15:53: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 1718A127058 for ; Fri, 19 Aug 2016 15:53:06 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 8KQCT-iQjeXV for ; Fri, 19 Aug 2016 15:53:05 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 0FBD112D0B6 for ; Fri, 19 Aug 2016 15:53:04 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-04v.sys.comcast.net with SMTP id aserbcKjdGkXBasetb11CG; Fri, 19 Aug 2016 22:53:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-10v.sys.comcast.net with SMTP id asesbUIsN7mi5asetbszdF; Fri, 19 Aug 2016 22:53:03 +0000 To: Christer Holmberg , ECRIT References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 19 Aug 2016 18:53:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFe1EjGYdc8Rs2qiomI5Rw5mx+CsCgbhLVHcyLJx/Gp+cv5GrBlQXKN8ElH8XTjXlKFlxHmTJ23+M1w1kSovFq1KcSM+0n2ELCz6BDTi5bKs5hj6J7ap KKbyfTK0Tec7M/V1j22dB+R7XhThi2jDSG2ZJCPBrteO/QuMTOpiVbMgYj0IV+pLsDrASsmTgbr6cDm5DapRlMIPuTD8Muln6muN0PFIAYkdkEkARPb8yu3Y Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 22:53:06 -0000 On 8/19/16 6:36 PM, Christer Holmberg wrote: > Hi, > >>>>>>>> The discussion on ecall has become quite heated, with people dug >>>>>>>> in on all sides. Can we calm it down a bit? >>>>>>>> >>>>>>>> IMO a couple of different approaches have been described that >>>>>>>> would work and not violate any specs. The differences between >>>>>>>> these reflect differences of philosophy and taste. >>>>>>> >>>>>>> I donąt think we have an agreement on the >>>>>>> would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086. >>>>>>> >>>>>>> But, I do agree we need to try to figure out how to move forward. >>>>>> >>>>>> OK. Maybe we should start there. >>>>>> >>>>>> I guess there is some dispute on whether it is valid for an INFO >>>>>> message to contain a multipart body, where one part contains the >>>>>> info package >>>>>> (C-D: info-package) and another part (C-D: by-reference) is >>>>>> referenced by a cid: uri in some sip header field. >>>>>> >>>>>> In my mind there is no question that this is valid. Do you >>>>>> disagree, and if so, on what basis? >>>>> >>>>> The dispute is whether a message body must be associated with an >>>>> Info Package. >>>>> >>>>> In my view: >>>>> >>>>> - RFC 6086 allows bodies not associated with an Info Package in >>>>> INFOs in order to be backward compatible with existing pre-6086 INFO usages. >>>>> - Any NEW usage MUST be associated with an Info Package. Sending of >>>>> MSD is a new INFO usage. >>>> >>>> I disagree. I find the following in 6086: >>>> >>>> NOTE: An INFO request can also contain other body parts that are >>>> meaningful within the context of an invite dialog usage but are >>>> not specifically associated with the INFO method and the >>>> application concerned. >>> >>> So, you are saying that the MSD is not associated with the ecall application??? >>> >>> RFC 6086 also says: >>> >>> "Any new usage MUST use the Info Package mechanism defined in this >>> specification, since it does not share the issues associated with >>> legacy INFO usage, and since Info Packages can be registered with >>> IANA." >>> >>> And, in my opinion, sending of MSD *is* part of the new INFO usage. It's not something else that we add to the INFO. >>> >>> Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just >> by saying the content is not associated with the application... >> >> We did 6086 so that the usage if INFO to carry associated body parts could be negotiated. > > You don't need 6086 to indicate what body parts you support. There is a SIP header field for that. > > We defined 6086 so that you could define and indicate the semantics associated with the INFO request (including body parts), and to negotiate support of processing that semantics. > >> IMO if something is in the message, but not in the info-package body part, then it isn't specifically part >> of the INFO usage. For instance, any random header field that you happen to include isn't. > > MSD is not "something random that you happen to include" in an INFO associated with the ecall application. > > Or, again, are you saying that MSD is not associated with the ecall application? I"m saying that I don't know anything about an ecall *application*. I agree there might be one, but we aren't defining that. I do know the MSD is associated with a call-info header field. I can potentially put that call-info in any message I like (that permits call-info). If there happens to be an ecall application, then the MSD might indeed end up at that application. I would expect that the application will be *loosely* coupled to the sip session. Lots of other things may happen in that session that may or may not be anticipated by the application. Those things may be processed by other UA application software. So the ecall application is just one *user* of the sip session. Of course the application environment may constrain the possibilities in some way. But I think that is outside of our scope here. Thanks, Paul From nobody Fri Aug 19 15:57:36 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 0602312D0E3 for ; Fri, 19 Aug 2016 15:57:36 -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 FoVAtnJ18-N7 for ; Fri, 19 Aug 2016 15:57:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B542712B02D for ; Fri, 19 Aug 2016 15:57:33 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-ae-57b78edb4449 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 92.D7.06563.BDE87B75; Sat, 20 Aug 2016 00:57:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Sat, 20 Aug 2016 00:57:31 +0200 From: Christer Holmberg To: Paul Kyzivat , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9U= Date: Fri, 19 Aug 2016 22:57:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> , 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_7594FB04B1934943A5C02806D1A2204B4BC27A8CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdSfd23/Zwg6W7LSwaFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4MlbN7WYt2KRRsWPfdZYG xmlKXYycHBICJhKfvlxl62Lk4hASWM8ocezcR0YIZwmjxIQVX9i7GDk42AQsJLr/aYOYIgJV Eh2n6kF6hQXcJTbMns8OYosIeEjs2HwTyk6SuDxjAzNIOYuAqkTjSV8Qk1fAV2LCKQGQCiGB qcwSr3oDQGxOAQeJey/es4HYjAJiEt9PrWECsZkFxCWavqxkhbhSQGLJnvPMELaoxMvH/1gh avIlzv1+CVbPKyAocXLmE5YJjEKzkLTPQlI2C0kZRNxA4sv721C2tsSyha+ZIWx9ie73p5mQ xRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyag1t+6+5gXP3a8RCjAAejEg+vguf2 cCHWxLLiytxDjBIczEoivCy9QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNT UwtSi2CyTBycUg2Mc1rv8NrNM9j9avLNRQFCExTnrnkbsyvOW9glWyjvpsDPt7ZBl56ctpmg tPP17TtHH188Fyqs41zXVmDz7M7zQlauBdsnWoTPulgu8/a3KGPBesGH4VdrKrkMzrHq/GDS KmPXczLT0P3ultN2fY7T0sv5Pyfvlq2axeaVUar0b+KBCJfYuUWZSizFGYmGWsxFxYkAPSW2 gpYCAAA= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 19 Aug 2016 22:57:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC27A8CESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, This is not about MSD. It's about the request protocol (which I assume in f= uture might also be used in other applications than ecall), and whether a r= equest shall be explicitly acknowledged or not - and how. And, as I've said before, there needs to be guidance on how long the reques= ter should wait for the requested data, before it considers the request a f= ailure. Regards, Christer Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD20/=FD08/=FD2016 01:44 To: Randall Gellens; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? On 8/19/16 6:09 PM, Randall Gellens wrote: > I think that if the IVS receives a request for an MSD, it needs to > respond with an MSD, even if it had just sent one. However, the IVS > would have no reason to send an MSD except in the initial INVITE or > after a request, so I don't think this situation would ever arise. ISTM that the IVS *could* realize that something has changed, and spontaneously send a new MSD. (E.g., sometime after the crash perhaps the car catches fire, or starts moving because it is sliding down an embankment.) (I don't know what is *in* an MSD, since that seems to be defined in EN 15722, and that apparently isn't freely available. Maybe there is nothing in it that *could* change. But then this whole discussion is moot.) Thanks, Paul --_000_7594FB04B1934943A5C02806D1A2204B4BC27A8CESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

This is not about MSD. It's about the request protocol (which I assume in f= uture might also be used in other applications than ecall), and whether a r= equest shall be explicitly acknowledged or not - and how.

And, as I've said before, there needs to be guidance on how long the reques= ter should wait for the requested data, before it considers the request a f= ailure.

Regards,

Christer


Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD20= /=FD08/=FD2016 01:44
To: Randall Gellens; Christer Holmberg; ecrit@ietf.org
Subject: Re: [= Ecrit] ecall: Why do we need ACK for successful requests?

On 8/19/16 6:09 PM, Randall Gellens wrote:

> I think that if the IVS receives a request for an MSD, it needs to
> respond with an MSD, even if it had just sent one.  However, the = IVS
> would have no reason to send an MSD except in the initial INVITE or > after a request, so I don't think this situation would ever arise.

ISTM that the IVS *could* realize that something has changed, and
spontaneously send a new MSD. (E.g., sometime after the crash perhaps
the car catches fire, or starts moving because it is sliding down an
embankment.)

(I don't know what is *in* an MSD, since that seems to be defined in EN 15722, and that apparently isn't freely available. Maybe there is
nothing in it that *could* change. But then this whole discussion is moot.)=

        Thanks,
        Paul

 --_000_7594FB04B1934943A5C02806D1A2204B4BC27A8CESESSMB209erics_-- From nobody Fri Aug 19 16:02: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 DC8BA12B056 for ; Fri, 19 Aug 2016 16:02: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 vaE7lfom3Blm for ; Fri, 19 Aug 2016 16:02:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 78B2312B014 for ; Fri, 19 Aug 2016 16:02:24 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-a3-57b78ffd88d6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id B3.A4.02493.DFF87B75; Sat, 20 Aug 2016 01:02:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Sat, 20 Aug 2016 01:02:21 +0200 From: Christer Holmberg To: Paul Kyzivat , ECRIT Thread-Topic: Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///SIgCAAHCnoP///jkAgAAjmWD//+XlgAAEhG11 Date: Fri, 19 Aug 2016 23:02:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC27B20@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@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_7594FB04B1934943A5C02806D1A2204B4BC27B20ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7ru6//u3hBnMeClo0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj75l2wbOMiq9zLrI2MK4I72Lk5JAQMJF4 suokYxcjF4eQwHpGiUuf3zKCJIQEljBKfNoi1sXIwcEmYCHR/U8bJCwi4CAxu3kXK4gtLKAg 8Xn/UkaIuKLEtAnz2SDsKIk7r/cxg9gsAqoSC1f+ZwEZwyvgKzHnfzDEqv/MEm+WvAabwwk0 c/78PywgNqOAmMT3U2uYQGxmAXGJpi8rWSHuFJBYsuc8M4QtKvHy8T9WiJp8ia2bD7OD2LwC ghInZz5hmcAoNAtJ+ywkZbOQlEHEDSS+vL8NZWtLLFv4mhnC1pfofn+aCVl8ASP7KkbR4tTi 4tx0IyO91KLM5OLi/Dy9vNSSTYzAGDm45bfVDsaDzx0PMQpwMCrx8Cp4bg8XYk0sK67MPcQo wcGsJMLL0gsU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnV wGg1a+o3k49HijZzR3y5sO2VrX3Td/e47YHpkssPzD5ZUThVIzBlP6fEc/OlRwp+bueyMm7z vKW7dc/aT2vf7J/26n6mngDvmnwJ3s3HNR9p/9zbF6M31VvoaoLJR4siYb58869eZ0PL/H2Y mdX3Nu5r32c564C09bWVu5cnvBD97c01PV2o306JpTgj0VCLuag4EQDnMGF5jQIAAA== Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 19 Aug 2016 23:02:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC27B20ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable "if there is an ecall application" We are defining a mechanism to be used by the ecall service, application or= whatever you want to call it. If you indicate support for the ecall info p= ackage, it means you support the application logic associated with that. If= you want to send MSD outside the ecall application, fine, but we are defin= ing ecall. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD20/=FD08/=FD2016 01:53 To: Christer Holmberg; ECRIT Subject: Re: Multipart with INFO On 8/19/16 6:36 PM, Christer Holmberg wrote: > Hi, > >>>>>>>> The discussion on ecall has become quite heated, with people dug >>>>>>>> in on all sides. Can we calm it down a bit? >>>>>>>> >>>>>>>> IMO a couple of different approaches have been described that >>>>>>>> would work and not violate any specs. The differences between >>>>>>>> these reflect differences of philosophy and taste. >>>>>>> >>>>>>> I don=B9t think we have an agreement on the >>>>>>> would-not-violate-any-specs part. We clearly have different views o= n what is allowed by RFC 6086. >>>>>>> >>>>>>> But, I do agree we need to try to figure out how to move forward. >>>>>> >>>>>> OK. Maybe we should start there. >>>>>> >>>>>> I guess there is some dispute on whether it is valid for an INFO >>>>>> message to contain a multipart body, where one part contains the >>>>>> info package >>>>>> (C-D: info-package) and another part (C-D: by-reference) is >>>>>> referenced by a cid: uri in some sip header field. >>>>>> >>>>>> In my mind there is no question that this is valid. Do you >>>>>> disagree, and if so, on what basis? >>>>> >>>>> The dispute is whether a message body must be associated with an >>>>> Info Package. >>>>> >>>>> In my view: >>>>> >>>>> - RFC 6086 allows bodies not associated with an Info Package in >>>>> INFOs in order to be backward compatible with existing pre-6086 INFO = usages. >>>>> - Any NEW usage MUST be associated with an Info Package. Sending of >>>>> MSD is a new INFO usage. >>>> >>>> I disagree. I find the following in 6086: >>>> >>>> NOTE: An INFO request can also contain other body parts that are >>>> meaningful within the context of an invite dialog usage but are >>>> not specifically associated with the INFO method and the >>>> application concerned. >>> >>> So, you are saying that the MSD is not associated with the ecall applic= ation??? >>> >>> RFC 6086 also says: >>> >>> "Any new usage MUST use the Info Package mechanism defined in this >>> specification, since it does not share the issues associat= ed with >>> legacy INFO usage, and since Info Packages can be register= ed with >>> IANA." >>> >>> And, in my opinion, sending of MSD *is* part of the new INFO usage. It'= s not something else that we add to the INFO. >>> >>> Otherwise, why did we do RFC 6086 in the first place? We can just allow= people to use - and standardize such usage - as in the past, with all the = problems associated, just >> by saying the content is not associated with t= he application... >> >> We did 6086 so that the usage if INFO to carry associated body parts cou= ld be negotiated. > > You don't need 6086 to indicate what body parts you support. There is a S= IP header field for that. > > We defined 6086 so that you could define and indicate the semantics assoc= iated with the INFO request (including body parts), and to negotiate suppor= t of processing that semantics. > >> IMO if something is in the message, but not in the info-package body par= t, then it isn't specifically part >> of the INFO usage. For instance, any random header field that you happen= to include isn't. > > MSD is not "something random that you happen to include" in an INFO assoc= iated with the ecall application. > > Or, again, are you saying that MSD is not associated with the ecall appli= cation? I"m saying that I don't know anything about an ecall *application*. I agree there might be one, but we aren't defining that. I do know the MSD is associated with a call-info header field. I can potentially put that call-info in any message I like (that permits call-info). If there happens to be an ecall application, then the MSD might indeed end up at that application. I would expect that the application will be *loosely* coupled to the sip session. Lots of other things may happen in that session that may or may not be anticipated by the application. Those things may be processed by other UA application software. So the ecall application is just one *user* of the sip session. Of course the application environment may constrain the possibilities in some way. But I think that is outside of our scope here. Thanks, Paul --_000_7594FB04B1934943A5C02806D1A2204B4BC27B20ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
"if ther= e is an ecall application"

We are defining a mechanism to be used by the ecall service, application or= whatever you want to call it. If you indicate support for the ecall info p= ackage, it means you support the application logic associated with that. If= you want to send MSD outside the ecall application, fine, but we are defining ecall.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD20= /=FD08/=FD2016 01:53
To: Christer Holmberg; ECRIT
Subject: Re: M= ultipart with INFO

On 8/19/16 6:36 PM, Christer Holmberg wrote:
> Hi,
>
>>>>>>>> The discussion on ecall has become quite h= eated, with people dug
>>>>>>>> in on all sides. Can we calm it down a bit= ?
>>>>>>>>
>>>>>>>> IMO a couple of different approaches have = been described that
>>>>>>>> would work and not violate any specs. The = differences between
>>>>>>>> these reflect differences of philosophy an= d taste.
>>>>>>>
>>>>>>> I don=B9t think we have an agreement on the >>>>>>> would-not-violate-any-specs part. We clearly h= ave different views on what is allowed by RFC 6086.
>>>>>>>
>>>>>>> But, I do agree we need to try to figure out h= ow to move forward.
>>>>>>
>>>>>> OK. Maybe we should start there.
>>>>>>
>>>>>> I guess there is some dispute on whether it is val= id for an INFO
>>>>>> message to contain a multipart body, where one par= t contains the
>>>>>> info package
>>>>>> (C-D: info-package) and another part (C-D: by-refe= rence) is
>>>>>> referenced by a cid: uri in some sip header field.=
>>>>>>
>>>>>> In my mind there is no question that this is valid= . Do you
>>>>>> disagree, and if so, on what basis?
>>>>>
>>>>> The dispute is whether a message body must be associat= ed with an
>>>>> Info Package.
>>>>>
>>>>> In my view:
>>>>>
>>>>> - RFC 6086 allows bodies not associated with an Info P= ackage in
>>>>> INFOs in order to be backward compatible with existing= pre-6086 INFO usages.
>>>>> - Any NEW usage MUST be associated with an Info Packag= e. Sending of
>>>>> MSD is a new INFO usage.
>>>>
>>>> I disagree. I find the following in 6086:
>>>>
>>>>       NOTE: An INFO request = can also contain other body parts that are
>>>>       meaningful within the = context of an invite dialog usage but are
>>>>       not specifically assoc= iated with the INFO method and the
>>>>       application concerned.=
>>>
>>> So, you are saying that the MSD is not associated with the eca= ll application???
>>>
>>> RFC 6086 also says:
>>>
>>>      "Any new usage MUST use the= Info Package mechanism defined in this
>>>          &nb= sp;   specification, since it does not share the issues associate= d with
>>>          &nb= sp;   legacy INFO usage, and since Info Packages can be registere= d with
>>>          &nb= sp;   IANA."
>>>
>>> And, in my opinion, sending of MSD *is* part of the new INFO u= sage. It's not something else that we add to the INFO.
>>>
>>> Otherwise, why did we do RFC 6086 in the first place? We can j= ust allow people to use - and standardize such usage - as in the past, with= all the problems associated, just >> by saying the content is not as= sociated with the application...
>>
>> We did 6086 so that the usage if INFO to carry associated body par= ts could be negotiated.
>
> You don't need 6086 to indicate what body parts you support. There is = a SIP header field for that.
>
> We defined 6086 so that you could define and indicate the semantics as= sociated with the INFO request (including body parts), and to negotiate sup= port of processing that semantics.
>
>> IMO if something is in the message, but not in the info-package bo= dy part, then it isn't specifically part
>> of the INFO usage. For instance, any random header field that you = happen to include isn't.
>
> MSD is not "something random that you happen to include" in = an INFO associated with the ecall application.
>
> Or, again, are you saying that MSD is not associated with the ecall ap= plication?

I"m saying that I don't know anything about an ecall *application*. I =
agree there might be one, but we aren't defining that. I do know the MSD is associated with a call-info header field. I can potentially put that call-info in any message I like (that permits call-info).

If there happens to be an ecall application, then the MSD might indeed
end up at that application. I would expect that the application will be *loosely* coupled to the sip session. Lots of other things may happen in that session that may or may not be anticipated by the application.
Those things may be processed by other UA application software. So the
ecall application is just one *user* of the sip session.

Of course the application environment may constrain the possibilities in some way. But I think that is outside of our scope here.

        Thanks,
        Paul

 --_000_7594FB04B1934943A5C02806D1A2204B4BC27B20ESESSMB209erics_-- From nobody Fri Aug 19 21:15:02 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 85E0E12D593 for ; Fri, 19 Aug 2016 21:15: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.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 HwsK_a8fO7JU for ; Fri, 19 Aug 2016 21:15:00 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E2B3712D114 for ; Fri, 19 Aug 2016 21:14:59 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Aug 2016 21:14:59 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Fri, 19 Aug 2016 21:14:25 -0700 To: Paul Kyzivat , 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] ecall: Why do we need ACK for successful requests? 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, 20 Aug 2016 04:15:01 -0000 At 6:44 PM -0400 8/19/16, Paul Kyzivat wrote: > On 8/19/16 6:09 PM, Randall Gellens wrote: > >> I think that if the IVS receives a request for an MSD, it needs to >> respond with an MSD, even if it had just sent one. However, the IVS >> would have no reason to send an MSD except in the initial INVITE or >> after a request, so I don't think this situation would ever arise. > > ISTM that the IVS *could* realize that something has changed, and > spontaneously send a new MSD. (E.g., sometime after the crash > perhaps the car catches fire, or starts moving because it is > sliding down an embankment.) > > (I don't know what is *in* an MSD, since that seems to be defined > in EN 15722, and that apparently isn't freely available. Maybe > there is nothing in it that *could* change. But then this whole > discussion is moot.) The MSD contains information about the vehicle's state and position, including some information about the occupants, so it's possible that the data could change (e.g., if the vehicle moves or occupants that were in the vehicle aren't). That's the reason for the mid-call update request: to allow the PSAP to request an updated MSD if the call taker thinks something might have changed. My point was simply that, based on current eCall requirements, there's nothing that says that the vehicle should send an updated MSD on its own, so I doubt that any IVS implementations would do so. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Collaboration: A literary partnership based on the false assumption that the other fellow can spell. From nobody Mon Aug 22 08:30: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 A1A2A12D60F for ; Mon, 22 Aug 2016 08:30:31 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 qCMJ0H3s05dA for ; Mon, 22 Aug 2016 08:30:30 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 A408912B037 for ; Mon, 22 Aug 2016 08:30:30 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-09v.sys.comcast.net with SMTP id brAmbCP9u1XXBbrBGbAj2z; Mon, 22 Aug 2016 15:30:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with SMTP id brBFbaLLTPpCzbrBFbIWfj; Mon, 22 Aug 2016 15:30:29 +0000 To: Christer Holmberg , Randall Gellens , "ecrit@ietf.org" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> Date: Mon, 22 Aug 2016 11:30:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEKzuPhnWgS/QWXVj9WNhNwaMiHpxUrYbOxVbef9BPN4YMGkh8umIrPANU0P5NDWpmlMdoXmqE8m1b4wi++dRZ2uUTqowRZHT8ryOsdPL/jEqlf92+AL Dck9XEEnKP2TXGzQ6+uu5usR6RaGHgsToZXufq2voBjF3r2F0cIZfUlheodEzIxYsYb8uUFDqIk1KIJ+W5OlkbHNv31V8TraLwAmjngnoyQaXuQe4IC+6wvv OOJtDh4W5u5Fby/sVfAJ5bDfw9dyeXuFDDGYQh3LavU= Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 15:30:31 -0000 On 8/19/16 6:57 PM, Christer Holmberg wrote: > Hi, > > This is not about MSD. It's about the request protocol (which I assume > in future might also be used in other applications than ecall), and > whether a request shall be explicitly acknowledged or not - and how. That is a fair question. The response to the INFO acknowledges that it was received. But that is only at the signaling level. It doesn't confirm that the content was processed and understood. And explicit ACK (in its own INFO) is a way to achieve that for an explicit request/response protocol. Of course that ACK need not be in an INFO. It could be something else, as long as it is well defined by the protocol, and unambiguously linked to the request. I don't think an MSD conveyed in additional-data can be unambiguously linked to the request, distinguishing it from an MSD that that was send unsolicited but just happens to arrive. If the goal is to optimize messages, then I could see embedding an MSD in an explicit ACK. (In an info-package body.) That would be an *alternative* to sending an MSD as additional-data. But that doesn't really save much (a few bytes) over sending a simpler ACK and piggybacking an MSD in additional-data in the same message. Thanks, Paul > And, as I've said before, there needs to be guidance on how long the > requester should wait for the requested data, before it considers the > request a failure. > > Regards, > > Christer > > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ý20/ý08/ý2016 01:44 > To: Randall Gellens ; Christer > Holmberg ; ecrit@ietf.org > > Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > > On 8/19/16 6:09 PM, Randall Gellens wrote: > >> I think that if the IVS receives a request for an MSD, it needs to >> respond with an MSD, even if it had just sent one. However, the IVS >> would have no reason to send an MSD except in the initial INVITE or >> after a request, so I don't think this situation would ever arise. > > ISTM that the IVS *could* realize that something has changed, and > spontaneously send a new MSD. (E.g., sometime after the crash perhaps > the car catches fire, or starts moving because it is sliding down an > embankment.) > > (I don't know what is *in* an MSD, since that seems to be defined in EN > 15722, and that apparently isn't freely available. Maybe there is > nothing in it that *could* change. But then this whole discussion is moot.) > > Thanks, > Paul > From nobody Mon Aug 22 11:20: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 192E312B02F for ; Mon, 22 Aug 2016 11:20: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 pA9yLtbw-doY for ; Mon, 22 Aug 2016 11:20:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1B7E912D54F for ; Mon, 22 Aug 2016 11:20:19 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-e6-57bb42623d04 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id D6.E2.06563.2624BB75; Mon, 22 Aug 2016 20:20:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 20:20:17 +0200 From: Christer Holmberg To: Paul Kyzivat , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA Date: Mon, 22 Aug 2016 18:20:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> In-Reply-To: <046d9c00-b1c5-4c02-e03b-ff250a0615dc@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.148] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7gW6S0+5wg7lrRSwaFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mp72zGYq+ChRsWrKB/YG xpvCXYwcHBICJhJfvqt1MXJxCAmsZ5TY/mw3K4SzhFHi2dW/TCBFbAIWEt3/tEFMEYEqiY5T 9V2MnBzCAu4SG2bPZwexRQQ8JHZsvgll50k82b4fzGYRUJVYMeECmM0r4Ctxe81CFojxE1kk Vp9YzwiS4BRwkFh48zUTiM0oICbx/dQaMJtZQFzi1pP5YLaEgIDEkj3nmSFsUYmXj/+xQthK Eo1LnrBC1BtInNu+kR3C1pZYtvA1M8RiQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVo2hx anFxbrqRsV5qUWZycXF+nl5easkmRmCEHNzyW3cH4+rXjocYBTgYlXh4F9juDhdiTSwrrsw9 xCjBwawkwvvBHijEm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomD U6qBMUfji9+cqlm7Fq/ctpXBYFYoI0flzbw9pvd8rn5iVdkxp+PSwd2b6qv/bbwTuTztweG9 GncXWwttKdqpcsh11RSNE1ciQx9M67/PbeCXwJNxMfHMkoKcFmELc+EeodOen/WSuevEc5zn 1X2ZJfPqyN+YY89vpG7ibnvnozvZSflLevQkntDKo0osxRmJhlrMRcWJAFWIb0OMAgAA Archived-At: Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 18:20:23 -0000 Hi, >> This is not about MSD. It's about the request protocol (which I assume=20 >> in future might also be used in other applications than ecall), and=20 >> whether a request shall be explicitly acknowledged or not - and how. > > That is a fair question. > > The response to the INFO acknowledges that it was received. But that is o= nly at the signaling level. It doesn't confirm that the content was process= ed and understood. Agree. > And explicit ACK (in its own INFO) is a way to achieve that for an explic= it request/response protocol. Agree. > Of course that ACK need not be in an INFO. It could be something else, as= long as it is well defined by the protocol, and unambiguously linked to th= e request. Yes. > I don't think an MSD conveyed in additional-data can be unambiguously lin= ked to the request, distinguishing it from an MSD that that=20 > was send unsolicited but just happens to arrive. > > If the goal is to optimize messages, then I could see embedding an MSD in= an explicit ACK. (In an info-package body.) That would be an > *alternative* to sending an MSD as additional-data. But that doesn't real= ly save much (a few bytes) over sending a simpler ACK and=20 > piggybacking an MSD in additional-data in the same message. Well, we don't have an agreement on how to transport the MSD. I was hoping = that we could decide in general whether an ACK is needed or not. In addition, even if an ACK is sent, the next question is whether there mus= t be *A* indicator mapping the content (e.g. MSD) to the corresponding requ= est.=20 Regards, Christer > And, as I've said before, there needs to be guidance on how long the=20 > requester should wait for the requested data, before it considers the=20 > request a failure. > > Regards, > > Christer > > > Regards, > > Christer > > Sent from my Windows Phone > ---------------------------------------------------------------------- > -- > From: Paul Kyzivat > Sent: =FD20/=FD08/=FD2016 01:44 > To: Randall Gellens ; Christer=20 > Holmberg ; ecrit@ietf.org=20 > > Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > > On 8/19/16 6:09 PM, Randall Gellens wrote: > >> I think that if the IVS receives a request for an MSD, it needs to=20 >> respond with an MSD, even if it had just sent one. However, the IVS=20 >> would have no reason to send an MSD except in the initial INVITE or=20 >> after a request, so I don't think this situation would ever arise. > > ISTM that the IVS *could* realize that something has changed, and=20 > spontaneously send a new MSD. (E.g., sometime after the crash perhaps=20 > the car catches fire, or starts moving because it is sliding down an > embankment.) > > (I don't know what is *in* an MSD, since that seems to be defined in=20 > EN 15722, and that apparently isn't freely available. Maybe there is=20 > nothing in it that *could* change. But then this whole discussion is=20 > moot.) > > Thanks, > Paul > From nobody Mon Aug 22 11:57:02 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 C405512D112 for ; Mon, 22 Aug 2016 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 f5CBztSqSs92 for ; Mon, 22 Aug 2016 11:57:00 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6212D0CD for ; Mon, 22 Aug 2016 11:57:00 -0700 (PDT) Received: from [10.0.1.92] (127.0.0.1) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 22 Aug 2016 11:56:59 -0700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: "Randall Gellens (IETF)" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> Date: Mon, 22 Aug 2016 11:53:58 -0700 Message-Id: <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: iPad Mail (13F69) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 18:57:02 -0000 Sent from my iPad > On Aug 22, 2016, at 11:20 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> This is not about MSD. It's about the request protocol (which I assume=20= >>> in future might also be used in other applications than ecall), and=20 >>> whether a request shall be explicitly acknowledged or not - and how. >>=20 >> That is a fair question. >>=20 >> The response to the INFO acknowledges that it was received. But that is o= nly at the signaling level. It doesn't confirm that the content was processe= d and understood. >=20 > Agree. >=20 >> And explicit ACK (in its own INFO) is a way to achieve that for an explic= it request/response protocol. >=20 > Agree. >=20 >> Of course that ACK need not be in an INFO. It could be something else, as= long as it is well defined by the protocol, and unambiguously linked to the= request. >=20 > Yes. >=20 >> I don't think an MSD conveyed in additional-data can be unambiguously lin= ked to the request, distinguishing it from an MSD that that=20 >> was send unsolicited but just happens to arrive. >>=20 >> If the goal is to optimize messages, then I could see embedding an MSD in= an explicit ACK. (In an info-package body.) That would be an >> *alternative* to sending an MSD as additional-data. But that doesn't real= ly save much (a few bytes) over sending a simpler ACK and=20 >> piggybacking an MSD in additional-data in the same message. >=20 > Well, we don't have an agreement on how to transport the MSD. I was hoping= that we could decide in general whether an ACK is needed or not. >=20 > In addition, even if an ACK is sent, the next question is whether there mu= st be *A* indicator mapping the content (e.g. MSD) to the corresponding requ= est.=20 In the compromise proposal last week, each request would have an explicit ac= k. I don't think we need to have a mechanism to tie an MSD to a specific req= uest. The ack acknowledges the request, and an MSD satisfies it. The PSAP pe= rforms a mid-call request for an MSD only when the call taker thinks somethi= ng might have changed. If it gets an updated MSD, it doesn't matter if it wa= s sent to satisfy the request or for some other reason (although in reality i= t won't be sent for any other reason). >=20 > Regards, >=20 > Christer >=20 >=20 >> And, as I've said before, there needs to be guidance on how long the=20 >> requester should wait for the requested data, before it considers the=20 >> request a failure. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> ---------------------------------------------------------------------- >> -- >> From: Paul Kyzivat >> Sent: =E2=80=8E20/=E2=80=8E08/=E2=80=8E2016 01:44 >> To: Randall Gellens ; Christer=20 >> Holmberg ; ecrit@ietf.org=20 >> >> Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? >>=20 >>> On 8/19/16 6:09 PM, Randall Gellens wrote: >>>=20 >>> I think that if the IVS receives a request for an MSD, it needs to=20 >>> respond with an MSD, even if it had just sent one. However, the IVS=20 >>> would have no reason to send an MSD except in the initial INVITE or=20 >>> after a request, so I don't think this situation would ever arise. >>=20 >> ISTM that the IVS *could* realize that something has changed, and=20 >> spontaneously send a new MSD. (E.g., sometime after the crash perhaps=20 >> the car catches fire, or starts moving because it is sliding down an >> embankment.) >>=20 >> (I don't know what is *in* an MSD, since that seems to be defined in=20 >> EN 15722, and that apparently isn't freely available. Maybe there is=20 >> nothing in it that *could* change. But then this whole discussion is=20 >> moot.) >>=20 >> Thanks, >> Paul >=20 From nobody Mon Aug 22 12:09:56 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 679E412D813 for ; Mon, 22 Aug 2016 12:09:55 -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 iBmOEBFwlWZc for ; Mon, 22 Aug 2016 12:09:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 42CB212D80E for ; Mon, 22 Aug 2016 12:09:53 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-2f-57bb4dfe119c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id C3.E6.06563.EFD4BB75; Mon, 22 Aug 2016 21:09:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 21:09:50 +0200 From: Christer Holmberg To: "Randall Gellens (IETF)" Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA///pygCAACT+AA== Date: Mon, 22 Aug 2016 19:09:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> In-Reply-To: <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdUfe/7+5wg6+3NC0aFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mt72trAVXNGqmLXsGnMD 4wnNLkZODgkBE4kT+z8wdzFycQgJrGeUOLesG8pZwigx4+cZli5GDg42AQuJ7n/aIKYIkPlw myKIySzgLbF2vyTIGGEBd4kNs+ezg9giAh4SOzbfhLLrJF61fmMGsVkEVCWO/5zDAmLzCvhK nNg+hR1i0wRWiVv3foAlOAVcJbqudjOC2IwCYhLfT61hArGZBcQlbj2ZzwRxs4DEkj3nmSFs UYmXj/+xQthKEo1LnrBC3KYpsX6XPkSrosSU7ofsEHsFJU7OfMIygVF0FpKpsxA6ZiHpmIWk YwEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwKg5uOW37g7G1a8dDzEKcDAq8fAusN0d LsSaWFZcmXuIUYKDWUmEd6kPUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU 1ILUIpgsEwenVANjohfbec8HyVwXucWsf3pFCGwx3P4oP0f1bL/LnjrTxqmHTrN1VN4+1xyX M/PN9BdHJ5x8cHKf/aa+3L/yvZXPqzyCMnu/e82Q032fnCr84c1Rp3O7g/W85y2d+KPlxCaF TZZiH+xefFfg6Nzwcp/79fDNPbK+uad6Pax6NuxvWdLntGQBa2mYEktxRqKhFnNRcSIAkKbP AZYCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 19:09:55 -0000 SGksDQoNCj4+Pj4gVGhpcyBpcyBub3QgYWJvdXQgTVNELiBJdCdzIGFib3V0IHRoZSByZXF1ZXN0 IHByb3RvY29sICh3aGljaCBJIA0KPj4+PiBhc3N1bWUgaW4gZnV0dXJlIG1pZ2h0IGFsc28gYmUg dXNlZCBpbiBvdGhlciBhcHBsaWNhdGlvbnMgdGhhbiANCj4+Pj4gZWNhbGwpLCBhbmQgd2hldGhl ciBhIHJlcXVlc3Qgc2hhbGwgYmUgZXhwbGljaXRseSBhY2tub3dsZWRnZWQgb3Igbm90IC0gYW5k IGhvdy4NCj4+PiANCj4+PiBUaGF0IGlzIGEgZmFpciBxdWVzdGlvbi4NCj4+PiANCj4+PiBUaGUg cmVzcG9uc2UgdG8gdGhlIElORk8gYWNrbm93bGVkZ2VzIHRoYXQgaXQgd2FzIHJlY2VpdmVkLiBC dXQgdGhhdCBpcyBvbmx5IGF0IHRoZSBzaWduYWxpbmcgbGV2ZWwuIEl0IGRvZXNuJ3QgY29uZmly bSB0aGF0IHRoZSBjb250ZW50IHdhcyBwcm9jZXNzZWQgYW5kIHVuZGVyc3Rvb2QuDQo+PiANCj4+ IEFncmVlLg0KPj4gDQo+Pj4gQW5kIGV4cGxpY2l0IEFDSyAoaW4gaXRzIG93biBJTkZPKSBpcyBh IHdheSB0byBhY2hpZXZlIHRoYXQgZm9yIGFuIGV4cGxpY2l0IHJlcXVlc3QvcmVzcG9uc2UgcHJv dG9jb2wuDQo+PiANCj4+IEFncmVlLg0KPj4gDQo+Pj4gT2YgY291cnNlIHRoYXQgQUNLIG5lZWQg bm90IGJlIGluIGFuIElORk8uIEl0IGNvdWxkIGJlIHNvbWV0aGluZyBlbHNlLCBhcyBsb25nIGFz IGl0IGlzIHdlbGwgZGVmaW5lZCBieSB0aGUgcHJvdG9jb2wsIGFuZCB1bmFtYmlndW91c2x5IGxp bmtlZCB0byB0aGUgcmVxdWVzdC4NCj4+IA0KPj4gWWVzLg0KPj4gDQo+Pj4gSSBkb24ndCB0aGlu ayBhbiBNU0QgY29udmV5ZWQgaW4gYWRkaXRpb25hbC1kYXRhIGNhbiBiZSB1bmFtYmlndW91c2x5 IA0KPj4+IGxpbmtlZCB0byB0aGUgcmVxdWVzdCwgZGlzdGluZ3Vpc2hpbmcgaXQgZnJvbSBhbiBN U0QgdGhhdCB0aGF0IHdhcyBzZW5kIHVuc29saWNpdGVkIGJ1dCBqdXN0IGhhcHBlbnMgdG8gYXJy aXZlLg0KPj4+IA0KPj4+IElmIHRoZSBnb2FsIGlzIHRvIG9wdGltaXplIG1lc3NhZ2VzLCB0aGVu IEkgY291bGQgc2VlIGVtYmVkZGluZyBhbiANCj4+PiBNU0QgaW4gYW4gZXhwbGljaXQgQUNLLiAo SW4gYW4gaW5mby1wYWNrYWdlIGJvZHkuKSBUaGF0IHdvdWxkIGJlIGFuDQo+Pj4gKmFsdGVybmF0 aXZlKiB0byBzZW5kaW5nIGFuIE1TRCBhcyBhZGRpdGlvbmFsLWRhdGEuIEJ1dCB0aGF0IGRvZXNu J3QgDQo+Pj4gcmVhbGx5IHNhdmUgbXVjaCAoYSBmZXcgYnl0ZXMpIG92ZXIgc2VuZGluZyBhIHNp bXBsZXIgQUNLIGFuZCBwaWdneWJhY2tpbmcgYW4gTVNEIGluIGFkZGl0aW9uYWwtZGF0YSBpbiB0 aGUgc2FtZSBtZXNzYWdlLg0KPj4gDQo+PiBXZWxsLCB3ZSBkb24ndCBoYXZlIGFuIGFncmVlbWVu dCBvbiBob3cgdG8gdHJhbnNwb3J0IHRoZSBNU0QuIEkgd2FzIGhvcGluZyB0aGF0IHdlIGNvdWxk IGRlY2lkZSBpbiBnZW5lcmFsIHdoZXRoZXIgYW4gQUNLIGlzIG5lZWRlZCBvciBub3QuDQo+PiAN Cj4+IEluIGFkZGl0aW9uLCBldmVuIGlmIGFuIEFDSyBpcyBzZW50LCB0aGUgbmV4dCBxdWVzdGlv biBpcyB3aGV0aGVyIHRoZXJlIG11c3QgYmUgKkEqIGluZGljYXRvciBtYXBwaW5nIHRoZSBjb250 ZW50IChlLmcuIE1TRCkgdG8gdGhlIGNvcnJlc3BvbmRpbmcgcmVxdWVzdC4gDQo+DQo+IEluIHRo ZSBjb21wcm9taXNlIHByb3Bvc2FsIGxhc3Qgd2VlaywgZWFjaCByZXF1ZXN0IHdvdWxkIGhhdmUg YW4gZXhwbGljaXQgYWNrLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSANCj4gYSBtZWNo YW5pc20gdG8gdGllIGFuIE1TRCB0byBhIHNwZWNpZmljIHJlcXVlc3QuIFRoZSBhY2sgYWNrbm93 bGVkZ2VzIHRoZSByZXF1ZXN0LCBhbmQgYW4gTVNEIHNhdGlzZmllcyBpdC4gDQo+IFRoZSBQU0FQ IHBlcmZvcm1zIGEgbWlkLWNhbGwgcmVxdWVzdCBmb3IgYW4gTVNEIG9ubHkgd2hlbiB0aGUgY2Fs bCB0YWtlciB0aGlua3Mgc29tZXRoaW5nIG1pZ2h0IGhhdmUgDQo+IGNoYW5nZWQuIElmIGl0IGdl dHMgYW4gdXBkYXRlZCBNU0QsIGl0IGRvZXNuJ3QgbWF0dGVyIGlmIGl0IHdhcyBzZW50IHRvIHNh dGlzZnkgdGhlIHJlcXVlc3Qgb3IgZm9yIHNvbWUgb3RoZXIgDQo+IHJlYXNvbiAoYWx0aG91Z2gg aW4gcmVhbGl0eSBpdCB3b24ndCBiZSBzZW50IGZvciBhbnkgb3RoZXIgcmVhc29uKS4NCg0KQWdh aW4sIEkgYW0gdGFraW5nIGFib3V0IHVzaW5nIHRoZSByZXF1ZXN0IHByb3RvY29sIHRvIHJlcXVl c3QgZGF0YSBpbiBnZW5lcmFsLg0KDQpJbiBteSBvcGluaW9uLCB0aGVyZSBzaG91bGQgYmUgYSB3 YXkgdG8gYXNzb2NpYXRlIHJlcXVlc3RlZCBjb250ZW50IHdpdGggdGhlIGFjdHVhbCByZXF1ZXN0 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJp c3Rlcg0KPiANCj4gDQo+PiBBbmQsIGFzIEkndmUgc2FpZCBiZWZvcmUsIHRoZXJlIG5lZWRzIHRv IGJlIGd1aWRhbmNlIG9uIGhvdyBsb25nIHRoZSANCj4+IHJlcXVlc3RlciBzaG91bGQgd2FpdCBm b3IgdGhlIHJlcXVlc3RlZCBkYXRhLCBiZWZvcmUgaXQgY29uc2lkZXJzIHRoZSANCj4+IHJlcXVl c3QgYSBmYWlsdXJlLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBDaHJpc3Rlcg0KPj4gDQo+ PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IENocmlzdGVyDQo+PiANCj4+IFNlbnQgZnJvbSBteSBX aW5kb3dzIFBob25lDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IC0tDQo+PiBGcm9tOiBQYXVs IEt5eml2YXQgPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQo+PiBTZW50OiDigI4yMC/i gI4wOC/igI4yMDE2IDAxOjQ0DQo+PiBUbzogUmFuZGFsbCBHZWxsZW5zIDxtYWlsdG86cmcraWV0 ZkByYW5keS5wZW5zaXZlLm9yZz47IENocmlzdGVyIA0KPj4gSG9sbWJlcmcgPG1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBlY3JpdEBpZXRmLm9yZyANCj4+IDxtYWlsdG86 ZWNyaXRAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW0Vjcml0XSBlY2FsbDogV2h5IGRvIHdl IG5lZWQgQUNLIGZvciBzdWNjZXNzZnVsIHJlcXVlc3RzPw0KPj4gDQo+Pj4gT24gOC8xOS8xNiA2 OjA5IFBNLCBSYW5kYWxsIEdlbGxlbnMgd3JvdGU6DQo+Pj4gDQo+Pj4gSSB0aGluayB0aGF0IGlm IHRoZSBJVlMgcmVjZWl2ZXMgYSByZXF1ZXN0IGZvciBhbiBNU0QsIGl0IG5lZWRzIHRvIA0KPj4+ IHJlc3BvbmQgd2l0aCBhbiBNU0QsIGV2ZW4gaWYgaXQgaGFkIGp1c3Qgc2VudCBvbmUuICBIb3dl dmVyLCB0aGUgSVZTIA0KPj4+IHdvdWxkIGhhdmUgbm8gcmVhc29uIHRvIHNlbmQgYW4gTVNEIGV4 Y2VwdCBpbiB0aGUgaW5pdGlhbCBJTlZJVEUgb3IgDQo+Pj4gYWZ0ZXIgYSByZXF1ZXN0LCBzbyBJ IGRvbid0IHRoaW5rIHRoaXMgc2l0dWF0aW9uIHdvdWxkIGV2ZXIgYXJpc2UuDQo+PiANCj4+IElT VE0gdGhhdCB0aGUgSVZTICpjb3VsZCogcmVhbGl6ZSB0aGF0IHNvbWV0aGluZyBoYXMgY2hhbmdl ZCwgYW5kIA0KPj4gc3BvbnRhbmVvdXNseSBzZW5kIGEgbmV3IE1TRC4gKEUuZy4sIHNvbWV0aW1l IGFmdGVyIHRoZSBjcmFzaCBwZXJoYXBzIA0KPj4gdGhlIGNhciBjYXRjaGVzIGZpcmUsIG9yIHN0 YXJ0cyBtb3ZpbmcgYmVjYXVzZSBpdCBpcyBzbGlkaW5nIGRvd24gYW4NCj4+IGVtYmFua21lbnQu KQ0KPj4gDQo+PiAoSSBkb24ndCBrbm93IHdoYXQgaXMgKmluKiBhbiBNU0QsIHNpbmNlIHRoYXQg c2VlbXMgdG8gYmUgZGVmaW5lZCBpbiANCj4+IEVOIDE1NzIyLCBhbmQgdGhhdCBhcHBhcmVudGx5 IGlzbid0IGZyZWVseSBhdmFpbGFibGUuIE1heWJlIHRoZXJlIGlzIA0KPj4gbm90aGluZyBpbiBp dCB0aGF0ICpjb3VsZCogY2hhbmdlLiBCdXQgdGhlbiB0aGlzIHdob2xlIGRpc2N1c3Npb24gaXMN Cj4+IG1vb3QuKQ0KPj4gDQo+PiAgICAgICAgVGhhbmtzLA0KPj4gICAgICAgIFBhdWwNCj4gDQo= From nobody Mon Aug 22 13:05: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 E994D12D832 for ; Mon, 22 Aug 2016 13:05:10 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 0HSNjod7O2Di for ; Mon, 22 Aug 2016 13:05:10 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 0DFEB12D829 for ; Mon, 22 Aug 2016 13:05:08 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-01v.sys.comcast.net with SMTP id bvSxbO62pTaLwbvT2bv9hp; Mon, 22 Aug 2016 20:05:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with SMTP id bvT1b5IzzrG54bvT1b5roe; Mon, 22 Aug 2016 20:05:08 +0000 To: Christer Holmberg , "Randall Gellens (IETF)" References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 22 Aug 2016 16:05:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEjusyHt6DJYO00QrET7sV6fVEqYC21rVbi0fG0AzfzPf0meBfXtyPteJn0+SIP1V4+iih5Vaz80snPKSYd5y7OT1sZvqyGgrlGozpt/m0tajx94i6h0 jcLayQvbL+rzas9RSTJpDnazP1b21JWogWNSc93NSPjEcdhNQkvkeinC2EsryDPMMWxeD4m73fwa6a5cRDqREB8jqmB8+zGKwMEJhBf8Cye9JkJpPb4/q/ju /DwdDdmYCZODfMh0ErX0XXprJ9xP1Rm399UFo7k5/44= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 20:05:11 -0000 On 8/22/16 3:09 PM, Christer Holmberg wrote: >> In the compromise proposal last week, each request would have an explicit ack. I don't think we need to have >> a mechanism to tie an MSD to a specific request. The ack acknowledges the request, and an MSD satisfies it. >> The PSAP performs a mid-call request for an MSD only when the call taker thinks something might have >> changed. If it gets an updated MSD, it doesn't matter if it was sent to satisfy the request or for some other >> reason (although in reality it won't be sent for any other reason). > > Again, I am taking about using the request protocol to request data in general. > > In my opinion, there should be a way to associate requested content with the actual request. That is another layer of protocol design. While it doesn't seem necessary for MSD, it could be important for some other (as yet hypothetical) cases. If you want to address that, then I think one of the following would work: 1) define an extensible body for the ACK. (E.g., a multipart body) Use it to contain the "response" to a particular request. 2) define the request to contain an identifier. Use the ACK to confirm acceptance of the request and committment to follow up. Also include that identifier in any messaage(s) that are intended as answers to the request. Will then have to figure out what form those messages are, and how to associate the identifier with them. Of those, (2) is potentially more flexible, but also more complex to design and use. Thanks, Paul From nobody Mon Aug 22 13:32: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 E187212D811 for ; Mon, 22 Aug 2016 13:32: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: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Vl8eu1KeLMNi for ; Mon, 22 Aug 2016 13:32:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6212D80B for ; Mon, 22 Aug 2016 13:32: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, 22 Aug 2016 13:32:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 22 Aug 2016 13:32:23 -0700 To: Paul Kyzivat , Christer Holmberg 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 20:32:28 -0000 At 4:05 PM -0400 8/22/16, Paul Kyzivat wrote: > On 8/22/16 3:09 PM, Christer Holmberg wrote: > >>> In the compromise proposal last week, each request would have an >>> explicit ack. I don't think we need to have >>> a mechanism to tie an MSD to a specific request. The ack >>> acknowledges the request, and an MSD satisfies it. >>> The PSAP performs a mid-call request for an MSD only when the >>> call taker thinks something might have >>> changed. If it gets an updated MSD, it doesn't matter if it was >>> sent to satisfy the request or for some other >>> reason (although in reality it won't be sent for any other reason). >> >> Again, I am taking about using the request protocol to request >> data in general. >> >> In my opinion, there should be a way to associate requested >> content with the actual request. > > That is another layer of protocol design. While it doesn't seem > necessary for MSD, it could be important for some other (as yet > hypothetical) cases. > > If you want to address that, then I think one of the following would work: > > 1) define an extensible body for the ACK. (E.g., a multipart body) > Use it to contain the "response" to a particular request. > > 2) define the request to contain an identifier. Use the ACK to > confirm acceptance of the request and committment to follow up. > Also include that identifier in any messaage(s) that are intended > as answers to the request. Will then have to figure out what form > those messages are, and how to associate the identifier with them. > > Of those, (2) is potentially more flexible, but also more complex > to design and use. Each request has a unique ID which is also used in the ACK to acknowledge that specific request. We don't have that in the MSD, and I don't think we need it for the MSD. We might need it for a future type of data, and in that case, the future type of data should include the ID of the request it is in response to. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Our greatest fear is that the Internet will become a vehicle of free distribution of information. --Ken Wasch, President of the Software Publishers' Association, 5 September 1995 From nobody Mon Aug 22 13:41: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 9BBF712D80F for ; Mon, 22 Aug 2016 13:41: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: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 BX5A9VKthEa7 for ; Mon, 22 Aug 2016 13:41:26 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 690C712D7FB for ; Mon, 22 Aug 2016 13:41: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, 22 Aug 2016 13:41:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 22 Aug 2016 13:41:22 -0700 To: Paul Kyzivat , Christer Holmberg 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 20:41:27 -0000 At 1:32 PM -0700 8/22/16, Randall Gellens wrote: > At 4:05 PM -0400 8/22/16, Paul Kyzivat wrote: > >> On 8/22/16 3:09 PM, Christer Holmberg wrote: >> >>>> In the compromise proposal last week, each request would have >>>> an explicit ack. I don't think we need to have >>>> a mechanism to tie an MSD to a specific request. The ack >>>> acknowledges the request, and an MSD satisfies it. >>>> The PSAP performs a mid-call request for an MSD only when the >>>> call taker thinks something might have >>>> changed. If it gets an updated MSD, it doesn't matter if it was >>>> sent to satisfy the request or for some other >>>> reason (although in reality it won't be sent for any other reason). >>> >>> Again, I am taking about using the request protocol to request >>> data in general. >>> >>> In my opinion, there should be a way to associate requested >>> content with the actual request. >> >> That is another layer of protocol design. While it doesn't seem >> necessary for MSD, it could be important for some other (as yet >> hypothetical) cases. >> >> If you want to address that, then I think one of the following would work: >> >> 1) define an extensible body for the ACK. (E.g., a multipart >> body) Use it to contain the "response" to a particular request. >> >> 2) define the request to contain an identifier. Use the ACK to >> confirm acceptance of the request and committment to follow up. >> Also include that identifier in any messaage(s) that are intended >> as answers to the request. Will then have to figure out what form >> those messages are, and how to associate the identifier with them. >> >> Of those, (2) is potentially more flexible, but also more complex >> to design and use. > > Each request has a unique ID which is also used in the ACK to > acknowledge that specific request. We don't have that in the MSD, > and I don't think we need it for the MSD. We might need it for a > future type of data, and in that case, the future type of data > should include the ID of the request it is in response to. To add to this: the MSD is defined by CEN and encoded in ASN.1; we can't alter it to add an ID field. Luckily, we don't actually need the ID in the case of the MSD. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There's no chance that the iPhone is going to get any significant market share. No chance. --Steve Ballmer, Microsoft CEO, 2007 From nobody Mon Aug 22 13:45:14 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 1011F12D80F for ; Mon, 22 Aug 2016 13:45:12 -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 H8y8Plz6oguP for ; Mon, 22 Aug 2016 13:45:10 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 31A1512D7FB for ; Mon, 22 Aug 2016 13:45:10 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-6a-57bb64543484 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 87.4F.04209.4546BB75; Mon, 22 Aug 2016 22:45:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 22:45:05 +0200 From: Christer Holmberg To: Randall Gellens , Paul Kyzivat Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA///pygCAACT+AIAAGA0////g9wAABELqQA== Date: Mon, 22 Aug 2016 20:45:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC30F5A@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbHdWzckZXe4wab38haNi56yWqzYcIDV 4vvzLkYHZo+/7z8weSxZ8pPJY+udxywBzFFcNimpOZllqUX6dglcGRdX97EV7BCueNx8m7GB cTZ/FyMnh4SAicSpt6fZuhi5OIQE1jNKvNgyjxXCWcIo0dKylbmLkYODTcBCovufNkiDiEC4 xKHpd9lBbGYBVYlzjY9ZQGxhAXeJDbPns0PUeEjs2HyTHWSOiMAkRolTP2azgSRYgBpaXrQx gdi8Ar4Sqze+htp8j03i1ZPzYN2cQCetm3wWbCqjgJjE91NrmCC2iUvcejKfCeJsAYkle84z Q9iiEi8f/2OFsJUkGpc8YYWo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFp mYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwPg5uOW36g7Gy28cDzEKcDAq8fAu sN0dLsSaWFZcmXuIUYKDWUmEd2sSUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS 1OzU1ILUIpgsEwenVANj5Z+4svs8J58W6r9/7Ow3v3n1X//L4vI3r+t9iSh+NH/d3XDN1UF/ HWtWdj2dWPzF7tSa1QVLjokrzr0909hi+5f/M36fdVzuWce/T/es0LmzEYlde0qru/Py1W44 q111d1nOElEwQfs9s3FdQPzO+wd5mLv6vK+c9q+/fvz+vFc7vnfxd5+8q8RSnJFoqMVcVJwI AP9vITWbAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 20:45:12 -0000 Hi, >>>>> In the compromise proposal last week, each request would have an=20 >>>>> explicit ack. I don't think we need to have >>>>> a mechanism to tie an MSD to a specific request. The ack=20 >>>>> acknowledges the request, and an MSD satisfies it. >>>>> The PSAP performs a mid-call request for an MSD only when the=20 >>>>> call taker thinks something might have >>>>> changed. If it gets an updated MSD, it doesn't matter if it was=20 >>>>> sent to satisfy the request or for some other >>>>> reason (although in reality it won't be sent for any other reason). >>>> >>>> Again, I am taking about using the request protocol to request=20 >>>> data in general. >>>> >>>> In my opinion, there should be a way to associate requested=20 >>>> content with the actual request. >>> >>> That is another layer of protocol design. While it doesn't seem=20 >>> necessary for MSD, it could be important for some other (as yet >>> hypothetical) cases. >>> >>> If you want to address that, then I think one of the following would = work: >>> >>> 1) define an extensible body for the ACK. (E.g., a multipart >>> body) Use it to contain the "response" to a particular request. >>> >>> 2) define the request to contain an identifier. Use the ACK to=20 >>> confirm acceptance of the request and committment to follow up. >>> Also include that identifier in any messaage(s) that are intended as=20 >>> answers to the request. Will then have to figure out what form those=20 >>> messages are, and how to associate the identifier with them. >>> >>> Of those, (2) is potentially more flexible, but also more complex=20 >>> to design and use. >> >> Each request has a unique ID which is also used in the ACK to=20 >> acknowledge that specific request. We don't have that in the MSD, and=20 >> I don't think we need it for the MSD. We might need it for a future=20 >> type of data, and in that case, the future type of data should include=20 >> the ID of the request it is in response to. > > To add to this: the MSD is defined by CEN and encoded in ASN.1; we can't = alter it to add an ID field. Luckily, we don't actually need the ID in the= case of the MSD. I am not talking about adding the information to the MSD content itself - t= hen we would have to do it for every new type of content than can be reques= ted. I am talking about something generic in the message that is carrying t= he MSD. Regards, Christer From nobody Mon Aug 22 13:49: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 4DEE312D836 for ; Mon, 22 Aug 2016 13:49:51 -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: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 Pp1hlmFzKrla for ; Mon, 22 Aug 2016 13:49:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D43512D829 for ; Mon, 22 Aug 2016 13:49:50 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 22 Aug 2016 13:49:49 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC30F5A@ESESSMB209.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC30F5A@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Mon, 22 Aug 2016 13:49:46 -0700 To: Christer Holmberg , Randall Gellens , Paul Kyzivat 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 22 Aug 2016 20:49:51 -0000 At 8:45 PM +0000 8/22/16, Christer Holmberg wrote: > Hi, > >>>>>> In the compromise proposal last week, each request would have an >>>>>> explicit ack. I don't think we need to have >>>>>> a mechanism to tie an MSD to a specific request. The ack >>>>>> acknowledges the request, and an MSD satisfies it. >>>>>> The PSAP performs a mid-call request for an MSD only when the >>>>>> call taker thinks something might have >>>>>> changed. If it gets an updated MSD, it doesn't matter if it was >>>>>> sent to satisfy the request or for some other >>>>>> reason (although in reality it won't be sent for any other reason). >>>>> >>>>> Again, I am taking about using the request protocol to request >>>>> data in general. >>>>> >>>>> In my opinion, there should be a way to associate requested >>>>> content with the actual request. >>>> >>>> That is another layer of protocol design. While it doesn't seem >>>> necessary for MSD, it could be important for some other (as yet >>>> hypothetical) cases. >>>> >>>> If you want to address that, then I think one of the following >>>> would work: >>>> >>>> 1) define an extensible body for the ACK. (E.g., a multipart >>>> body) Use it to contain the "response" to a particular request. >>>> >>>> 2) define the request to contain an identifier. Use the ACK to >>>> confirm acceptance of the request and committment to follow up. >>>> Also include that identifier in any messaage(s) that are intended as >>>> answers to the request. Will then have to figure out what form those >>>> messages are, and how to associate the identifier with them. >>>> >>>> Of those, (2) is potentially more flexible, but also more complex >>>> to design and use. >>> >>> Each request has a unique ID which is also used in the ACK to >>> acknowledge that specific request. We don't have that in the MSD, and >>> I don't think we need it for the MSD. We might need it for a future >>> type of data, and in that case, the future type of data should include >>> the ID of the request it is in response to. >> >> To add to this: the MSD is defined by CEN and encoded in ASN.1; we >> can't alter it to add an ID field. Luckily, we don't actually >> need the ID in the case of the MSD. > > I am not talking about adding the information to the MSD content > itself - then we would have to do it for every new type of content > than can be requested. I am talking about something generic in the > message that is carrying the MSD. I think it's better in the data, since it's small, not all data needs it, and the data can be sent in different ways. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Who's on first? From nobody Mon Aug 22 15:05:20 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 AF58F12D838 for ; Mon, 22 Aug 2016 15:05:16 -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 DsTzx8nlekSP for ; Mon, 22 Aug 2016 15:05:13 -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 0B0D712D837 for ; Mon, 22 Aug 2016 15:05:12 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 600D1A3525D5C; Mon, 22 Aug 2016 22:05:06 +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 u7MM5At1023660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 22:05:10 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 u7MM59QZ017182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Aug 2016 00:05:09 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 23 Aug 2016 00:05:09 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , Christer Holmberg , ECRIT Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+moz5ujqkArDNUixwMINjqLOPKBQwoSAgASw5ZA= Date: Mon, 22 Aug 2016 22:05:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 22 Aug 2016 22:05:17 -0000 I'm afraid I see somewhat muddled thinking here, and I am sure it is not mi= ne. We have already agreed for the use case of ecall, that the transfer of data= outside of a call control message using INFO requires the creation of an I= nfo package. Following that use case, and using exactly the same argument, then any othe= r use case requiring to use INFO to transfer data would create another Info= package for the transfer of that data. While theoretically, an argument might apply that it is valid to use additi= onal data in an INFO message, I cannot conceive of a use case where only th= ere in addition to the ecall Info package, and never required at any other = time. If it is required at any other time, then the separate Info package m= ust exist, and therefore if it exists, it should be used for all the transf= ers outside of call control messages. Conversely, if it is only there when = ecall transfer exists, and never outside it, I wonder why it is not part of= the ecall Info package. The only exception I can see to this is where some other preexisting linkin= g mechanism exists, such as Geolocation, but even this in my mind causes is= sues. Regards Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 19 August 2016 23:53 To: Christer Holmberg; ECRIT Subject: Re: [Ecrit] Multipart with INFO On 8/19/16 6:36 PM, Christer Holmberg wrote: > Hi, > >>>>>>>> The discussion on ecall has become quite heated, with people=20 >>>>>>>> dug in on all sides. Can we calm it down a bit? >>>>>>>> >>>>>>>> IMO a couple of different approaches have been described that=20 >>>>>>>> would work and not violate any specs. The differences between=20 >>>>>>>> these reflect differences of philosophy and taste. >>>>>>> >>>>>>> I don=B9t think we have an agreement on the=20 >>>>>>> would-not-violate-any-specs part. We clearly have different views o= n what is allowed by RFC 6086. >>>>>>> >>>>>>> But, I do agree we need to try to figure out how to move forward. >>>>>> >>>>>> OK. Maybe we should start there. >>>>>> >>>>>> I guess there is some dispute on whether it is valid for an INFO=20 >>>>>> message to contain a multipart body, where one part contains the=20 >>>>>> info package >>>>>> (C-D: info-package) and another part (C-D: by-reference) is=20 >>>>>> referenced by a cid: uri in some sip header field. >>>>>> >>>>>> In my mind there is no question that this is valid. Do you=20 >>>>>> disagree, and if so, on what basis? >>>>> >>>>> The dispute is whether a message body must be associated with an=20 >>>>> Info Package. >>>>> >>>>> In my view: >>>>> >>>>> - RFC 6086 allows bodies not associated with an Info Package in=20 >>>>> INFOs in order to be backward compatible with existing pre-6086 INFO = usages. >>>>> - Any NEW usage MUST be associated with an Info Package. Sending=20 >>>>> of MSD is a new INFO usage. >>>> >>>> I disagree. I find the following in 6086: >>>> >>>> NOTE: An INFO request can also contain other body parts that are >>>> meaningful within the context of an invite dialog usage but are >>>> not specifically associated with the INFO method and the >>>> application concerned. >>> >>> So, you are saying that the MSD is not associated with the ecall applic= ation??? >>> >>> RFC 6086 also says: >>> >>> "Any new usage MUST use the Info Package mechanism defined in this >>> specification, since it does not share the issues associated wi= th >>> legacy INFO usage, and since Info Packages can be registered wi= th >>> IANA." >>> >>> And, in my opinion, sending of MSD *is* part of the new INFO usage. It'= s not something else that we add to the INFO. >>> >>> Otherwise, why did we do RFC 6086 in the first place? We can just allow= people to use - and standardize such usage - as in the past, with all the = problems associated, just >> by saying the content is not associated with t= he application... >> >> We did 6086 so that the usage if INFO to carry associated body parts cou= ld be negotiated. > > You don't need 6086 to indicate what body parts you support. There is a S= IP header field for that. > > We defined 6086 so that you could define and indicate the semantics assoc= iated with the INFO request (including body parts), and to negotiate suppor= t of processing that semantics. > >> IMO if something is in the message, but not in the info-package body=20 >> part, then it isn't specifically part of the INFO usage. For instance, a= ny random header field that you happen to include isn't. > > MSD is not "something random that you happen to include" in an INFO assoc= iated with the ecall application. > > Or, again, are you saying that MSD is not associated with the ecall appli= cation? I"m saying that I don't know anything about an ecall *application*. I agree= there might be one, but we aren't defining that. I do know the MSD is asso= ciated with a call-info header field. I can potentially put that call-info = in any message I like (that permits call-info). If there happens to be an ecall application, then the MSD might indeed end = up at that application. I would expect that the application will be *loosely* coupled to the sip session. Lots of other things may happen in th= at session that may or may not be anticipated by the application.=20 Those things may be processed by other UA application software. So the ecal= l application is just one *user* of the sip session. Of course the application environment may constrain the possibilities in so= me way. But I think that is outside of our scope here. Thanks, Paul _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 22 15:27: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 27CF312D1A9 for ; Mon, 22 Aug 2016 15:27:54 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 qk821R-43YlI for ; Mon, 22 Aug 2016 15:27:52 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 5E9B912D095 for ; Mon, 22 Aug 2016 15:27:52 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-12v.sys.comcast.net with SMTP id bxfKbzFlilHMYbxhAbPpeh; Mon, 22 Aug 2016 22:27:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-02v.sys.comcast.net with SMTP id bxh8bPBKdlDr0bxh9bBAut; Mon, 22 Aug 2016 22:27:51 +0000 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , ECRIT References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: Date: Mon, 22 Aug 2016 18:27:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCsYoTiph6qk1rrvN9IzyAYDZZiNzdbntKZF61XCVI/siQWhYV4wglUor016pojpyW3PEgdFo6FZRU2/77/i//Hw3N02wRvGdXjFOow4EDnZLgvmjuux XsA1XHkjbhy0B5nwWiBo/EeiQN1Qec6ILDNI5XzMLjwjgLAybmt7rscc2rgYE7ppvRZT36Drr8z+EWVo+UiOfi2PnnK8pLG9zbXfcIwFr6oq+akuY00qaWjn 892jyrshc2cSF4j+UjflWyLltSiYFdtMscELwDiH0Pk= Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 22 Aug 2016 22:27:54 -0000 On 8/22/16 6:05 PM, Drage, Keith (Nokia - GB) wrote: > I'm afraid I see somewhat muddled thinking here, and I am sure it is not mine. > > We have already agreed for the use case of ecall, that the transfer of data outside of a call control message using INFO requires the creation of an Info package. Since ecall isn't yet done, presumably anything is potentially subject to revision. But I don't think that is being proposed. > Following that use case, and using exactly the same argument, then any other use case requiring to use INFO to transfer data would create another Info package for the transfer of that data. > > While theoretically, an argument might apply that it is valid to use additional data in an INFO message, I cannot conceive of a use case where only there in addition to the ecall Info package, and never required at any other time. If it is required at any other time, then the separate Info package must exist, and therefore if it exists, it should be used for all the transfers outside of call control messages. Conversely, if it is only there when ecall transfer exists, and never outside it, I wonder why it is not part of the ecall Info package. I can't parse that statement. IMO what we have is a suggestion that there be an info package that says "I'd like to have you send me a fresh copy of X", where there is already an independently defined mechanism for sending X, independent of this info package. For MSD that mechanism is additional-info, and it happens that it is valid for the MSD to piggyback on an INFO response. For something other than MSD it remains to be seen how it might be conveyed. We don't yet have any examples. It is *conceivable* that something else might be defined to use additional-info. Or it might be defined to use another info-package. > The only exception I can see to this is where some other preexisting linking mechanism exists, such as Geolocation, but even this in my mind causes issues. I don't think we need to decide this. Thanks, Paul > Regards > > Keith > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 19 August 2016 23:53 > To: Christer Holmberg; ECRIT > Subject: Re: [Ecrit] Multipart with INFO > > On 8/19/16 6:36 PM, Christer Holmberg wrote: >> Hi, >> >>>>>>>>> The discussion on ecall has become quite heated, with people >>>>>>>>> dug in on all sides. Can we calm it down a bit? >>>>>>>>> >>>>>>>>> IMO a couple of different approaches have been described that >>>>>>>>> would work and not violate any specs. The differences between >>>>>>>>> these reflect differences of philosophy and taste. >>>>>>>> >>>>>>>> I donąt think we have an agreement on the >>>>>>>> would-not-violate-any-specs part. We clearly have different views on what is allowed by RFC 6086. >>>>>>>> >>>>>>>> But, I do agree we need to try to figure out how to move forward. >>>>>>> >>>>>>> OK. Maybe we should start there. >>>>>>> >>>>>>> I guess there is some dispute on whether it is valid for an INFO >>>>>>> message to contain a multipart body, where one part contains the >>>>>>> info package >>>>>>> (C-D: info-package) and another part (C-D: by-reference) is >>>>>>> referenced by a cid: uri in some sip header field. >>>>>>> >>>>>>> In my mind there is no question that this is valid. Do you >>>>>>> disagree, and if so, on what basis? >>>>>> >>>>>> The dispute is whether a message body must be associated with an >>>>>> Info Package. >>>>>> >>>>>> In my view: >>>>>> >>>>>> - RFC 6086 allows bodies not associated with an Info Package in >>>>>> INFOs in order to be backward compatible with existing pre-6086 INFO usages. >>>>>> - Any NEW usage MUST be associated with an Info Package. Sending >>>>>> of MSD is a new INFO usage. >>>>> >>>>> I disagree. I find the following in 6086: >>>>> >>>>> NOTE: An INFO request can also contain other body parts that are >>>>> meaningful within the context of an invite dialog usage but are >>>>> not specifically associated with the INFO method and the >>>>> application concerned. >>>> >>>> So, you are saying that the MSD is not associated with the ecall application??? >>>> >>>> RFC 6086 also says: >>>> >>>> "Any new usage MUST use the Info Package mechanism defined in this >>>> specification, since it does not share the issues associated with >>>> legacy INFO usage, and since Info Packages can be registered with >>>> IANA." >>>> >>>> And, in my opinion, sending of MSD *is* part of the new INFO usage. It's not something else that we add to the INFO. >>>> >>>> Otherwise, why did we do RFC 6086 in the first place? We can just allow people to use - and standardize such usage - as in the past, with all the problems associated, just >> by saying the content is not associated with the application... >>> >>> We did 6086 so that the usage if INFO to carry associated body parts could be negotiated. >> >> You don't need 6086 to indicate what body parts you support. There is a SIP header field for that. >> >> We defined 6086 so that you could define and indicate the semantics associated with the INFO request (including body parts), and to negotiate support of processing that semantics. >> >>> IMO if something is in the message, but not in the info-package body >>> part, then it isn't specifically part of the INFO usage. For instance, any random header field that you happen to include isn't. >> >> MSD is not "something random that you happen to include" in an INFO associated with the ecall application. >> >> Or, again, are you saying that MSD is not associated with the ecall application? > > I"m saying that I don't know anything about an ecall *application*. I agree there might be one, but we aren't defining that. I do know the MSD is associated with a call-info header field. I can potentially put that call-info in any message I like (that permits call-info). > > If there happens to be an ecall application, then the MSD might indeed end up at that application. I would expect that the application will be > *loosely* coupled to the sip session. Lots of other things may happen in that session that may or may not be anticipated by the application. > Those things may be processed by other UA application software. So the ecall application is just one *user* of the sip session. > > Of course the application environment may constrain the possibilities in some way. But I think that is outside of our scope here. > > Thanks, > Paul > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Mon Aug 22 23:03:58 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 C191112D0EC for ; Mon, 22 Aug 2016 23:03:56 -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 EIFh-SawiYKz for ; Mon, 22 Aug 2016 23:03:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 13B9A12D09B for ; Mon, 22 Aug 2016 23:03:54 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-5d-57bbe748d114 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 07.2A.02553.847EBB75; Tue, 23 Aug 2016 08:03:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 08:03:50 +0200 From: Christer Holmberg To: Paul Kyzivat , "Drage, Keith (Nokia - GB)" , ECRIT Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///SIgCAAHCnoP///jkAgAAjmWD//+XlgACVM80AAADK9AAAFly7AA== Date: Tue, 23 Aug 2016 06:03:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7nK7n893hBv0TWCwaFz1ltdiw5TiL xYoNB1gdmD3+vv/A5LFkyU8mj7u3LjEFMEdx2aSk5mSWpRbp2yVwZSyfNZutoI+/omP3DqYG xv/cXYycHBICJhJ3N/1k72Lk4hASWM8ocenwH2YIZwmjxJmeDqAMBwebgIVE9z9tkAYRgXKJ Wd0tzCC2sICGxLf+fcwQcU2JyddeMIOUiwhkSfxsjQcJswioSrQvmc0GYvMKWEn8mn4CalcX q8SSJT2sIAlOAQeJvU8OgdmMAmIS30+tYQKxmQXEJW49mc8EcaiAxJI955khbFGJl4//gdWL CuhJfP86GyquKNH+tIERotdA4v25+cwQtrXElHPv2SBsbYllC18zQxwkKHFy5hOWCYxis5Cs m4WkfRaS9llI2mchaV/AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzDWDm75bbCD8eVz x0OMAhyMSjy8C2x3hwuxJpYVV+YeYpTgYFYS4T39BCjEm5JYWZValB9fVJqTWnyIUZqDRUmc 1/+lYriQQHpiSWp2ampBahFMlomDU6qBcaYnz49ojVf3QrUvPqgvjlqj9ferk1Wyb+eOB7ys k1c/t0vQtg76fe7SyWj3T/3nJll83lXpFsriMuNFw/08qQdqKr9/+S0M9Ju8KFvpraC5/fzU Ql6ekNpQjXzeg6+YJBx0+A/m7LlicHB3gfZd9cqfJ/wfyeZts1495+6x9QtOexX2/co5rsRS nJFoqMVcVJwIACTr4PixAgAA Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 06:03:57 -0000 Hi Paul, >>I'm afraid I see somewhat muddled thinking here, and I am sure it is not >>mine. >> >> We have already agreed for the use case of ecall, that the transfer of >>data outside of a call control message using INFO requires the creation >>of an Info package. > >Since ecall isn't yet done, presumably anything is potentially subject >to revision. The new suggestion was presented as a =B3compromise proposal=B2. As we have= n=B9t reached an agreement on that, I think we should step back to where we were and try to figure out another way of solving the issue. =8A >IMO what we have is a suggestion that there be an info package that says >"I'd like to have you send me a fresh copy of X", where there is already >an independently defined mechanism for sending X, independent of this >info package. > >For MSD that mechanism is additional-info, and it happens that it is >valid for the MSD to piggyback on an INFO response. My opinion is still: - the INFO is associated with ecall (i.e. the INFO is sent to request, acknowledge or provide information associated with the ecall) - the MSD is association with ecall (if we can=B9t even agree on that I think we need to ask for guidance outside IETF). Therefore the MSD has to be associated with an info package, per 6086. In my opinion, the MSD is not =B3piggybacked random information not related to ecall=B2, and if we allow it to be sent outside an info package we basically open the door for people to use INFO for *ANYTHING* without registering an Info Package. That=B9s exactly what we wanted to prevent wit= h 6086, and as far as I remember you were heavily involved in that work, and in the years of painful to-info-or-not-to-info discussions that took place prior to that, so I=B9m really surprised that you suggest something like that. But, you are of course entitled to your opinion :) Regards, Christer From nobody Mon Aug 22 23:35:45 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 BE6C912D520 for ; Mon, 22 Aug 2016 23:35:43 -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 Ht9bNLWh_Hmh for ; Mon, 22 Aug 2016 23:35:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 450DF12B035 for ; Mon, 22 Aug 2016 23:35:41 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-5c-57bbeebb405c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 55.50.02553.BBEEBB75; Tue, 23 Aug 2016 08:35:40 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 08:35:38 +0200 From: Ivo Sedlacek To: Randall Gellens , Christer Holmberg , Paul Kyzivat Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA///pygCAACT+AP//7uIAAADz9YAAAFBRAAAAITuAAAAp3wAAGD9nMA== Date: Tue, 23 Aug 2016 06:35:37 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F3532@ESESSMB301.ericsson.se> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC30F5A@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdQHfPu93hBq/rLRoXPWW1WLHhAKvF 9+ddjA7MHn/ff2DyWLLkJ5PH1juPWQKYo7hsUlJzMstSi/TtErgyDr98zVjQxVnxYPI65gbG TvYuRk4OCQETiRXvZjF3MXJxCAmsZ5Q4d/orK4SzhFHixo0PYFVsAnoSE7ccAUuICHQzSjTe aWAESTALqEqca3zMAmILC7hLbJg9H6xBRMBDYsfmm+wQDcsYJbbs3whWxALU0LrsIVgzr4Cv ROe0XjBbSOAMu8TdybJdjBwcnEA3tfYVgIQZBWQlrv7phdolLnHryXwmiLMFJJbsOc8MYYtK vHz8jxXCVpRofwpzm47Egt2f2CBsbYllC18zQ6wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsY WVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbPwS2/DXYwvnzueIhRgINRiYd3ge3ucCHW xLLiytxDjBIczEoivC0vgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphak FsFkmTg4pRoYOSe9nM58dRn37L9STNvKOg6xBD3+XrHQTsIpgOP93sYbjAdE1p1qmPfCNfzO gbrj4bM9Y6+vCGANY1jD1vFRknnKV8bD3Sr3qqTYLm7Xsp5i0TfVxG6rutxttdy3l9Vrn3Pe mnOpguH2apscd1Vtr/f9KiJNhlUJ6ydcvL3pc0Y2w7VZgU+7lViKMxINtZiLihMBlEjCepoC AAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 23 Aug 2016 06:35:44 -0000 Hello, my view: 1) unless we want to allow an IVS participating in a call to send a new MSD= to the PSAP on the IVS own decision, then MSD itself is successful acknowl= edgement of the request. Thus, an explicit successful acknowledgement of th= e request is NOT needed. 2) if we want to allow an IVS participating in a call to send a new MSD to = the PSAP on the IVS own decision: - we need to distinguish: - MSD-sent-upon-IVS-own-decision; and - MSD-sent-upon-PSAP-request; and indicate so from the IVS to the PSAP. For MSD-sent-upon-PSAP-request,= there would have to be some linkage to the request from PSAP. - MSD-sent-upon-PSAP-request is a successful acknowledgement of the reques= t. Again, another explicit successful acknowledgement of the request is NOT= needed. 3) I agree that we need and explicit message from the IVS to the PSAP if, u= pon receiving request from the PSAP, the IVS decides NOT to send an MSD=20 So, the first step to find a way forward is: Do we want to allow an IVS participating in a call to send a new MSD to th= e PSAP on the IVS own decision? Kind regards Ivo Sedlacek From nobody Mon Aug 22 23:47: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 7C81212D758 for ; Mon, 22 Aug 2016 23:47:06 -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 0fv1vSdTNQOH for ; Mon, 22 Aug 2016 23:47:05 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 4361B12B006 for ; Mon, 22 Aug 2016 23:47:05 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-31-57bbf16768ca Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 38.2A.02493.761FBB75; Tue, 23 Aug 2016 08:47:03 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.224]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 08:47:02 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "Drage, Keith (Nokia - GB)" , Christer Holmberg , ECRIT Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+mouINmMP564H02enZdKbs9GiaBQwoSAgASpnQCAAAZYAIAArCpA Date: Tue, 23 Aug 2016 06:47:02 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101164F3557@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7vW76x93hBh9ua1k0LnrKarFhy3EW ixUbDrA6MHv8ff+ByWPJkp9MHndvXWIKYI7isklJzcksSy3St0vgyvj3dSJLwUOmiuv7XjI1 ME5l6mLk4JAQMJF4dkexi5GLQ0hgPaPE9aadzBDOEkaJOzMmADmcHGwCehITtxxhBUmICKxl lHjQ/I8FJCEsoCFxeMIMJhBbREBTYvK1F8wQtpvEq2WrwGwWAVWJ11N62UBsXgFfiUdr30Nt 6GKVWLKkhxUkwSngILH3ySEwm1FAVuLqn15GEJtZQFzi1pP5YAskBAQkluw5zwxhi0q8fPyP FcJWlGh/2gBVryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWM osWpxcW56UZGeqlFmcnFxfl5enmpJZsYgXFycMtvqx2MB587HmIU4GBU4uFdYLs7XIg1say4 MvcQowQHs5IIb8tLoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZ Jg5OqQbG3p8H9me/2cm+n0E5n5HxwmLvtyVzXm57oT755YqXqz8IBwQ+nbDkQWpyTFvQS24l pQtJnyJZ5so4/5lSXCvf6iP251fKtaUZLBO+6TPducJ4VvPMP8+pXE27nt85OFtxtv2arFva F9IOvkl6OeFLwe9Svqu//03Xl/WzdoxxSk/ZrRggcbc3SYmlOCPRUIu5qDgRAKiFayKPAgAA Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 06:47:06 -0000 Hello Paul, > For MSD that mechanism is additional-info, and it happens that it is vali= d for the MSD to piggyback on an INFO response. Stating that MSD is NOT associated with the emergencyCallData.eCall.__MSD__= info package (an info package defined in a draft with sole purpose to get = MSD from IVS) is very weird. Kind regards Ivo From nobody Tue Aug 23 03:10: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 9466212D908 for ; Tue, 23 Aug 2016 03:10:26 -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 QAN2MP0NMMk4 for ; Tue, 23 Aug 2016 03:10:24 -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 A50DD12D902 for ; Tue, 23 Aug 2016 03:10:24 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 426BEBAAC5FA1; Tue, 23 Aug 2016 10:10:20 +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 u7NAAMlR012300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 10:10:22 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 u7NAALiV030939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Aug 2016 12:10:21 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 23 Aug 2016 12:10:21 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , Paul Kyzivat , ECRIT Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+moz5ujqkArDNUixwMINjqLOPKBQwoSAgASw5ZD///8QAIAAf2gAgABYkyA= Date: Tue, 23 Aug 2016 10:10:21 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF57BC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@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="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 10:10:27 -0000 Just to be clear, I do not agree with the supposed "compromise proposal eit= her (I just have not got to that thread yet). I do not see any element of c= ompromise at all. I essentially support Christer in what he is saying below. I expressed my position, and it is unchanged, in the following text (taken = from the previous mail), which I believe Paul also agreed with (and I think= aligns with Christer and Ivo): "I see some sort of supporting ecrit "application" in the PSAP and the call= ing UA. That supporting application initiates two independent data transpor= t mechanisms within SIP, using RFC 7852 for the initial MSD and the data re= sponse to indicate support of MSD reception, and using RFC 6086 for any sub= sequent MSD. SIP itself knows nothing about the relationship between these = two mechanisms, only the ecrit "application". It is the ecrit "application"= that performs the combination of the data received using the two data tran= sfer mechanisms as appropriate. The MSDs transferred using the two mechanisms following identical syntax an= d coding, but that is merely a matter of convenient definition. As such, use of Call-Info in INFO would be entirely inappropriate, because = INFO does not transfer additional-data according to RFC 7852. Note that RFC 7842 is only used by ecrit in the initial INVITE transaction,= and appearance in subsequent messages of any form would not be expected by= the recipient PSAP." As such, I see no crossover with additional data at the SIP level, and beca= use we have decided to use an Info package to carry data outside circuit sw= itched messages, I believe the decision on any other data would follow the = same route. As such I believe the use cases for additional data in INFO are= limited, and not something we should be worrying about tat the moment. Regards Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 23 August 2016 07:04 To: Paul Kyzivat; Drage, Keith (Nokia - GB); ECRIT Subject: Re: [Ecrit] Multipart with INFO Hi Paul, >>I'm afraid I see somewhat muddled thinking here, and I am sure it is=20 >>not mine. >> >> We have already agreed for the use case of ecall, that the transfer=20 >>of data outside of a call control message using INFO requires the=20 >>creation of an Info package. > >Since ecall isn't yet done, presumably anything is potentially subject=20 >to revision. The new suggestion was presented as a =B3compromise proposal=B2. As we have= n=B9t reached an agreement on that, I think we should step back to where we= were and try to figure out another way of solving the issue. =D0 >IMO what we have is a suggestion that there be an info package that=20 >says "I'd like to have you send me a fresh copy of X", where there is=20 >already an independently defined mechanism for sending X, independent=20 >of this info package. > >For MSD that mechanism is additional-info, and it happens that it is=20 >valid for the MSD to piggyback on an INFO response. My opinion is still: - the INFO is associated with ecall (i.e. the INFO is sent to request, ackn= owledge or provide information associated with the ecall) - the MSD is association with ecall (if we can=B9t even agree on that I thi= nk we need to ask for guidance outside IETF). Therefore the MSD has to be associated with an info package, per 6086. In my opinion, the MSD is not =B3piggybacked random information not related= to ecall=B2, and if we allow it to be sent outside an info package we basi= cally open the door for people to use INFO for *ANYTHING* without registeri= ng an Info Package. That=B9s exactly what we wanted to prevent with 6086, a= nd as far as I remember you were heavily involved in that work, and in the = years of painful to-info-or-not-to-info discussions that took place prior t= o that, so I=B9m really surprised that you suggest something like that. But= , you are of course entitled to your opinion :) Regards, Christer From nobody Tue Aug 23 04:26: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 9A181126579 for ; Tue, 23 Aug 2016 04:26:37 -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 s8GNWJBhFTwp for ; Tue, 23 Aug 2016 04:26:35 -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 1127912B011 for ; Tue, 23 Aug 2016 04:26:35 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 84D707C9BC35C; Tue, 23 Aug 2016 11:26:30 +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 u7NBQWn5032761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 11:26:33 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 u7NBQVcM019189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Aug 2016 13:26:32 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 23 Aug 2016 13:26:31 +0200 From: "Drage, Keith (Nokia - GB)" To: Randall Gellens , Christer Holmberg , Paul Kyzivat Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA///pygCAACT+AP//7uIAAADz9YAAAFBRAAAAITuAAAAp3wAABx5SMA== Date: Tue, 23 Aug 2016 11:26:30 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF57CA4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC30F5A@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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 23 Aug 2016 11:26:37 -0000 Just finished working back over the entire thread. This discussion is getti= ng way too complicated and I think we need to simplify it. Working through = the issues as follows: 1) Transactional uniqueness. We have a dialog. 3GPP stage 1 documents require it for all emergency calls= . The Info package is correlated with the dialog - a separate dialog would = have a separate instance of the Info package. When one defines an applicati= on using an Info package, one has to decide what sort of protocol is runnin= g over the top, in terms of transactional complexity. This one is a very si= mply protocol where I do not believe one would ever need two simultaneous t= ransactions within this instance of the Info package, and given that the re= sult of the request is the current MSD, I do not think it would ever matter= if there were allowed to be two requests outstanding - it does not matter = if the MSD is sent in response to request 1 or request 2. So the MSD receiv= ed relates to the endpoints identified within the dialog, and if any audit = trail is required, then the SIP timestamp header field can be utilised, but= there is never a need to relate a response to a specific request. As far as I am aware, there is no such parallel transactional behaviour in = the existing CS domain modem mechanism. 2) Knowing that a response to an request for MSD is not lost. I agree with Paul in stating that a response to an INFO request indicates t= hat the data has been received, but does not indicate that it has been proc= essed. So when the emergency user agent sends an MSD in an INFO request, it will n= ot know for sure that the application in the PSAP has received it. I believ= e it is up to the PSAP to police and resolve this issue (and we should agre= e this). The PSAP will know that data has been received validly at the SIP level, ev= en if it is corrupted or malformed at the application level. If such data i= s malformed, then it is a simple matter for the PSAP application to send an= other request. Depending on the nature of the original failure, the second = one will either suceed or not. At some point in a sequence of such failures= the PSAP will need to decide that requesting will never work, but this mec= hanism should be used for one off errors. 3) Knowing that a request for MSD is not lost.=20 The PSAP application will need to communicate with the SIP layer so that th= e PSAP application is notified if a response is not received to a request f= or an MSD in an INFO message. 4) Knowing that the initial MSD sent in the INVITE request has been receive= d.=20 I have not yet seen a discussion of this in this thread, but because it rel= ates I will raise it. This is the only point where I believe an explicit ac= knowledgement is needed, but for different reasons to what might be expecte= d. It is not needed so that the emergency user agent knows that the MSD has= been received, because a similar discussion to that in 2) above applies - = there are a number of indicators to the PSAP that it should have received a= n MSD, and if it does not get one it can request one, assuming the Info pac= kage has been negotiated. It is needed because the PSAP and the emergency u= ser agent need to know that the call has fallen back to operating in the CS= domain at some point, and therefore end to end transfer of SIP data is los= t, and therefore the CS domain mechanism of in-band data needs to be adopte= d. A mechanism is provided for in the 3GPP specifications. Regards Keith =09 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 22 August 2016 21:50 To: Christer Holmberg; Randall Gellens; Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? At 8:45 PM +0000 8/22/16, Christer Holmberg wrote: > Hi, > >>>>>> In the compromise proposal last week, each request would have=20 >>>>>> an explicit ack. I don't think we need to have >>>>>> a mechanism to tie an MSD to a specific request. The ack =20 >>>>>> acknowledges the request, and an MSD satisfies it. >>>>>> The PSAP performs a mid-call request for an MSD only when the =20 >>>>>> call taker thinks something might have >>>>>> changed. If it gets an updated MSD, it doesn't matter if it=20 >>>>>> was sent to satisfy the request or for some other >>>>>> reason (although in reality it won't be sent for any other reason= ). >>>>> >>>>> Again, I am taking about using the request protocol to request =20 >>>>> data in general. >>>>> >>>>> In my opinion, there should be a way to associate requested =20 >>>>> content with the actual request. >>>> >>>> That is another layer of protocol design. While it doesn't seem =20 >>>> necessary for MSD, it could be important for some other (as yet >>>> hypothetical) cases. >>>> >>>> If you want to address that, then I think one of the following=20 >>>> would work: >>>> >>>> 1) define an extensible body for the ACK. (E.g., a multipart >>>> body) Use it to contain the "response" to a particular request. >>>> >>>> 2) define the request to contain an identifier. Use the ACK to =20 >>>> confirm acceptance of the request and committment to follow up. >>>> Also include that identifier in any messaage(s) that are intended=20 >>>> as answers to the request. Will then have to figure out what form=20 >>>> those messages are, and how to associate the identifier with them. >>>> >>>> Of those, (2) is potentially more flexible, but also more=20 >>>> complex to design and use. >>> >>> Each request has a unique ID which is also used in the ACK to =20 >>> acknowledge that specific request. We don't have that in the MSD,=20 >>> and I don't think we need it for the MSD. We might need it for a=20 >>> future type of data, and in that case, the future type of data=20 >>> should include the ID of the request it is in response to. >> >> To add to this: the MSD is defined by CEN and encoded in ASN.1; we=20 >> can't alter it to add an ID field. Luckily, we don't actually need=20 >> the ID in the case of the MSD. > > I am not talking about adding the information to the MSD content=20 > itself - then we would have to do it for every new type of content=20 > than can be requested. I am talking about something generic in the=20 > message that is carrying the MSD. I think it's better in the data, since it's small, not all data needs it, a= nd the data can be sent in different ways. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Who's on first? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Aug 23 05:15:36 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 76E2F12D0C1 for ; Tue, 23 Aug 2016 05:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548] 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 VAfVYlDpap3F for ; Tue, 23 Aug 2016 05:15:33 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DD712D099 for ; Tue, 23 Aug 2016 05:15:31 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail31.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Aug 2016 14:15:27 +0200 X-IronPort-AV: E=Sophos;i="5.28,565,1464645600"; d="scan'208";a="1126901220" Received: from he105660.emea1.cds.t-internal.com ([10.169.119.56]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 23 Aug 2016 14:15:27 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105660.emea1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 14:15:27 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 14:15:27 +0200 From: To: , , , Thread-Topic: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR+e3Drl7X9qOJvkGedgmS1TGX9KBQNCGAgAA1uwD//9JTgIAAQWGAgAATT4CAACZpAIAACeIAgAAlG9WABBiPgIAATxOA///pygCAACT+AP//7uIAAADz9YAAAFBRAAAAITuAAAAp3wAABx5SMAAdT22g Date: Tue, 23 Aug 2016 12:15:26 +0000 Message-ID: <5049b60f5ea0499e870fc059f52e2d0e@HE105660.emea1.cds.t-internal.com> References: <06153496-26c6-7372-dd66-46a9c9304498@alum.mit.edu> <706faf44-1502-4bb3-648d-527f7d754a7d@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC27A8C@ESESSMB209.ericsson.se> <046d9c00-b1c5-4c02-e03b-ff250a0615dc@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC308D5@ESESSMB209.ericsson.se> <7C13DF77-4110-4FA0-BD67-CF2D89318352@randy.pensive.org> <7594FB04B1934943A5C02806D1A2204B4BC30B15@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC30F5A@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57CA4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF57CA4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.244.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 23 Aug 2016 12:15:35 -0000 Hi Keith, You are talking about: 4) Knowing that the initial MSD sent in the INVITE request has been receive= d.=20 ... It is needed because the PSAP and the emergency user agent need to know= that the call has fallen back to operating in the CS domain at some point,= and therefore end to end transfer of SIP data is lost, and therefore the C= S domain mechanism of in-band data needs to be adopted. A mechanism is prov= ided for in the 3GPP specifications. So my question is if you see now the need to add some words with regard to = Fallback within this draft or do we need something other where we document = that? Or is this a 3GPP task? Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Drage, Keith (Nok= ia - GB) Gesendet: Dienstag, 23. August 2016 13:26 An: Randall Gellens; Christer Holmberg; Paul Kyzivat Cc: ecrit@ietf.org Betreff: Re: [Ecrit] ecall: Why do we need ACK for successful requests? Just finished working back over the entire thread. This discussion is getti= ng way too complicated and I think we need to simplify it. Working through = the issues as follows: 1) Transactional uniqueness. We have a dialog. 3GPP stage 1 documents require it for all emergency calls= . The Info package is correlated with the dialog - a separate dialog would = have a separate instance of the Info package. When one defines an applicati= on using an Info package, one has to decide what sort of protocol is runnin= g over the top, in terms of transactional complexity. This one is a very si= mply protocol where I do not believe one would ever need two simultaneous t= ransactions within this instance of the Info package, and given that the re= sult of the request is the current MSD, I do not think it would ever matter= if there were allowed to be two requests outstanding - it does not matter = if the MSD is sent in response to request 1 or request 2. So the MSD receiv= ed relates to the endpoints identified within the dialog, and if any audit = trail is required, then the SIP timestamp header field can be utilised, but= there is never a need to relate a response to a specific request. As far as I am aware, there is no such parallel transactional behaviour in = the existing CS domain modem mechanism. 2) Knowing that a response to an request for MSD is not lost. I agree with Paul in stating that a response to an INFO request indicates t= hat the data has been received, but does not indicate that it has been proc= essed. So when the emergency user agent sends an MSD in an INFO request, it will n= ot know for sure that the application in the PSAP has received it. I believ= e it is up to the PSAP to police and resolve this issue (and we should agre= e this). The PSAP will know that data has been received validly at the SIP level, ev= en if it is corrupted or malformed at the application level. If such data i= s malformed, then it is a simple matter for the PSAP application to send an= other request. Depending on the nature of the original failure, the second = one will either suceed or not. At some point in a sequence of such failures= the PSAP will need to decide that requesting will never work, but this mec= hanism should be used for one off errors. 3) Knowing that a request for MSD is not lost.=20 The PSAP application will need to communicate with the SIP layer so that th= e PSAP application is notified if a response is not received to a request f= or an MSD in an INFO message. 4) Knowing that the initial MSD sent in the INVITE request has been receive= d.=20 I have not yet seen a discussion of this in this thread, but because it rel= ates I will raise it. This is the only point where I believe an explicit ac= knowledgement is needed, but for different reasons to what might be expecte= d. It is not needed so that the emergency user agent knows that the MSD has= been received, because a similar discussion to that in 2) above applies - = there are a number of indicators to the PSAP that it should have received a= n MSD, and if it does not get one it can request one, assuming the Info pac= kage has been negotiated. It is needed because the PSAP and the emergency u= ser agent need to know that the call has fallen back to operating in the CS= domain at some point, and therefore end to end transfer of SIP data is los= t, and therefore the CS domain mechanism of in-band data needs to be adopte= d. A mechanism is provided for in the 3GPP specifications. Regards Keith =09 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 22 August 2016 21:50 To: Christer Holmberg; Randall Gellens; Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? At 8:45 PM +0000 8/22/16, Christer Holmberg wrote: > Hi, > >>>>>> In the compromise proposal last week, each request would have=20 >>>>>> an explicit ack. I don't think we need to have >>>>>> a mechanism to tie an MSD to a specific request. The ack=20 >>>>>> acknowledges the request, and an MSD satisfies it. >>>>>> The PSAP performs a mid-call request for an MSD only when the=20 >>>>>> call taker thinks something might have >>>>>> changed. If it gets an updated MSD, it doesn't matter if it=20 >>>>>> was sent to satisfy the request or for some other >>>>>> reason (although in reality it won't be sent for any other reason= ). >>>>> >>>>> Again, I am taking about using the request protocol to request=20 >>>>> data in general. >>>>> >>>>> In my opinion, there should be a way to associate requested=20 >>>>> content with the actual request. >>>> >>>> That is another layer of protocol design. While it doesn't seem=20 >>>> necessary for MSD, it could be important for some other (as yet >>>> hypothetical) cases. >>>> >>>> If you want to address that, then I think one of the following=20 >>>> would work: >>>> >>>> 1) define an extensible body for the ACK. (E.g., a multipart >>>> body) Use it to contain the "response" to a particular request. >>>> >>>> 2) define the request to contain an identifier. Use the ACK to=20 >>>> confirm acceptance of the request and committment to follow up. >>>> Also include that identifier in any messaage(s) that are intended=20 >>>> as answers to the request. Will then have to figure out what form=20 >>>> those messages are, and how to associate the identifier with them. >>>> >>>> Of those, (2) is potentially more flexible, but also more=20 >>>> complex to design and use. >>> >>> Each request has a unique ID which is also used in the ACK to=20 >>> acknowledge that specific request. We don't have that in the MSD,=20 >>> and I don't think we need it for the MSD. We might need it for a=20 >>> future type of data, and in that case, the future type of data=20 >>> should include the ID of the request it is in response to. >> >> To add to this: the MSD is defined by CEN and encoded in ASN.1; we=20 >> can't alter it to add an ID field. Luckily, we don't actually need=20 >> the ID in the case of the MSD. > > I am not talking about adding the information to the MSD content=20 > itself - then we would have to do it for every new type of content=20 > than can be requested. I am talking about something generic in the=20 > message that is carrying the MSD. I think it's better in the data, since it's small, not all data needs it, a= nd the data can be sent in different ways. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Who's on first? _______________________________________________ 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 Tue Aug 23 06:41: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 C9C1912D18E for ; Tue, 23 Aug 2016 06:41:18 -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 zzQTu6xkEQps for ; Tue, 23 Aug 2016 06:41:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D9F8A12D0EB for ; Tue, 23 Aug 2016 06:41:14 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-ad-57bc52781b8b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 84.3D.04209.8725CB75; Tue, 23 Aug 2016 15:41:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 15:40:56 +0200 From: Christer Holmberg To: "R.Jesske@telekom.de" , "keith.drage@nokia.com" , "rg+ietf@randy.pensive.org" , "pkyzivat@alum.mit.edu" Thread-Topic: AW: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR/UP5+QAgeLKi3E2OP7uEXnNvWA== Date: Tue, 23 Aug 2016 13:40:56 +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.5.160527 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A2DEF13536B92439DC5630928CF85CC@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7n25l0J5wg847HBaNi56yWmzYcpzF YsWGA6wWTXe62Cy+P+9idGD1+Pv+A5PHkiU/mTzu3rrE5LH1zmMWj7aXCgGsUVw2Kak5mWWp Rfp2CVwZE7uXMxfsdKw4u+E0SwPjfJMuRk4OCQETiVMt79i7GLk4hATWM0rcXHOOGcJZwijx a9MvIIeDg03AQqL7nzZIXETgHKPEsql/mEG6mQVUJc41PmYBsYUFvCW+rT/JBmKLCPhIzH00 jx3C1pNYs3slK4jNAlT/dOVnMJtXwEri1axdYHMYBcQkvp9awwQxU1zi1pP5TBDXCUgs2XOe GcIWlXj5+B9YryjQzO9fZ4PdJiGgKLG8Xw6iVU/ixtQpbBC2tcSslg2sELa2xLKFr5kh1gpK nJz5hGUCo+gsJNtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQI jLyDW36r7mC8/MbxEKMAB6MSD+8C293hQqyJZcWVuYcYJTiYlUR4lwTuCRfiTUmsrEotyo8v Ks1JLT7EKM3BoiTO6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAKHZ+2fofEaLbknzPLbYSibmh dHuSqUKsYmDdcjntzC9VHwoZT03QlRKqY+W/NzGER/+2a7Pdtx3uH7R1j1Q/fLty3fGyXbLm xtsOqPe+Wfz6+f7qa9Y/MjenMFwT+L9kTh7P4RKXnY3qB59NO8o8dX/p+qk3NPfbujw+tUhl ltGH+NXrf8WI2iqxFGckGmoxFxUnAgC1HE2wuAIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 23 Aug 2016 13:41:19 -0000 Hi, Regarding fallback, I think it could be useful to add a note saying that 3GPP TS XXXXX defines how to do fallback to CS. I don=B9t think we need to say much more than that. Regards, Christer On 23/08/16 15:15, "R.Jesske@telekom.de" wrote: >Hi Keith, >You are talking about: > >4) Knowing that the initial MSD sent in the INVITE request has been >received.=20 > >... It is needed because the PSAP and the emergency user agent need to >know that the call has fallen back to operating in the CS domain at some >point, and therefore end to end transfer of SIP data is lost, and >therefore the CS domain mechanism of in-band data needs to be adopted. A >mechanism is provided for in the 3GPP specifications. > >So my question is if you see now the need to add some words with regard >to Fallback within this draft or do we need something other where we >document that? >Or is this a 3GPP task? > >Best Regards > >Roland > > >-----Urspr=FCngliche Nachricht----- >Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Drage, Keith >(Nokia - GB) >Gesendet: Dienstag, 23. August 2016 13:26 >An: Randall Gellens; Christer Holmberg; Paul Kyzivat >Cc: ecrit@ietf.org >Betreff: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > >Just finished working back over the entire thread. This discussion is >getting way too complicated and I think we need to simplify it. Working >through the issues as follows: > >1) Transactional uniqueness. > >We have a dialog. 3GPP stage 1 documents require it for all emergency >calls. The Info package is correlated with the dialog - a separate dialog >would have a separate instance of the Info package. When one defines an >application using an Info package, one has to decide what sort of >protocol is running over the top, in terms of transactional complexity. >This one is a very simply protocol where I do not believe one would ever >need two simultaneous transactions within this instance of the Info >package, and given that the result of the request is the current MSD, I >do not think it would ever matter if there were allowed to be two >requests outstanding - it does not matter if the MSD is sent in response >to request 1 or request 2. So the MSD received relates to the endpoints >identified within the dialog, and if any audit trail is required, then >the SIP timestamp header field can be utilised, but there is never a need >to relate a response to a specific request. > >As far as I am aware, there is no such parallel transactional behaviour >in the existing CS domain modem mechanism. > >2) Knowing that a response to an request for MSD is not lost. > >I agree with Paul in stating that a response to an INFO request indicates >that the data has been received, but does not indicate that it has been >processed. > >So when the emergency user agent sends an MSD in an INFO request, it will >not know for sure that the application in the PSAP has received it. I >believe it is up to the PSAP to police and resolve this issue (and we >should agree this). > >The PSAP will know that data has been received validly at the SIP level, >even if it is corrupted or malformed at the application level. If such >data is malformed, then it is a simple matter for the PSAP application to >send another request. Depending on the nature of the original failure, >the second one will either suceed or not. At some point in a sequence of >such failures the PSAP will need to decide that requesting will never >work, but this mechanism should be used for one off errors. > >3) Knowing that a request for MSD is not lost. > >The PSAP application will need to communicate with the SIP layer so that >the PSAP application is notified if a response is not received to a >request for an MSD in an INFO message. > >4) Knowing that the initial MSD sent in the INVITE request has been >received.=20 > >I have not yet seen a discussion of this in this thread, but because it >relates I will raise it. This is the only point where I believe an >explicit acknowledgement is needed, but for different reasons to what >might be expected. It is not needed so that the emergency user agent >knows that the MSD has been received, because a similar discussion to >that in 2) above applies - there are a number of indicators to the PSAP >that it should have received an MSD, and if it does not get one it can >request one, assuming the Info package has been negotiated. It is needed >because the PSAP and the emergency user agent need to know that the call >has fallen back to operating in the CS domain at some point, and >therefore end to end transfer of SIP data is lost, and therefore the CS >domain mechanism of in-band data needs to be adopted. A mechanism is >provided for in the 3GPP specifications. > >Regards > >Keith > >=09 > >-----Original Message----- >From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens >Sent: 22 August 2016 21:50 >To: Christer Holmberg; Randall Gellens; Paul Kyzivat >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > >At 8:45 PM +0000 8/22/16, Christer Holmberg wrote: > >> Hi, >> >>>>>>> In the compromise proposal last week, each request would have >>>>>>> an explicit ack. I don't think we need to have >>>>>>> a mechanism to tie an MSD to a specific request. The ack >>>>>>> acknowledges the request, and an MSD satisfies it. >>>>>>> The PSAP performs a mid-call request for an MSD only when the >>>>>>> call taker thinks something might have >>>>>>> changed. If it gets an updated MSD, it doesn't matter if it >>>>>>> was sent to satisfy the request or for some other >>>>>>> reason (although in reality it won't be sent for any other >>>>>>>reason). >>>>>> >>>>>> Again, I am taking about using the request protocol to request >>>>>> data in general. >>>>>> >>>>>> In my opinion, there should be a way to associate requested >>>>>> content with the actual request. >>>>> >>>>> That is another layer of protocol design. While it doesn't seem >>>>> necessary for MSD, it could be important for some other (as yet >>>>> hypothetical) cases. >>>>> >>>>> If you want to address that, then I think one of the following >>>>> would work: >>>>> >>>>> 1) define an extensible body for the ACK. (E.g., a multipart >>>>> body) Use it to contain the "response" to a particular request. >>>>> >>>>> 2) define the request to contain an identifier. Use the ACK to >>>>> confirm acceptance of the request and committment to follow up. >>>>> Also include that identifier in any messaage(s) that are intended >>>>> as answers to the request. Will then have to figure out what form >>>>> those messages are, and how to associate the identifier with them. >>>>> >>>>> Of those, (2) is potentially more flexible, but also more >>>>> complex to design and use. >>>> >>>> Each request has a unique ID which is also used in the ACK to >>>> acknowledge that specific request. We don't have that in the MSD, >>>> and I don't think we need it for the MSD. We might need it for a >>>> future type of data, and in that case, the future type of data >>>> should include the ID of the request it is in response to. >>> >>> To add to this: the MSD is defined by CEN and encoded in ASN.1; we >>> can't alter it to add an ID field. Luckily, we don't actually need >>> the ID in the case of the MSD. >> >> I am not talking about adding the information to the MSD content >> itself - then we would have to do it for every new type of content >> than can be requested. I am talking about something generic in the >> message that is carrying the MSD. > >I think it's better in the data, since it's small, not all data needs it, >and the data can be sent in different ways. > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- Who's on first? > >_______________________________________________ >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 Tue Aug 23 07:54: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 8AA1912DC49 for ; Tue, 23 Aug 2016 07:54:24 -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 wf-U0Va7i4SM for ; Tue, 23 Aug 2016 07:54:20 -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 C170212DA64 for ; Tue, 23 Aug 2016 07:32:53 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 76ABEFDB83934; Tue, 23 Aug 2016 14:32:48 +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 u7NEWoTt002588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 14:32:51 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 u7NEWlFB017209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Aug 2016 16:32:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 23 Aug 2016 16:32:31 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , "R.Jesske@telekom.de" , "rg+ietf@randy.pensive.org" , "pkyzivat@alum.mit.edu" Thread-Topic: AW: [Ecrit] ecall: Why do we need ACK for successful requests? Thread-Index: AQHR/UP5+QAgeLKi3E2OP7uEXnNvWKBWm1Pg Date: Tue, 23 Aug 2016 14:32:31 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF58051@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? 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, 23 Aug 2016 14:54:24 -0000 CS domain is outside the scope of the IETF work, and therefore any mention = needs to be informative. The purpose of mentioning it was to distinguish between cases where an expl= icit response is required, which is this one, versus the cases where I beli= eve we should rely on timeouts and SIP failures, and therefore no explicit = response is required. I believe the use case for CS fallback is the only case where an explicit a= pplication level response is required. Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 23 August 2016 14:41 To: R.Jesske@telekom.de; Drage, Keith (Nokia - GB); rg+ietf@randy.pensive.o= rg; pkyzivat@alum.mit.edu Cc: ecrit@ietf.org Subject: Re: AW: [Ecrit] ecall: Why do we need ACK for successful requests? Hi, Regarding fallback, I think it could be useful to add a note saying that 3G= PP TS XXXXX defines how to do fallback to CS. I don=B9t think we need to sa= y much more than that. Regards, Christer On 23/08/16 15:15, "R.Jesske@telekom.de" wrote: >Hi Keith, >You are talking about: > >4) Knowing that the initial MSD sent in the INVITE request has been >received.=20 > >... It is needed because the PSAP and the emergency user agent need to=20 >know that the call has fallen back to operating in the CS domain at=20 >some point, and therefore end to end transfer of SIP data is lost, and=20 >therefore the CS domain mechanism of in-band data needs to be adopted.=20 >A mechanism is provided for in the 3GPP specifications. > >So my question is if you see now the need to add some words with regard=20 >to Fallback within this draft or do we need something other where we=20 >document that? >Or is this a 3GPP task? > >Best Regards > >Roland > > >-----Urspr=FCngliche Nachricht----- >Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Drage, Keith=20 >(Nokia - GB) >Gesendet: Dienstag, 23. August 2016 13:26 >An: Randall Gellens; Christer Holmberg; Paul Kyzivat >Cc: ecrit@ietf.org >Betreff: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > >Just finished working back over the entire thread. This discussion is=20 >getting way too complicated and I think we need to simplify it. Working=20 >through the issues as follows: > >1) Transactional uniqueness. > >We have a dialog. 3GPP stage 1 documents require it for all emergency=20 >calls. The Info package is correlated with the dialog - a separate=20 >dialog would have a separate instance of the Info package. When one=20 >defines an application using an Info package, one has to decide what=20 >sort of protocol is running over the top, in terms of transactional comple= xity. >This one is a very simply protocol where I do not believe one would=20 >ever need two simultaneous transactions within this instance of the=20 >Info package, and given that the result of the request is the current=20 >MSD, I do not think it would ever matter if there were allowed to be=20 >two requests outstanding - it does not matter if the MSD is sent in=20 >response to request 1 or request 2. So the MSD received relates to the=20 >endpoints identified within the dialog, and if any audit trail is=20 >required, then the SIP timestamp header field can be utilised, but=20 >there is never a need to relate a response to a specific request. > >As far as I am aware, there is no such parallel transactional behaviour=20 >in the existing CS domain modem mechanism. > >2) Knowing that a response to an request for MSD is not lost. > >I agree with Paul in stating that a response to an INFO request=20 >indicates that the data has been received, but does not indicate that=20 >it has been processed. > >So when the emergency user agent sends an MSD in an INFO request, it=20 >will not know for sure that the application in the PSAP has received=20 >it. I believe it is up to the PSAP to police and resolve this issue=20 >(and we should agree this). > >The PSAP will know that data has been received validly at the SIP=20 >level, even if it is corrupted or malformed at the application level.=20 >If such data is malformed, then it is a simple matter for the PSAP=20 >application to send another request. Depending on the nature of the=20 >original failure, the second one will either suceed or not. At some=20 >point in a sequence of such failures the PSAP will need to decide that=20 >requesting will never work, but this mechanism should be used for one off = errors. > >3) Knowing that a request for MSD is not lost. > >The PSAP application will need to communicate with the SIP layer so=20 >that the PSAP application is notified if a response is not received to=20 >a request for an MSD in an INFO message. > >4) Knowing that the initial MSD sent in the INVITE request has been >received.=20 > >I have not yet seen a discussion of this in this thread, but because it=20 >relates I will raise it. This is the only point where I believe an=20 >explicit acknowledgement is needed, but for different reasons to what=20 >might be expected. It is not needed so that the emergency user agent=20 >knows that the MSD has been received, because a similar discussion to=20 >that in 2) above applies - there are a number of indicators to the PSAP=20 >that it should have received an MSD, and if it does not get one it can=20 >request one, assuming the Info package has been negotiated. It is=20 >needed because the PSAP and the emergency user agent need to know that=20 >the call has fallen back to operating in the CS domain at some point,=20 >and therefore end to end transfer of SIP data is lost, and therefore=20 >the CS domain mechanism of in-band data needs to be adopted. A=20 >mechanism is provided for in the 3GPP specifications. > >Regards > >Keith > >=09 > >-----Original Message----- >From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall=20 >Gellens >Sent: 22 August 2016 21:50 >To: Christer Holmberg; Randall Gellens; Paul Kyzivat >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] ecall: Why do we need ACK for successful requests? > >At 8:45 PM +0000 8/22/16, Christer Holmberg wrote: > >> Hi, >> >>>>>>> In the compromise proposal last week, each request would have =20 >>>>>>>an explicit ack. I don't think we need to have >>>>>>> a mechanism to tie an MSD to a specific request. The ack =20 >>>>>>>acknowledges the request, and an MSD satisfies it. >>>>>>> The PSAP performs a mid-call request for an MSD only when the =20 >>>>>>>call taker thinks something might have >>>>>>> changed. If it gets an updated MSD, it doesn't matter if it =20 >>>>>>>was sent to satisfy the request or for some other >>>>>>> reason (although in reality it won't be sent for any other=20 >>>>>>>reason). >>>>>> >>>>>> Again, I am taking about using the request protocol to request=20 >>>>>> data in general. >>>>>> >>>>>> In my opinion, there should be a way to associate requested=20 >>>>>> content with the actual request. >>>>> >>>>> That is another layer of protocol design. While it doesn't seem=20 >>>>> necessary for MSD, it could be important for some other (as yet >>>>> hypothetical) cases. >>>>> >>>>> If you want to address that, then I think one of the following=20 >>>>> would work: >>>>> >>>>> 1) define an extensible body for the ACK. (E.g., a multipart >>>>> body) Use it to contain the "response" to a particular request. >>>>> >>>>> 2) define the request to contain an identifier. Use the ACK to=20 >>>>> confirm acceptance of the request and committment to follow up. >>>>> Also include that identifier in any messaage(s) that are intended=20 >>>>> as answers to the request. Will then have to figure out what form=20 >>>>> those messages are, and how to associate the identifier with them. >>>>> >>>>> Of those, (2) is potentially more flexible, but also more=20 >>>>> complex to design and use. >>>> >>>> Each request has a unique ID which is also used in the ACK to=20 >>>> acknowledge that specific request. We don't have that in the MSD,=20 >>>> and I don't think we need it for the MSD. We might need it for a=20 >>>> future type of data, and in that case, the future type of data=20 >>>> should include the ID of the request it is in response to. >>> >>> To add to this: the MSD is defined by CEN and encoded in ASN.1; we=20 >>> can't alter it to add an ID field. Luckily, we don't actually need=20 >>> the ID in the case of the MSD. >> >> I am not talking about adding the information to the MSD content=20 >> itself - then we would have to do it for every new type of content=20 >> than can be requested. I am talking about something generic in the=20 >> message that is carrying the MSD. > >I think it's better in the data, since it's small, not all data needs=20 >it, and the data can be sent in different ways. > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- Who's on first? > >_______________________________________________ >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 Tue Aug 23 08:32:56 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 8F5B712D613 for ; Tue, 23 Aug 2016 08:32:55 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Xi38laBiFDSF for ; Tue, 23 Aug 2016 08:32:54 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 13DE212D611 for ; Tue, 23 Aug 2016 08:16:00 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-06v.sys.comcast.net with SMTP id cDPwbYhHx2NhqcDQmb5BzU; Tue, 23 Aug 2016 15:16:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with SMTP id cDQlbi6uFo5B0cDQlbUrka; Tue, 23 Aug 2016 15:16:00 +0000 To: "Drage, Keith (Nokia - GB)" , Christer Holmberg , ECRIT References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADF57BC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <64cb54ae-bc36-de9c-d858-c62b725fa9ad@alum.mit.edu> Date: Tue, 23 Aug 2016 11:15:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF57BC6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfN9OPhXl0bGYIBfU5gk7QNq48iw/UOwupf8hz4t7dZ2bKzE1JqQgC0aKl1pgJF+5SeiwgQ/02HaCsv6b73CT357K7esLWVRDLjxTt6tCeZvJsVQdWBFq 9wz3kiSe5s+7HrdzAFNwMJKFKDlR8qoAwZAcVpk0uIGDKpchSnoGWCxReUWbsV0Z4S8ux3s2FM3xkicgQENUEQpQU4984LsOjLK9eYQbDIyy60Vc8t3eDM/s c2Fy8x7ZifFob1dhS5VILjF7VXR9xJC8/GWh4t+UMak= Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 15:32:55 -0000 Just to be clear: I don't have an axe to grind here. I see multiple possible solutions that seem reasonable to me. I think they have been suggested by others along the way. OTOH, I see some proposals that I consider *wrong*. I think there is more disagreement about the rationale for particular solutions than for the specific mechanisms. I think I will just stay quiet for awhile, until you with skin in the game have a concrete (-12) revised proposal. Thanks, Paul On 8/23/16 6:10 AM, Drage, Keith (Nokia - GB) wrote: > Just to be clear, I do not agree with the supposed "compromise proposal either (I just have not got to that thread yet). I do not see any element of compromise at all. > > I essentially support Christer in what he is saying below. > > I expressed my position, and it is unchanged, in the following text (taken from the previous mail), which I believe Paul also agreed with (and I think aligns with Christer and Ivo): > > "I see some sort of supporting ecrit "application" in the PSAP and the calling UA. That supporting application initiates two independent data transport mechanisms within SIP, using RFC 7852 for the initial MSD and the data response to indicate support of MSD reception, and using RFC 6086 for any subsequent MSD. SIP itself knows nothing about the relationship between these two mechanisms, only the ecrit "application". It is the ecrit "application" that performs the combination of the data received using the two data transfer mechanisms as appropriate. > > The MSDs transferred using the two mechanisms following identical syntax and coding, but that is merely a matter of convenient definition. > > As such, use of Call-Info in INFO would be entirely inappropriate, because INFO does not transfer additional-data according to RFC 7852. > > Note that RFC 7842 is only used by ecrit in the initial INVITE transaction, and appearance in subsequent messages of any form would not be expected by the recipient PSAP." > > As such, I see no crossover with additional data at the SIP level, and because we have decided to use an Info package to carry data outside circuit switched messages, I believe the decision on any other data would follow the same route. As such I believe the use cases for additional data in INFO are limited, and not something we should be worrying about tat the moment. > > Regards > > Keith > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 23 August 2016 07:04 > To: Paul Kyzivat; Drage, Keith (Nokia - GB); ECRIT > Subject: Re: [Ecrit] Multipart with INFO > > Hi Paul, > >>> I'm afraid I see somewhat muddled thinking here, and I am sure it is >>> not mine. >>> >>> We have already agreed for the use case of ecall, that the transfer >>> of data outside of a call control message using INFO requires the >>> creation of an Info package. >> >> Since ecall isn't yet done, presumably anything is potentially subject >> to revision. > > > The new suggestion was presented as a łcompromise proposal˛. As we havenąt reached an agreement on that, I think we should step back to where we were and try to figure out another way of solving the issue. > > Đ > >> IMO what we have is a suggestion that there be an info package that >> says "I'd like to have you send me a fresh copy of X", where there is >> already an independently defined mechanism for sending X, independent >> of this info package. >> >> For MSD that mechanism is additional-info, and it happens that it is >> valid for the MSD to piggyback on an INFO response. > > > My opinion is still: > > - the INFO is associated with ecall (i.e. the INFO is sent to request, acknowledge or provide information associated with the ecall) > - the MSD is association with ecall (if we canąt even agree on that I think we need to ask for guidance outside IETF). > > Therefore the MSD has to be associated with an info package, per 6086. > > In my opinion, the MSD is not łpiggybacked random information not related to ecall˛, and if we allow it to be sent outside an info package we basically open the door for people to use INFO for *ANYTHING* without registering an Info Package. Thatąs exactly what we wanted to prevent with 6086, and as far as I remember you were heavily involved in that work, and in the years of painful to-info-or-not-to-info discussions that took place prior to that, so Iąm really surprised that you suggest something like that. But, you are of course entitled to your opinion :) > > Regards, > > Christer > > From nobody Tue Aug 23 09:28: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 11AF412D550 for ; Tue, 23 Aug 2016 09:28:07 -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 VJ1FMiPM3dNP for ; Tue, 23 Aug 2016 09:28:05 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 854DF12B075 for ; Tue, 23 Aug 2016 09:28:04 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-45-57bc7991ea93 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id DB.85.02493.1997CB75; Tue, 23 Aug 2016 18:28:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.179]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 18:28:01 +0200 From: Christer Holmberg To: Brian Rosen , "Drage, Keith (Nokia - GB)" Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+iphqNJ7oBH9k0Om6PUXgFpRgaBQeIMA///SIgCAAHCnoP///jkAgAAjmWD//+XlgACVM80AACPjKQAABFetUA== Date: Tue, 23 Aug 2016 16:28:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC3552B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1EDD290B-4DE8-46B6-B6B7-671241F8FF0C@salsgiver.com> In-Reply-To: <1EDD290B-4DE8-46B6-B6B7-671241F8FF0C@salsgiver.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbFdVHdS5Z5wg9mPrSymHdvAbtG46Cmr xYYtx1ksVmw4wOrA4vH3/QcmjyVLfjJ53L11iclj0aEfrAEsUVw2Kak5mWWpRfp2CVwZv6+I FfzKrXjwubCBcUJ2FyMnh4SAicS8g5eYuxi5OIQE1jNKvOxcxgbhLGGUOLbpHFCGg4NNwEKi +582SIOIQKRE89G/bCA2s4CDxPVty9hBbGEBDYnDE2YwQdRoSky+9oIZws6SeHrtM5jNIqAq sXrrA1YQm1fAV+L/7kZGiF3drBLblr5mAUlwCjhK3F21G6yBUUBM4vupNUwQy8Qlbj2ZzwRx tYDEkj3nmSFsUYmXj/+xQthKEmsPb2cBuZkZ6Ij1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMorOQ TJ2F0DELSccsJB0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG0sEtv612MB587niI UYCDUYmH90HYnnAh1sSy4srcQ4wSHMxKIrxKuUAh3pTEyqrUovz4otKc1OJDjNIcLErivP4v FcOFBNITS1KzU1MLUotgskwcnFINjLp5p6dv7/8a2+CxnSmvdZLKhuv7/5dcW+N822KHtCX/ LdHjxmuf7GdUOXbEh99xU4F457l1aYyKneF1XYs2aS9aeLzpfPLb1XuuyrcFPdeQjtYPWJZ4 q/v2jRsnTpidbpK8cvHl16x90xd5RpxXSvc47nfm4y7des6d3xY/s5/fOvPan5+p8aVKLMUZ iYZazEXFiQB75r/PoAIAAA== Archived-At: Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 16:28:07 -0000 SGksDQoNCj5UaGUgbm90aW9uIGF1dGhvcnMgaGF2ZSBwcm9wb3NlZCBpcyB0aGF0IHdlIGNyZWF0 ZSBhIGNvbW1hbmQgY2hhbm5lbCBmb3IgbWlkIGNhbGwgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBk ZXZpY2VzIGFuZCBQU0FQcyB1c2luZyBJTkZPLiAgVGhhdCByZXF1aXJlcyBhbiBJTkZPID5wYWNr YWdlLiAgV2UgY2FuLCBob3dldmVyLCBtYWtlIG9uZSBJTkZPIHBhY2thZ2UgdGhhdCBkZWZpbmVz IHRoaXMgcHJvdG9jb2wgYW5kIHVzZSBpdCBmb3IgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGRldmlj ZXMgY29tbXVuaWNhdGluZyB3aXRoIFBTQVBzLCBhdCBsZWFzdCB0aG9zZSB0aGF0ID5oYXZlIGEg c2ltcGxlIHJlcXVlc3QgdXBkYXRlIGNvbW1hbmQuDQoNCkNvcnJlY3QuDQoNCj5XZSBzdGFydGVk IHRoaXMgZW50aXJlIHNldCBvZiBkb2N1bWVudHMgdG8gbWFuYWdlIHNlbmRpbmcgb2YgZGF0YSBm cm9tIGRldmljZXMgdG8gUFNBUHMuICBlQ2FsbCBpcyBvbmUgZXhhbXBsZSwgYW4gYWxhcm0gaXMg YW5vdGhlci4gICBJbiBtb3N0IGNhc2VzLCB0aGUgaW5pdGlhbCBkYXRhID5hY2NvbXBhbmllcyB0 aGUgSU5WSVRFLg0KPklmIHRoZXJlIGlzIGFuIHVwZGF0ZSwgdGhlIGRldmljZSBjYW4gZGVjaWRl IHRvIHNlbmQgaXQuICBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgdGhlIFBTQVAgY2FuIHJlcXVl c3QgaXQuICAgRGlmZmVyZW50IGRldmljZXMgaGF2ZSBkaWZmZXJlbnQgZGF0YS4NCg0KQ29ycmVj dC4NCg0KPk5vIG9uZSBoYXMgYXJndWVkIHRoYXQgdGhlIGRhdGEgc2VudCB3aXRoIHRoZSBJTlZJ VEUgaXMgY2FycmllZCBhcyBBZGRpdGlvbmFsIERhdGEsIHJlcXVpcmluZyBhIHNjaGVtYSBhbmQg YSB0b2tlbiByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KQ29ycmVjdC4gVGhlIGFncmVlbWVudCBo YXMgYmVlbiB0byB1c2UgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIEFkZGl0aW9uYWwgRGF0YSBm b3IgdHJhbnNwb3J0aW5nIHRoZSBkYXRhIGluIElOVklURS4gDQoNCj4gV2XigJlyZSBhcmd1aW5n IHRoYXQgdGhlIGNoYXJhY3RlciBvZiB0aGUgZGF0YSBkb2VzbuKAmXQgY2hhbmdlIGFuZCB0aGUg c2NoZW1hIG9mIHRoZSBkYXRhIGRvZXNu4oCZdCBjaGFuZ2Ugd2hlbiB5b3Ugc2VuZA0KPiBpdCBt aWQgY2FsbCwgYW5kIGl0IGRvZXNu4oCZdCBtYXR0ZXIgd2hhdCBtZXNzYWdlIHlvdSBhdHRhY2gg aXQgdG8sIGl04oCZcyBBZGRpdGlvbmFsIERhdGEuICBXaGF0IHdlIG5lZWQgSU5GTyBmb3IgaXMg dGhlIA0KPiByZXF1ZXN0L3Jlc3BvbnNlIGNvbW1hbmQgY2hhbm5lbC4gICBZb3Ugc2VuZCBhbiBJ TkZPIHdpdGggYSByZXF1ZXN0IHVzaW5nIGFuIElORk8gcGFja2FnZSBjb25mb3JtaW5nIHRvIDYw ODYuIA0KPiBZb3UgbWF5IGdldCBhIHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0IChpbiBhbm90aGVy IElORk8pLiBUaGF04oCZcyB0aGUgSU5GTyB0cmFuc2FjdGlvbiBhbmQgaXQgc2F0aXNmaWVzIGFs bCB0aGUgcmVxdWlyZW1lbnRzDQo+IG9mIDYwODYuICA2MDg2IGlzbuKAmXQgYSBzdHJhaWdodGph Y2tldC4gIEnigJltIGhhcHB5IHRvIGdvIGdldCBzaXBwY29yZSB0byB0ZWxsIHVzIHRoZSBvYnZp b3VzOiB3ZSBjYW4gc2VuZCBhIENhbGwtSW5mbyB3aXRoIGEgDQo+IENJRCBhbmQgYSBib2R5LCBu byBtYXR0ZXIgd2hhdCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIElORk8gYW5kIHRoZSBD YWxsLUluZm8gYXJlLiAgRG8geW91IHdhbnQgbWUgdG8gYXNrIGZvciB0aGF0PyAgDQoNCkZpcnN0 LCBJJ20gaGFwcHkgdG8gdGFrZSB0aGlzIHRvIFNJUENPUkUgKEkgYWxyZWFkeSBzdWdnZXN0ZWQg dGhhdCBlYXJsaWVyKS4NCg0KSG93ZXZlciwgc2ltcGx5IGFza2luZyAiQ2FuIHdlIHNlbmQgYSBD YWxsLUluZm8gd2l0aCBhIENJRCBhbmQgYSBib2R5IiBpc24ndCB2ZXJ5IHVzZWZ1bC4NCg0KVGhl IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIElORk8gcmVxdWVzdCBpdHNlbGYsIGFuZCB0aGUgTVNE IGNvbnRlbnQgdHJhbnNwb3J0ZWQgaW4gdGhlIElORk8gcmVxdWVzdCwgYXJlIGFzc29jaWF0ZWQg d2l0aCB0aGUgc2FtZSAiYXBwbGljYXRpb24iIChlY2FsbCksIGFuZCB3aGV0aGVyIHRoZSBNU0Qg dGhlcmVmb3JlIG11c3QgYmUgc2VudCB1c2luZyBhbiBJbmZvIFBhY2thZ2UsIGFzIHN0YXRlZCBp biA2MDg2LiANCg0KPiBXZSB3YW50IHRoZSBNU0Qgb3V0c2lkZSB0aGUgSU5GTyBwYWNrYWdlIGJl Y2F1c2UgaXTigJlzIEFkZGl0aW9uYWwgRGF0YSBhbmQgc2hvdWxkIGJlIGNhcnJpZWQgd2l0aCBh IENhbGwtSW5mbyBwb2ludGluZyANCj4gdG8gdGhlIE1JTUUgdHlwZSBhbmQgc2NoZW1hIHJlZ2lz dGVyZWQgZm9yIEFkZGl0aW9uYWwgRGF0YSwganVzdCBsaWtlIGluIHRoZSBJTlZJVEUuICANCj4N Cj4gV2Ugd2FudCB0aGUgSU5GTyBwYWNrYWdlIGZvciBpdHMgY29tbWFuZCAoc2VuZCB0aGUgTVNE KSBhbmQgcmVzcG9uc2UgKEFDSykuICBUaGF0IGNhbiBvbmx5IGhhcHBlbiBtaWQtY2FsbCwgc28g SU5GTyBpcw0KPiBhcHByb3ByaWF0ZS4gIEl04oCZcyBhIHdlbGwgZGVmaW5lZCBJTkZPIHBhY2th Z2UsIGFuZCBpdCBzYXRpc2ZpZXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgNjA2OC4gIFRoZSBz YW1lIGlkZWEgd291bGQgd29yayB3aXRoIA0KPiBhbnkgZGV2aWNlIHRoYXQgbmVlZHMgc29tZSBr aW5kIG9mIGNvbW1hbmQgc3RydWN0dXJlLiAgVGhlIGV4YW1wbGUgSSBnYXZlIHdhcyDigJxzZW5k IGVsZXZhdG9ycyB0byBncm91bmQgZmxvb3LigJ0uICBUaGF0IHdvdWxkIA0KPiBuZWVkIGEgbmV3 IElORk8gcGFja2FnZSBiZWNhdXNlIHRoZSBjb21tYW5kIGlzIGRpZmZlcmVudC4gIFRoZSBlbGV2 YXRvciBzdGF0dXMgd291bGQgYmUgQWRkaXRpb25hbCBEYXRhLCBhbmQgd291bGQgYmUgc2VudCAN Cj4gaW4gYSBib2R5IHBvaW50ZWQgdG8gYnkgdGhlIENhbGwtSW5mbywganVzdCBsaWtlIGl0IHdv dWxkIGluIHRoZSBJTlZJVEU6IHNhbWUgTUlNRSB0eXBlLCBzYW1lIENvbnRlbnQtRGlzcG9zaXRp b24uICBCdXQgaWYgSSBoYWQgYSANCj4gY29udGFpbmVyIHRoYXQgc2VudCBhIGxlYWsgYWxhcm0s IGFuZCB0aGF04oCZcyBhbGwgaXQgY2FuIGRvLCB1c2luZyB0aGUgZUNhbGwgSU5GTyBwYWNrYWdl IHRvIHJlcXVlc3QgYW4gdXBkYXRlIG9mIGl0cyBkYXRhIHdvdWxkIHdvcmsgZmluZSB3aXRoIG5v IGNoYW5nZXMuDQoNCkJ1dCBJTkZPIGlzIG5vdCBqdXN0IGxpa2UgdGhlIElOVklURS4gNjA4NiBk ZWZpbmVzIHJ1bGVzIGZvciBob3cgdG8gdHJhbnNwb3J0IGNvbnRlbnQgdXNpbmcgSU5GTywgYW5k IEFkZGl0aW9uYWwgRGF0YSBjYW5ub3Qgb3ZlcnJpZGUgdGhvc2UgcnVsZXMuDQoNCj5Vc2luZyB0 aGUgSU5GTyBmb3IgY29tbWFuZC9jb250cm9sIGFuZCBBZGRpdGlvbmFsIERhdGEgZm9yIHRoZSBk YXRhIGlzIGNsZWFuIGFuZCBtYWtlcyBzZW5zZS4gIEl0IGFsbG93cyB1cyB0byByZXVzZSB0aGUg SU5GTw0KPnBhY2thZ2UgZm9yIG90aGVyIHNpbXBsZSBkZXZpY2VzLCBhbmQgY3JlYXRlIG90aGVy cyBmb3IgbW9yZSBjb21wbGV4IGRldmljZXMuICBJdCBtYWtlcyBwcm9jZXNzaW5nIGF0IHRoZSBQ U0FQIHNpbXBsZXIsIGJlY2F1c2UNCj50aGUgZGF0YSBjb21lcyB0aGUgc2FtZSB3YXkgd2hldGhl ciBpdOKAmXMgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgY2FsbCwgaXQgY29tZXMgdW5zb2xpY2l0 ZWQgb3IgaXQgY29tZXMgYXMgYSByZXNwb25zZSB0byBhIGNvbW1hbmQgdG8gc2VuZCBpdC4NCg0K SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQuIFlvdSBkb24ndCBoYXZlIHRvIHN1cHBvcnQgdGhl IE1TRCBJbmZvIFBhY2thZ2UgaW4gb3JkZXIgdG8gdXNlIHRoZSBjb21tYW5kL2NvbnRyb2wgcHJv dG9jb2wgLSBpdCdzIGRlZmluZWQgc2VwYXJhdGVseSwgb3V0c2lkZSB0aGUgTVNEIEluZm8gUGFj a2FnZS4gWW91IGNhbiB1c2UgdGhlIHByb3RvY29sIGluIHdoYXRldmVyIEluZm8gUGFja2FnZSB5 b3Ugd2FudCAtIGFuZCBpZiB5b3UgZG9uJ3QgdXNlIElORk8geW91IGRvbid0IGV2ZW4gaGF2ZSB0 byBkZWZpbmUgYW4gSW5mbyBQYWNrYWdlIGluIG9yZGVyIHRvIHVzZSBpdC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KDQpCcmlhbg0KDQoNCj4gT24gQXVnIDIyLCAyMDE2LCBhdCA2OjA1IFBN LCBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpIDxrZWl0aC5kcmFnZUBub2tpYS5jb20+IHdyb3Rl Og0KPiANCj4gSSdtIGFmcmFpZCBJIHNlZSBzb21ld2hhdCBtdWRkbGVkIHRoaW5raW5nIGhlcmUs IGFuZCBJIGFtIHN1cmUgaXQgaXMgbm90IG1pbmUuDQo+IA0KPiBXZSBoYXZlIGFscmVhZHkgYWdy ZWVkIGZvciB0aGUgdXNlIGNhc2Ugb2YgZWNhbGwsIHRoYXQgdGhlIHRyYW5zZmVyIG9mIGRhdGEg b3V0c2lkZSBvZiBhIGNhbGwgY29udHJvbCBtZXNzYWdlIHVzaW5nIElORk8gcmVxdWlyZXMgdGhl IGNyZWF0aW9uIG9mIGFuIEluZm8gcGFja2FnZS4NCj4gDQo+IEZvbGxvd2luZyB0aGF0IHVzZSBj YXNlLCBhbmQgdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBhcmd1bWVudCwgdGhlbiBhbnkgb3RoZXIg dXNlIGNhc2UgcmVxdWlyaW5nIHRvIHVzZSBJTkZPIHRvIHRyYW5zZmVyIGRhdGEgd291bGQgY3Jl YXRlIGFub3RoZXIgSW5mbyBwYWNrYWdlIGZvciB0aGUgdHJhbnNmZXIgb2YgdGhhdCBkYXRhLg0K PiANCj4gV2hpbGUgdGhlb3JldGljYWxseSwgYW4gYXJndW1lbnQgbWlnaHQgYXBwbHkgdGhhdCBp dCBpcyB2YWxpZCB0byB1c2UgYWRkaXRpb25hbCBkYXRhIGluIGFuIElORk8gbWVzc2FnZSwgSSBj YW5ub3QgY29uY2VpdmUgb2YgYSB1c2UgY2FzZSB3aGVyZSBvbmx5IHRoZXJlIGluIGFkZGl0aW9u IHRvIHRoZSBlY2FsbCBJbmZvIHBhY2thZ2UsIGFuZCBuZXZlciByZXF1aXJlZCBhdCBhbnkgb3Ro ZXIgdGltZS4gSWYgaXQgaXMgcmVxdWlyZWQgYXQgYW55IG90aGVyIHRpbWUsIHRoZW4gdGhlIHNl cGFyYXRlIEluZm8gcGFja2FnZSBtdXN0IGV4aXN0LCBhbmQgdGhlcmVmb3JlIGlmIGl0IGV4aXN0 cywgaXQgc2hvdWxkIGJlIHVzZWQgZm9yIGFsbCB0aGUgdHJhbnNmZXJzIG91dHNpZGUgb2YgY2Fs bCBjb250cm9sIG1lc3NhZ2VzLiBDb252ZXJzZWx5LCBpZiBpdCBpcyBvbmx5IHRoZXJlIHdoZW4g ZWNhbGwgdHJhbnNmZXIgZXhpc3RzLCBhbmQgbmV2ZXIgb3V0c2lkZSBpdCwgSSB3b25kZXIgd2h5 IGl0IGlzIG5vdCBwYXJ0IG9mIHRoZSBlY2FsbCBJbmZvIHBhY2thZ2UuDQo+IA0KPiBUaGUgb25s eSBleGNlcHRpb24gSSBjYW4gc2VlIHRvIHRoaXMgaXMgd2hlcmUgc29tZSBvdGhlciBwcmVleGlz dGluZyBsaW5raW5nIG1lY2hhbmlzbSBleGlzdHMsIHN1Y2ggYXMgR2VvbG9jYXRpb24sIGJ1dCBl dmVuIHRoaXMgaW4gbXkgbWluZCBjYXVzZXMgaXNzdWVzLg0KPiANCj4gUmVnYXJkcw0KPiANCj4g S2VpdGgNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVjcml0IFtt YWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0K PiBTZW50OiAxOSBBdWd1c3QgMjAxNiAyMzo1Mw0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IEVD UklUDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIE11bHRpcGFydCB3aXRoIElORk8NCj4gDQo+IE9u IDgvMTkvMTYgNjozNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+PiBIaSwNCj4+IA0K Pj4+Pj4+Pj4+IFRoZSBkaXNjdXNzaW9uIG9uIGVjYWxsIGhhcyBiZWNvbWUgcXVpdGUgaGVhdGVk LCB3aXRoIHBlb3BsZSANCj4+Pj4+Pj4+PiBkdWcgaW4gb24gYWxsIHNpZGVzLiBDYW4gd2UgY2Fs bSBpdCBkb3duIGEgYml0Pw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IElNTyBhIGNvdXBsZSBvZiBk aWZmZXJlbnQgYXBwcm9hY2hlcyBoYXZlIGJlZW4gZGVzY3JpYmVkIHRoYXQgDQo+Pj4+Pj4+Pj4g d291bGQgd29yayBhbmQgbm90IHZpb2xhdGUgYW55IHNwZWNzLiBUaGUgZGlmZmVyZW5jZXMgYmV0 d2VlbiANCj4+Pj4+Pj4+PiB0aGVzZSByZWZsZWN0IGRpZmZlcmVuY2VzIG9mIHBoaWxvc29waHkg YW5kIHRhc3RlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJIGRvbsK5dCB0aGluayB3ZSBoYXZlIGFu IGFncmVlbWVudCBvbiB0aGUgDQo+Pj4+Pj4+PiB3b3VsZC1ub3QtdmlvbGF0ZS1hbnktc3BlY3Mg cGFydC4gV2UgY2xlYXJseSBoYXZlIGRpZmZlcmVudCB2aWV3cyBvbiB3aGF0IGlzIGFsbG93ZWQg YnkgUkZDIDYwODYuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEJ1dCwgSSBkbyBhZ3JlZSB3ZSBuZWVk IHRvIHRyeSB0byBmaWd1cmUgb3V0IGhvdyB0byBtb3ZlIGZvcndhcmQuDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBPSy4gTWF5YmUgd2Ugc2hvdWxkIHN0YXJ0IHRoZXJlLg0KPj4+Pj4+PiANCj4+Pj4+Pj4g SSBndWVzcyB0aGVyZSBpcyBzb21lIGRpc3B1dGUgb24gd2hldGhlciBpdCBpcyB2YWxpZCBmb3Ig YW4gSU5GTyANCj4+Pj4+Pj4gbWVzc2FnZSB0byBjb250YWluIGEgbXVsdGlwYXJ0IGJvZHksIHdo ZXJlIG9uZSBwYXJ0IGNvbnRhaW5zIHRoZSANCj4+Pj4+Pj4gaW5mbyBwYWNrYWdlDQo+Pj4+Pj4+ IChDLUQ6IGluZm8tcGFja2FnZSkgYW5kIGFub3RoZXIgcGFydCAoQy1EOiBieS1yZWZlcmVuY2Up IGlzIA0KPj4+Pj4+PiByZWZlcmVuY2VkIGJ5IGEgY2lkOiB1cmkgaW4gc29tZSBzaXAgaGVhZGVy IGZpZWxkLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gbXkgbWluZCB0aGVyZSBpcyBubyBxdWVzdGlv biB0aGF0IHRoaXMgaXMgdmFsaWQuIERvIHlvdSANCj4+Pj4+Pj4gZGlzYWdyZWUsIGFuZCBpZiBz bywgb24gd2hhdCBiYXNpcz8NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgZGlzcHV0ZSBpcyB3aGV0aGVy IGEgbWVzc2FnZSBib2R5IG11c3QgYmUgYXNzb2NpYXRlZCB3aXRoIGFuIA0KPj4+Pj4+IEluZm8g UGFja2FnZS4NCj4+Pj4+PiANCj4+Pj4+PiBJbiBteSB2aWV3Og0KPj4+Pj4+IA0KPj4+Pj4+IC0g UkZDIDYwODYgYWxsb3dzIGJvZGllcyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIEluZm8gUGFja2Fn ZSBpbiANCj4+Pj4+PiBJTkZPcyBpbiBvcmRlciB0byBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdp dGggZXhpc3RpbmcgcHJlLTYwODYgSU5GTyB1c2FnZXMuDQo+Pj4+Pj4gLSBBbnkgTkVXIHVzYWdl IE1VU1QgYmUgYXNzb2NpYXRlZCB3aXRoIGFuIEluZm8gUGFja2FnZS4gU2VuZGluZyANCj4+Pj4+ PiBvZiBNU0QgaXMgYSBuZXcgSU5GTyB1c2FnZS4NCj4+Pj4+IA0KPj4+Pj4gSSBkaXNhZ3JlZS4g SSBmaW5kIHRoZSBmb2xsb3dpbmcgaW4gNjA4NjoNCj4+Pj4+IA0KPj4+Pj4gICAgICBOT1RFOiBB biBJTkZPIHJlcXVlc3QgY2FuIGFsc28gY29udGFpbiBvdGhlciBib2R5IHBhcnRzIHRoYXQgYXJl DQo+Pj4+PiAgICAgIG1lYW5pbmdmdWwgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGludml0ZSBk aWFsb2cgdXNhZ2UgYnV0IGFyZQ0KPj4+Pj4gICAgICBub3Qgc3BlY2lmaWNhbGx5IGFzc29jaWF0 ZWQgd2l0aCB0aGUgSU5GTyBtZXRob2QgYW5kIHRoZQ0KPj4+Pj4gICAgICBhcHBsaWNhdGlvbiBj b25jZXJuZWQuDQo+Pj4+IA0KPj4+PiBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTVNEIGlz IG5vdCBhc3NvY2lhdGVkIHdpdGggdGhlIGVjYWxsIGFwcGxpY2F0aW9uPz8/DQo+Pj4+IA0KPj4+ PiBSRkMgNjA4NiBhbHNvIHNheXM6DQo+Pj4+IA0KPj4+PiAJIkFueSBuZXcgdXNhZ2UgTVVTVCB1 c2UgdGhlIEluZm8gUGFja2FnZSBtZWNoYW5pc20gZGVmaW5lZCBpbiB0aGlzDQo+Pj4+ICAgICAg IAlzcGVjaWZpY2F0aW9uLCBzaW5jZSBpdCBkb2VzIG5vdCBzaGFyZSB0aGUgaXNzdWVzIGFzc29j aWF0ZWQgd2l0aA0KPj4+PiAgICAgICAJbGVnYWN5IElORk8gdXNhZ2UsIGFuZCBzaW5jZSBJbmZv IFBhY2thZ2VzIGNhbiBiZSByZWdpc3RlcmVkIHdpdGgNCj4+Pj4gICAgICAgCUlBTkEuIg0KPj4+ PiANCj4+Pj4gQW5kLCBpbiBteSBvcGluaW9uLCBzZW5kaW5nIG9mIE1TRCAqaXMqIHBhcnQgb2Yg dGhlIG5ldyBJTkZPIHVzYWdlLiBJdCdzIG5vdCBzb21ldGhpbmcgZWxzZSB0aGF0IHdlIGFkZCB0 byB0aGUgSU5GTy4NCj4+Pj4gDQo+Pj4+IE90aGVyd2lzZSwgd2h5IGRpZCB3ZSBkbyBSRkMgNjA4 NiBpbiB0aGUgZmlyc3QgcGxhY2U/IFdlIGNhbiBqdXN0IGFsbG93IHBlb3BsZSB0byB1c2UgLSBh bmQgc3RhbmRhcmRpemUgc3VjaCB1c2FnZSAtIGFzIGluIHRoZSBwYXN0LCB3aXRoIGFsbCB0aGUg cHJvYmxlbXMgYXNzb2NpYXRlZCwganVzdCA+PiBieSBzYXlpbmcgdGhlIGNvbnRlbnQgaXMgbm90 IGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwbGljYXRpb24uLi4NCj4+PiANCj4+PiBXZSBkaWQgNjA4 NiBzbyB0aGF0IHRoZSB1c2FnZSBpZiBJTkZPIHRvIGNhcnJ5IGFzc29jaWF0ZWQgYm9keSBwYXJ0 cyBjb3VsZCBiZSBuZWdvdGlhdGVkLg0KPj4gDQo+PiBZb3UgZG9uJ3QgbmVlZCA2MDg2IHRvIGlu ZGljYXRlIHdoYXQgYm9keSBwYXJ0cyB5b3Ugc3VwcG9ydC4gVGhlcmUgaXMgYSBTSVAgaGVhZGVy IGZpZWxkIGZvciB0aGF0Lg0KPj4gDQo+PiBXZSBkZWZpbmVkIDYwODYgc28gdGhhdCB5b3UgY291 bGQgZGVmaW5lIGFuZCBpbmRpY2F0ZSB0aGUgc2VtYW50aWNzIGFzc29jaWF0ZWQgd2l0aCB0aGUg SU5GTyByZXF1ZXN0IChpbmNsdWRpbmcgYm9keSBwYXJ0cyksIGFuZCB0byBuZWdvdGlhdGUgc3Vw cG9ydCBvZiBwcm9jZXNzaW5nIHRoYXQgc2VtYW50aWNzLg0KPj4gDQo+Pj4gSU1PIGlmIHNvbWV0 aGluZyBpcyBpbiB0aGUgbWVzc2FnZSwgYnV0IG5vdCBpbiB0aGUgaW5mby1wYWNrYWdlIGJvZHkg DQo+Pj4gcGFydCwgdGhlbiBpdCBpc24ndCBzcGVjaWZpY2FsbHkgcGFydCBvZiB0aGUgSU5GTyB1 c2FnZS4gRm9yIGluc3RhbmNlLCBhbnkgcmFuZG9tIGhlYWRlciBmaWVsZCB0aGF0IHlvdSBoYXBw ZW4gdG8gaW5jbHVkZSBpc24ndC4NCj4+IA0KPj4gTVNEIGlzIG5vdCAic29tZXRoaW5nIHJhbmRv bSB0aGF0IHlvdSBoYXBwZW4gdG8gaW5jbHVkZSIgaW4gYW4gSU5GTyBhc3NvY2lhdGVkIHdpdGgg dGhlIGVjYWxsIGFwcGxpY2F0aW9uLg0KPj4gDQo+PiBPciwgYWdhaW4sIGFyZSB5b3Ugc2F5aW5n IHRoYXQgTVNEIGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggdGhlIGVjYWxsIGFwcGxpY2F0aW9uPw0K PiANCj4gSSJtIHNheWluZyB0aGF0IEkgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBhbiBlY2Fs bCAqYXBwbGljYXRpb24qLiBJIGFncmVlIHRoZXJlIG1pZ2h0IGJlIG9uZSwgYnV0IHdlIGFyZW4n dCBkZWZpbmluZyB0aGF0LiBJIGRvIGtub3cgdGhlIE1TRCBpcyBhc3NvY2lhdGVkIHdpdGggYSBj YWxsLWluZm8gaGVhZGVyIGZpZWxkLiBJIGNhbiBwb3RlbnRpYWxseSBwdXQgdGhhdCBjYWxsLWlu Zm8gaW4gYW55IG1lc3NhZ2UgSSBsaWtlICh0aGF0IHBlcm1pdHMgY2FsbC1pbmZvKS4NCj4gDQo+ IElmIHRoZXJlIGhhcHBlbnMgdG8gYmUgYW4gZWNhbGwgYXBwbGljYXRpb24sIHRoZW4gdGhlIE1T RCBtaWdodCBpbmRlZWQgDQo+IGVuZCB1cCBhdCB0aGF0IGFwcGxpY2F0aW9uLiBJIHdvdWxkIGV4 cGVjdCB0aGF0IHRoZSBhcHBsaWNhdGlvbiB3aWxsIA0KPiBiZQ0KPiAqbG9vc2VseSogY291cGxl ZCB0byB0aGUgc2lwIHNlc3Npb24uIExvdHMgb2Ygb3RoZXIgdGhpbmdzIG1heSBoYXBwZW4gaW4g dGhhdCBzZXNzaW9uIHRoYXQgbWF5IG9yIG1heSBub3QgYmUgYW50aWNpcGF0ZWQgYnkgdGhlIGFw cGxpY2F0aW9uLiANCj4gVGhvc2UgdGhpbmdzIG1heSBiZSBwcm9jZXNzZWQgYnkgb3RoZXIgVUEg YXBwbGljYXRpb24gc29mdHdhcmUuIFNvIHRoZSBlY2FsbCBhcHBsaWNhdGlvbiBpcyBqdXN0IG9u ZSAqdXNlciogb2YgdGhlIHNpcCBzZXNzaW9uLg0KPiANCj4gT2YgY291cnNlIHRoZSBhcHBsaWNh dGlvbiBlbnZpcm9ubWVudCBtYXkgY29uc3RyYWluIHRoZSBwb3NzaWJpbGl0aWVzIGluIHNvbWUg d2F5LiBCdXQgSSB0aGluayB0aGF0IGlzIG91dHNpZGUgb2Ygb3VyIHNjb3BlIGhlcmUuDQo+IA0K PiAJVGhhbmtzLA0KPiAJUGF1bA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1h aWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Tue Aug 23 22:53: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 38FF112D579 for ; Tue, 23 Aug 2016 22:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 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, RP_MATCHES_RCVD=-0.548] 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 aNmQ54DiGM-y for ; Tue, 23 Aug 2016 22:53:37 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC7812D5F0 for ; Tue, 23 Aug 2016 22:53:36 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 24 Aug 2016 07:53:33 +0200 X-IronPort-AV: E=Sophos;i="5.28,569,1464645600"; d="scan'208";a="946330906" Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 24 Aug 2016 07:53:32 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 24 Aug 2016 07:53:32 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Wed, 24 Aug 2016 07:53:32 +0200 From: To: , , Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR+movstynZmUIpUWoyOVvfzwPC6BQeIMA///SIgCAAHCnoP///jkAgAAjmWD//+XlgACVM80AACPjKQAABFetUAAeV2mw Date: Wed, 24 Aug 2016 05:53:32 +0000 Message-ID: <4d72d2808e9d4db5ac32d33e48cfb1e1@HE105660.emea1.cds.t-internal.com> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1EDD290B-4DE8-46B6-B6B7-671241F8FF0C@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC3552B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC3552B@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.244.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 05:53:40 -0000 SGksDQpMb29raW5nIG9uIENocmlzdGVyJ3MgQ29tbWVudDoNCg0KPlRoZSBxdWVzdGlvbiBpcyB3 aGV0aGVyIHRoZSBJTkZPIHJlcXVlc3QgaXRzZWxmLCBhbmQgdGhlIE1TRCBjb250ZW50IHRyYW5z cG9ydGVkIGluIHRoZSBJTkZPIHJlcXVlc3QsIGFyZSA+YXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1l ICJhcHBsaWNhdGlvbiIgKGVjYWxsKSwgYW5kIHdoZXRoZXIgdGhlIE1TRCB0aGVyZWZvcmUgbXVz dCBiZSBzZW50IHVzaW5nIGFuIEluZm8gPlBhY2thZ2UsIGFzIHN0YXRlZCBpbiA2MDg2Lg0KDQpE aXNjdXNzaW5nIHRoaXMgYWxsIHRoZSB0aW1lIEknbSB3b25kZXJpbmcgaWYgd2UgY2Fubm90IGNv bWUgdXAgd2l0aCBzb21lIHRleHQgZGVzY3JpYmluZyB0aGUgImVDYWxsIiB1c2UgY2FzZSB3aGVu IHVzaW5nIElORk8gd2l0aCBhZGRpdGlvbmFsIGRhdGEgZm9yIHRoZSBlQ2FsbCBzY2VuYXJpby4g QW5kIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgYXBwbGljYXRpb24gaGFzIHRvIGNvcnJlbGF0ZSB0 aGUgaW5mb3JtYXRpb24uDQpJIHRoaW5rIGFsbCBvdGhlciBjYXNlcyBhcmUgb3V0IG9mIHNjb3Bl LiANCg0KT3IgSSdtIHdyb25nPw0KDQpCZXN0IHJlZ2FyZHMNCg0KUm9sYW5kDQoNCg0KDQoNCi0t LS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogRWNyaXQgW21haWx0bzplY3Jp dC1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBDaHJpc3RlciBIb2xtYmVyZw0KR2Vz ZW5kZXQ6IERpZW5zdGFnLCAyMy4gQXVndXN0IDIwMTYgMTg6MjgNCkFuOiBCcmlhbiBSb3Nlbjsg RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKQ0KQ2M6IEVDUklUDQpCZXRyZWZmOiBSZTogW0Vjcml0 XSBNdWx0aXBhcnQgd2l0aCBJTkZPDQoNCkhpLA0KDQo+VGhlIG5vdGlvbiBhdXRob3JzIGhhdmUg cHJvcG9zZWQgaXMgdGhhdCB3ZSBjcmVhdGUgYSBjb21tYW5kIGNoYW5uZWwgZm9yIG1pZCBjYWxs IGNvbW11bmljYXRpb25zIGJldHdlZW4gZGV2aWNlcyBhbmQgUFNBUHMgdXNpbmcgSU5GTy4gIFRo YXQgcmVxdWlyZXMgYW4gSU5GTyA+cGFja2FnZS4gIFdlIGNhbiwgaG93ZXZlciwgbWFrZSBvbmUg SU5GTyBwYWNrYWdlIHRoYXQgZGVmaW5lcyB0aGlzIHByb3RvY29sIGFuZCB1c2UgaXQgZm9yIG11 bHRpcGxlIGluc3RhbmNlcyBvZiBkZXZpY2VzIGNvbW11bmljYXRpbmcgd2l0aCBQU0FQcywgYXQg bGVhc3QgdGhvc2UgdGhhdCA+aGF2ZSBhIHNpbXBsZSByZXF1ZXN0IHVwZGF0ZSBjb21tYW5kLg0K DQpDb3JyZWN0Lg0KDQo+V2Ugc3RhcnRlZCB0aGlzIGVudGlyZSBzZXQgb2YgZG9jdW1lbnRzIHRv IG1hbmFnZSBzZW5kaW5nIG9mIGRhdGEgZnJvbSBkZXZpY2VzIHRvIFBTQVBzLiAgZUNhbGwgaXMg b25lIGV4YW1wbGUsIGFuIGFsYXJtIGlzIGFub3RoZXIuICAgSW4gbW9zdCBjYXNlcywgdGhlIGlu aXRpYWwgZGF0YSA+YWNjb21wYW5pZXMgdGhlIElOVklURS4NCj5JZiB0aGVyZSBpcyBhbiB1cGRh dGUsIHRoZSBkZXZpY2UgY2FuIGRlY2lkZSB0byBzZW5kIGl0LiAgSXQgaXMgYWxzbyBwb3NzaWJs ZSB0aGF0IHRoZSBQU0FQIGNhbiByZXF1ZXN0IGl0LiAgIERpZmZlcmVudCBkZXZpY2VzIGhhdmUg ZGlmZmVyZW50IGRhdGEuDQoNCkNvcnJlY3QuDQoNCj5ObyBvbmUgaGFzIGFyZ3VlZCB0aGF0IHRo ZSBkYXRhIHNlbnQgd2l0aCB0aGUgSU5WSVRFIGlzIGNhcnJpZWQgYXMgQWRkaXRpb25hbCBEYXRh LCByZXF1aXJpbmcgYSBzY2hlbWEgYW5kIGEgdG9rZW4gcmVnaXN0ZXJlZCB3aXRoIElBTkEuDQoN CkNvcnJlY3QuIFRoZSBhZ3JlZW1lbnQgaGFzIGJlZW4gdG8gdXNlIHRoZSBtZWNoYW5pc20gZGVm aW5lZCBpbiBBZGRpdGlvbmFsIERhdGEgZm9yIHRyYW5zcG9ydGluZyB0aGUgZGF0YSBpbiBJTlZJ VEUuIA0KDQo+IFdl4oCZcmUgYXJndWluZyB0aGF0IHRoZSBjaGFyYWN0ZXIgb2YgdGhlIGRhdGEg ZG9lc27igJl0IGNoYW5nZSBhbmQgdGhlIA0KPiBzY2hlbWEgb2YgdGhlIGRhdGEgZG9lc27igJl0 IGNoYW5nZSB3aGVuIHlvdSBzZW5kIGl0IG1pZCBjYWxsLCBhbmQgaXQgZG9lc27igJl0IG1hdHRl ciB3aGF0IG1lc3NhZ2UgeW91IGF0dGFjaCBpdCB0bywgaXTigJlzIEFkZGl0aW9uYWwgRGF0YS4g IFdoYXQgd2UgbmVlZCBJTkZPIGZvciBpcyB0aGUNCj4gcmVxdWVzdC9yZXNwb25zZSBjb21tYW5k IGNoYW5uZWwuICAgWW91IHNlbmQgYW4gSU5GTyB3aXRoIGEgcmVxdWVzdCB1c2luZyBhbiBJTkZP IHBhY2thZ2UgY29uZm9ybWluZyB0byA2MDg2LiANCj4gWW91IG1heSBnZXQgYSByZXNwb25zZSB0 byB0aGUgcmVxdWVzdCAoaW4gYW5vdGhlciBJTkZPKS4gVGhhdOKAmXMgdGhlIA0KPiBJTkZPIHRy YW5zYWN0aW9uIGFuZCBpdCBzYXRpc2ZpZXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgNjA4Ni4g IDYwODYgDQo+IGlzbuKAmXQgYSBzdHJhaWdodGphY2tldC4gIEnigJltIGhhcHB5IHRvIGdvIGdl dCBzaXBwY29yZSB0byB0ZWxsIHVzIHRoZSBvYnZpb3VzOiB3ZSBjYW4gc2VuZCBhIENhbGwtSW5m byB3aXRoIGEgQ0lEIGFuZCBhIGJvZHksIG5vIG1hdHRlciB3aGF0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGUgSU5GTyBhbmQgdGhlIENhbGwtSW5mbyBhcmUuICBEbyB5b3Ugd2FudCBtZSB0 byBhc2sgZm9yIHRoYXQ/DQoNCkZpcnN0LCBJJ20gaGFwcHkgdG8gdGFrZSB0aGlzIHRvIFNJUENP UkUgKEkgYWxyZWFkeSBzdWdnZXN0ZWQgdGhhdCBlYXJsaWVyKS4NCg0KSG93ZXZlciwgc2ltcGx5 IGFza2luZyAiQ2FuIHdlIHNlbmQgYSBDYWxsLUluZm8gd2l0aCBhIENJRCBhbmQgYSBib2R5IiBp c24ndCB2ZXJ5IHVzZWZ1bC4NCg0KVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIElORk8gcmVx dWVzdCBpdHNlbGYsIGFuZCB0aGUgTVNEIGNvbnRlbnQgdHJhbnNwb3J0ZWQgaW4gdGhlIElORk8g cmVxdWVzdCwgYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSAiYXBwbGljYXRpb24iIChlY2Fs bCksIGFuZCB3aGV0aGVyIHRoZSBNU0QgdGhlcmVmb3JlIG11c3QgYmUgc2VudCB1c2luZyBhbiBJ bmZvIFBhY2thZ2UsIGFzIHN0YXRlZCBpbiA2MDg2LiANCg0KPiBXZSB3YW50IHRoZSBNU0Qgb3V0 c2lkZSB0aGUgSU5GTyBwYWNrYWdlIGJlY2F1c2UgaXTigJlzIEFkZGl0aW9uYWwgRGF0YSANCj4g YW5kIHNob3VsZCBiZSBjYXJyaWVkIHdpdGggYSBDYWxsLUluZm8gcG9pbnRpbmcgdG8gdGhlIE1J TUUgdHlwZSBhbmQgc2NoZW1hIHJlZ2lzdGVyZWQgZm9yIEFkZGl0aW9uYWwgRGF0YSwganVzdCBs aWtlIGluIHRoZSBJTlZJVEUuDQo+DQo+IFdlIHdhbnQgdGhlIElORk8gcGFja2FnZSBmb3IgaXRz IGNvbW1hbmQgKHNlbmQgdGhlIE1TRCkgYW5kIHJlc3BvbnNlIA0KPiAoQUNLKS4gIFRoYXQgY2Fu IG9ubHkgaGFwcGVuIG1pZC1jYWxsLCBzbyBJTkZPIGlzIGFwcHJvcHJpYXRlLiAgSXTigJlzIGEg DQo+IHdlbGwgZGVmaW5lZCBJTkZPIHBhY2thZ2UsIGFuZCBpdCBzYXRpc2ZpZXMgYWxsIHRoZSBy ZXF1aXJlbWVudHMgb2YgDQo+IDYwNjguICBUaGUgc2FtZSBpZGVhIHdvdWxkIHdvcmsgd2l0aCBh bnkgZGV2aWNlIHRoYXQgbmVlZHMgc29tZSBraW5kIA0KPiBvZiBjb21tYW5kIHN0cnVjdHVyZS4g IFRoZSBleGFtcGxlIEkgZ2F2ZSB3YXMg4oCcc2VuZCBlbGV2YXRvcnMgdG8gDQo+IGdyb3VuZCBm bG9vcuKAnS4gIFRoYXQgd291bGQgbmVlZCBhIG5ldyBJTkZPIHBhY2thZ2UgYmVjYXVzZSB0aGUg Y29tbWFuZCBpcyBkaWZmZXJlbnQuICBUaGUgZWxldmF0b3Igc3RhdHVzIHdvdWxkIGJlIEFkZGl0 aW9uYWwgRGF0YSwgYW5kIHdvdWxkIGJlIHNlbnQgaW4gYSBib2R5IHBvaW50ZWQgdG8gYnkgdGhl IENhbGwtSW5mbywganVzdCBsaWtlIGl0IHdvdWxkIGluIHRoZSBJTlZJVEU6IHNhbWUgTUlNRSB0 eXBlLCBzYW1lIENvbnRlbnQtRGlzcG9zaXRpb24uICBCdXQgaWYgSSBoYWQgYSBjb250YWluZXIg dGhhdCBzZW50IGEgbGVhayBhbGFybSwgYW5kIHRoYXTigJlzIGFsbCBpdCBjYW4gZG8sIHVzaW5n IHRoZSBlQ2FsbCBJTkZPIHBhY2thZ2UgdG8gcmVxdWVzdCBhbiB1cGRhdGUgb2YgaXRzIGRhdGEg d291bGQgd29yayBmaW5lIHdpdGggbm8gY2hhbmdlcy4NCg0KQnV0IElORk8gaXMgbm90IGp1c3Qg bGlrZSB0aGUgSU5WSVRFLiA2MDg2IGRlZmluZXMgcnVsZXMgZm9yIGhvdyB0byB0cmFuc3BvcnQg Y29udGVudCB1c2luZyBJTkZPLCBhbmQgQWRkaXRpb25hbCBEYXRhIGNhbm5vdCBvdmVycmlkZSB0 aG9zZSBydWxlcy4NCg0KPlVzaW5nIHRoZSBJTkZPIGZvciBjb21tYW5kL2NvbnRyb2wgYW5kIEFk ZGl0aW9uYWwgRGF0YSBmb3IgdGhlIGRhdGEgaXMgDQo+Y2xlYW4gYW5kIG1ha2VzIHNlbnNlLiAg SXQgYWxsb3dzIHVzIHRvIHJldXNlIHRoZSBJTkZPIHBhY2thZ2UgZm9yIA0KPm90aGVyIHNpbXBs ZSBkZXZpY2VzLCBhbmQgY3JlYXRlIG90aGVycyBmb3IgbW9yZSBjb21wbGV4IGRldmljZXMuICBJ dCBtYWtlcyBwcm9jZXNzaW5nIGF0IHRoZSBQU0FQIHNpbXBsZXIsIGJlY2F1c2UgdGhlIGRhdGEg Y29tZXMgdGhlIHNhbWUgd2F5IHdoZXRoZXIgaXTigJlzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhl IGNhbGwsIGl0IGNvbWVzIHVuc29saWNpdGVkIG9yIGl0IGNvbWVzIGFzIGEgcmVzcG9uc2UgdG8g YSBjb21tYW5kIHRvIHNlbmQgaXQuDQoNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kLiBZb3Ug ZG9uJ3QgaGF2ZSB0byBzdXBwb3J0IHRoZSBNU0QgSW5mbyBQYWNrYWdlIGluIG9yZGVyIHRvIHVz ZSB0aGUgY29tbWFuZC9jb250cm9sIHByb3RvY29sIC0gaXQncyBkZWZpbmVkIHNlcGFyYXRlbHks IG91dHNpZGUgdGhlIE1TRCBJbmZvIFBhY2thZ2UuIFlvdSBjYW4gdXNlIHRoZSBwcm90b2NvbCBp biB3aGF0ZXZlciBJbmZvIFBhY2thZ2UgeW91IHdhbnQgLSBhbmQgaWYgeW91IGRvbid0IHVzZSBJ TkZPIHlvdSBkb24ndCBldmVuIGhhdmUgdG8gZGVmaW5lIGFuIEluZm8gUGFja2FnZSBpbiBvcmRl ciB0byB1c2UgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KQnJpYW4NCg0KDQo+IE9u IEF1ZyAyMiwgMjAxNiwgYXQgNjowNSBQTSwgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSA8a2Vp dGguZHJhZ2VAbm9raWEuY29tPiB3cm90ZToNCj4gDQo+IEknbSBhZnJhaWQgSSBzZWUgc29tZXdo YXQgbXVkZGxlZCB0aGlua2luZyBoZXJlLCBhbmQgSSBhbSBzdXJlIGl0IGlzIG5vdCBtaW5lLg0K PiANCj4gV2UgaGF2ZSBhbHJlYWR5IGFncmVlZCBmb3IgdGhlIHVzZSBjYXNlIG9mIGVjYWxsLCB0 aGF0IHRoZSB0cmFuc2ZlciBvZiBkYXRhIG91dHNpZGUgb2YgYSBjYWxsIGNvbnRyb2wgbWVzc2Fn ZSB1c2luZyBJTkZPIHJlcXVpcmVzIHRoZSBjcmVhdGlvbiBvZiBhbiBJbmZvIHBhY2thZ2UuDQo+ IA0KPiBGb2xsb3dpbmcgdGhhdCB1c2UgY2FzZSwgYW5kIHVzaW5nIGV4YWN0bHkgdGhlIHNhbWUg YXJndW1lbnQsIHRoZW4gYW55IG90aGVyIHVzZSBjYXNlIHJlcXVpcmluZyB0byB1c2UgSU5GTyB0 byB0cmFuc2ZlciBkYXRhIHdvdWxkIGNyZWF0ZSBhbm90aGVyIEluZm8gcGFja2FnZSBmb3IgdGhl IHRyYW5zZmVyIG9mIHRoYXQgZGF0YS4NCj4gDQo+IFdoaWxlIHRoZW9yZXRpY2FsbHksIGFuIGFy Z3VtZW50IG1pZ2h0IGFwcGx5IHRoYXQgaXQgaXMgdmFsaWQgdG8gdXNlIGFkZGl0aW9uYWwgZGF0 YSBpbiBhbiBJTkZPIG1lc3NhZ2UsIEkgY2Fubm90IGNvbmNlaXZlIG9mIGEgdXNlIGNhc2Ugd2hl cmUgb25seSB0aGVyZSBpbiBhZGRpdGlvbiB0byB0aGUgZWNhbGwgSW5mbyBwYWNrYWdlLCBhbmQg bmV2ZXIgcmVxdWlyZWQgYXQgYW55IG90aGVyIHRpbWUuIElmIGl0IGlzIHJlcXVpcmVkIGF0IGFu eSBvdGhlciB0aW1lLCB0aGVuIHRoZSBzZXBhcmF0ZSBJbmZvIHBhY2thZ2UgbXVzdCBleGlzdCwg YW5kIHRoZXJlZm9yZSBpZiBpdCBleGlzdHMsIGl0IHNob3VsZCBiZSB1c2VkIGZvciBhbGwgdGhl IHRyYW5zZmVycyBvdXRzaWRlIG9mIGNhbGwgY29udHJvbCBtZXNzYWdlcy4gQ29udmVyc2VseSwg aWYgaXQgaXMgb25seSB0aGVyZSB3aGVuIGVjYWxsIHRyYW5zZmVyIGV4aXN0cywgYW5kIG5ldmVy IG91dHNpZGUgaXQsIEkgd29uZGVyIHdoeSBpdCBpcyBub3QgcGFydCBvZiB0aGUgZWNhbGwgSW5m byBwYWNrYWdlLg0KPiANCj4gVGhlIG9ubHkgZXhjZXB0aW9uIEkgY2FuIHNlZSB0byB0aGlzIGlz IHdoZXJlIHNvbWUgb3RoZXIgcHJlZXhpc3RpbmcgbGlua2luZyBtZWNoYW5pc20gZXhpc3RzLCBz dWNoIGFzIEdlb2xvY2F0aW9uLCBidXQgZXZlbiB0aGlzIGluIG15IG1pbmQgY2F1c2VzIGlzc3Vl cy4NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEtlaXRoDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBFY3JpdCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4gU2VudDogMTkgQXVndXN0IDIwMTYgMjM6NTMNCj4g VG86IENocmlzdGVyIEhvbG1iZXJnOyBFQ1JJVA0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBNdWx0 aXBhcnQgd2l0aCBJTkZPDQo+IA0KPiBPbiA4LzE5LzE2IDY6MzYgUE0sIENocmlzdGVyIEhvbG1i ZXJnIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+Pj4+Pj4+PiBUaGUgZGlzY3Vzc2lvbiBvbiBlY2Fs bCBoYXMgYmVjb21lIHF1aXRlIGhlYXRlZCwgd2l0aCBwZW9wbGUgDQo+Pj4+Pj4+Pj4gZHVnIGlu IG9uIGFsbCBzaWRlcy4gQ2FuIHdlIGNhbG0gaXQgZG93biBhIGJpdD8NCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiBJTU8gYSBjb3VwbGUgb2YgZGlmZmVyZW50IGFwcHJvYWNoZXMgaGF2ZSBiZWVuIGRl c2NyaWJlZCB0aGF0IA0KPj4+Pj4+Pj4+IHdvdWxkIHdvcmsgYW5kIG5vdCB2aW9sYXRlIGFueSBz cGVjcy4gVGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gDQo+Pj4+Pj4+Pj4gdGhlc2UgcmVmbGVjdCBk aWZmZXJlbmNlcyBvZiBwaGlsb3NvcGh5IGFuZCB0YXN0ZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g SSBkb27CuXQgdGhpbmsgd2UgaGF2ZSBhbiBhZ3JlZW1lbnQgb24gdGhlIA0KPj4+Pj4+Pj4gd291 bGQtbm90LXZpb2xhdGUtYW55LXNwZWNzIHBhcnQuIFdlIGNsZWFybHkgaGF2ZSBkaWZmZXJlbnQg dmlld3Mgb24gd2hhdCBpcyBhbGxvd2VkIGJ5IFJGQyA2MDg2Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBCdXQsIEkgZG8gYWdyZWUgd2UgbmVlZCB0byB0cnkgdG8gZmlndXJlIG91dCBob3cgdG8gbW92 ZSBmb3J3YXJkLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gT0suIE1heWJlIHdlIHNob3VsZCBzdGFydCB0 aGVyZS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgZ3Vlc3MgdGhlcmUgaXMgc29tZSBkaXNwdXRlIG9u IHdoZXRoZXIgaXQgaXMgdmFsaWQgZm9yIGFuIElORk8gDQo+Pj4+Pj4+IG1lc3NhZ2UgdG8gY29u dGFpbiBhIG11bHRpcGFydCBib2R5LCB3aGVyZSBvbmUgcGFydCBjb250YWlucyB0aGUgDQo+Pj4+ Pj4+IGluZm8gcGFja2FnZQ0KPj4+Pj4+PiAoQy1EOiBpbmZvLXBhY2thZ2UpIGFuZCBhbm90aGVy IHBhcnQgKEMtRDogYnktcmVmZXJlbmNlKSBpcyANCj4+Pj4+Pj4gcmVmZXJlbmNlZCBieSBhIGNp ZDogdXJpIGluIHNvbWUgc2lwIGhlYWRlciBmaWVsZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEluIG15 IG1pbmQgdGhlcmUgaXMgbm8gcXVlc3Rpb24gdGhhdCB0aGlzIGlzIHZhbGlkLiBEbyB5b3UgDQo+ Pj4+Pj4+IGRpc2FncmVlLCBhbmQgaWYgc28sIG9uIHdoYXQgYmFzaXM/DQo+Pj4+Pj4gDQo+Pj4+ Pj4gVGhlIGRpc3B1dGUgaXMgd2hldGhlciBhIG1lc3NhZ2UgYm9keSBtdXN0IGJlIGFzc29jaWF0 ZWQgd2l0aCBhbiANCj4+Pj4+PiBJbmZvIFBhY2thZ2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSW4gbXkg dmlldzoNCj4+Pj4+PiANCj4+Pj4+PiAtIFJGQyA2MDg2IGFsbG93cyBib2RpZXMgbm90IGFzc29j aWF0ZWQgd2l0aCBhbiBJbmZvIFBhY2thZ2UgaW4gDQo+Pj4+Pj4gSU5GT3MgaW4gb3JkZXIgdG8g YmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHByZS02MDg2IElORk8gdXNhZ2Vz Lg0KPj4+Pj4+IC0gQW55IE5FVyB1c2FnZSBNVVNUIGJlIGFzc29jaWF0ZWQgd2l0aCBhbiBJbmZv IFBhY2thZ2UuIFNlbmRpbmcgDQo+Pj4+Pj4gb2YgTVNEIGlzIGEgbmV3IElORk8gdXNhZ2UuDQo+ Pj4+PiANCj4+Pj4+IEkgZGlzYWdyZWUuIEkgZmluZCB0aGUgZm9sbG93aW5nIGluIDYwODY6DQo+ Pj4+PiANCj4+Pj4+ICAgICAgTk9URTogQW4gSU5GTyByZXF1ZXN0IGNhbiBhbHNvIGNvbnRhaW4g b3RoZXIgYm9keSBwYXJ0cyB0aGF0IGFyZQ0KPj4+Pj4gICAgICBtZWFuaW5nZnVsIHdpdGhpbiB0 aGUgY29udGV4dCBvZiBhbiBpbnZpdGUgZGlhbG9nIHVzYWdlIGJ1dCBhcmUNCj4+Pj4+ICAgICAg bm90IHNwZWNpZmljYWxseSBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gbWV0aG9kIGFuZCB0aGUN Cj4+Pj4+ICAgICAgYXBwbGljYXRpb24gY29uY2VybmVkLg0KPj4+PiANCj4+Pj4gU28sIHlvdSBh cmUgc2F5aW5nIHRoYXQgdGhlIE1TRCBpcyBub3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBlY2FsbCBh cHBsaWNhdGlvbj8/Pw0KPj4+PiANCj4+Pj4gUkZDIDYwODYgYWxzbyBzYXlzOg0KPj4+PiANCj4+ Pj4gCSJBbnkgbmV3IHVzYWdlIE1VU1QgdXNlIHRoZSBJbmZvIFBhY2thZ2UgbWVjaGFuaXNtIGRl ZmluZWQgaW4gdGhpcw0KPj4+PiAgICAgICAJc3BlY2lmaWNhdGlvbiwgc2luY2UgaXQgZG9lcyBu b3Qgc2hhcmUgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGgNCj4+Pj4gICAgICAgCWxlZ2FjeSBJ TkZPIHVzYWdlLCBhbmQgc2luY2UgSW5mbyBQYWNrYWdlcyBjYW4gYmUgcmVnaXN0ZXJlZCB3aXRo DQo+Pj4+ICAgICAgIAlJQU5BLiINCj4+Pj4gDQo+Pj4+IEFuZCwgaW4gbXkgb3Bpbmlvbiwgc2Vu ZGluZyBvZiBNU0QgKmlzKiBwYXJ0IG9mIHRoZSBuZXcgSU5GTyB1c2FnZS4gSXQncyBub3Qgc29t ZXRoaW5nIGVsc2UgdGhhdCB3ZSBhZGQgdG8gdGhlIElORk8uDQo+Pj4+IA0KPj4+PiBPdGhlcndp c2UsIHdoeSBkaWQgd2UgZG8gUkZDIDYwODYgaW4gdGhlIGZpcnN0IHBsYWNlPyBXZSBjYW4ganVz dCBhbGxvdyBwZW9wbGUgdG8gdXNlIC0gYW5kIHN0YW5kYXJkaXplIHN1Y2ggdXNhZ2UgLSBhcyBp biB0aGUgcGFzdCwgd2l0aCBhbGwgdGhlIHByb2JsZW1zIGFzc29jaWF0ZWQsIGp1c3QgPj4gYnkg c2F5aW5nIHRoZSBjb250ZW50IGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcGxpY2F0aW9u Li4uDQo+Pj4gDQo+Pj4gV2UgZGlkIDYwODYgc28gdGhhdCB0aGUgdXNhZ2UgaWYgSU5GTyB0byBj YXJyeSBhc3NvY2lhdGVkIGJvZHkgcGFydHMgY291bGQgYmUgbmVnb3RpYXRlZC4NCj4+IA0KPj4g WW91IGRvbid0IG5lZWQgNjA4NiB0byBpbmRpY2F0ZSB3aGF0IGJvZHkgcGFydHMgeW91IHN1cHBv cnQuIFRoZXJlIGlzIGEgU0lQIGhlYWRlciBmaWVsZCBmb3IgdGhhdC4NCj4+IA0KPj4gV2UgZGVm aW5lZCA2MDg2IHNvIHRoYXQgeW91IGNvdWxkIGRlZmluZSBhbmQgaW5kaWNhdGUgdGhlIHNlbWFu dGljcyBhc3NvY2lhdGVkIHdpdGggdGhlIElORk8gcmVxdWVzdCAoaW5jbHVkaW5nIGJvZHkgcGFy dHMpLCBhbmQgdG8gbmVnb3RpYXRlIHN1cHBvcnQgb2YgcHJvY2Vzc2luZyB0aGF0IHNlbWFudGlj cy4NCj4+IA0KPj4+IElNTyBpZiBzb21ldGhpbmcgaXMgaW4gdGhlIG1lc3NhZ2UsIGJ1dCBub3Qg aW4gdGhlIGluZm8tcGFja2FnZSBib2R5IA0KPj4+IHBhcnQsIHRoZW4gaXQgaXNuJ3Qgc3BlY2lm aWNhbGx5IHBhcnQgb2YgdGhlIElORk8gdXNhZ2UuIEZvciBpbnN0YW5jZSwgYW55IHJhbmRvbSBo ZWFkZXIgZmllbGQgdGhhdCB5b3UgaGFwcGVuIHRvIGluY2x1ZGUgaXNuJ3QuDQo+PiANCj4+IE1T RCBpcyBub3QgInNvbWV0aGluZyByYW5kb20gdGhhdCB5b3UgaGFwcGVuIHRvIGluY2x1ZGUiIGlu IGFuIElORk8gYXNzb2NpYXRlZCB3aXRoIHRoZSBlY2FsbCBhcHBsaWNhdGlvbi4NCj4+IA0KPj4g T3IsIGFnYWluLCBhcmUgeW91IHNheWluZyB0aGF0IE1TRCBpcyBub3QgYXNzb2NpYXRlZCB3aXRo IHRoZSBlY2FsbCBhcHBsaWNhdGlvbj8NCj4gDQo+IEkibSBzYXlpbmcgdGhhdCBJIGRvbid0IGtu b3cgYW55dGhpbmcgYWJvdXQgYW4gZWNhbGwgKmFwcGxpY2F0aW9uKi4gSSBhZ3JlZSB0aGVyZSBt aWdodCBiZSBvbmUsIGJ1dCB3ZSBhcmVuJ3QgZGVmaW5pbmcgdGhhdC4gSSBkbyBrbm93IHRoZSBN U0QgaXMgYXNzb2NpYXRlZCB3aXRoIGEgY2FsbC1pbmZvIGhlYWRlciBmaWVsZC4gSSBjYW4gcG90 ZW50aWFsbHkgcHV0IHRoYXQgY2FsbC1pbmZvIGluIGFueSBtZXNzYWdlIEkgbGlrZSAodGhhdCBw ZXJtaXRzIGNhbGwtaW5mbykuDQo+IA0KPiBJZiB0aGVyZSBoYXBwZW5zIHRvIGJlIGFuIGVjYWxs IGFwcGxpY2F0aW9uLCB0aGVuIHRoZSBNU0QgbWlnaHQgaW5kZWVkIA0KPiBlbmQgdXAgYXQgdGhh dCBhcHBsaWNhdGlvbi4gSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgYXBwbGljYXRpb24gd2lsbCAN Cj4gYmUNCj4gKmxvb3NlbHkqIGNvdXBsZWQgdG8gdGhlIHNpcCBzZXNzaW9uLiBMb3RzIG9mIG90 aGVyIHRoaW5ncyBtYXkgaGFwcGVuIGluIHRoYXQgc2Vzc2lvbiB0aGF0IG1heSBvciBtYXkgbm90 IGJlIGFudGljaXBhdGVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gDQo+IFRob3NlIHRoaW5ncyBtYXkg YmUgcHJvY2Vzc2VkIGJ5IG90aGVyIFVBIGFwcGxpY2F0aW9uIHNvZnR3YXJlLiBTbyB0aGUgZWNh bGwgYXBwbGljYXRpb24gaXMganVzdCBvbmUgKnVzZXIqIG9mIHRoZSBzaXAgc2Vzc2lvbi4NCj4g DQo+IE9mIGNvdXJzZSB0aGUgYXBwbGljYXRpb24gZW52aXJvbm1lbnQgbWF5IGNvbnN0cmFpbiB0 aGUgcG9zc2liaWxpdGllcyBpbiBzb21lIHdheS4gQnV0IEkgdGhpbmsgdGhhdCBpcyBvdXRzaWRl IG9mIG91ciBzY29wZSBoZXJlLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxp bmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0 DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l Y3JpdA0K From nobody Tue Aug 23 23:14: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 E2CC412D151 for ; Tue, 23 Aug 2016 23:14:06 -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 nARaJd_gJbnw for ; Tue, 23 Aug 2016 23:14:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E8F9B12D0FD for ; Tue, 23 Aug 2016 23:14:04 -0700 (PDT) X-AuditID: c1b4fb25-8d3fb70000001071-38-57bd3b298641 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id C2.DC.04209.92B3DB75; Wed, 24 Aug 2016 08:14:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Wed, 24 Aug 2016 08:14:01 +0200 From: Christer Holmberg To: "R.Jesske@telekom.de" , "br@salsgiver.com" , "keith.drage@nokia.com" Thread-Topic: AW: [Ecrit] Multipart with INFO Thread-Index: AQHR/c60wjqG+/j+Nk6+z04dSm/pBQ== Date: Wed, 24 Aug 2016 06:14:00 +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.5.160527 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1254" Content-ID: <82DECA71C998CE45ABAFC2360CCB76B1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7sa6W9d5wg3UrTSymHdvAbtG46Cmr xYYtx1ksmu50sTmweCxZ8pPJ4+6tS0weiw79YPVoe6kQwBLFZZOSmpNZllqkb5fAldHTcIm9 4GlsxYT7u5gbGO94dzGyc0gImEjcke1i5OIQEljPKPF3ykImCGcJo8SWzzcZuxg5ONgELCS6 /2l3MXJyiAh0MkrM3FgPYjMLqEqca3zMAmILC+hIzHx5mhmkXERAV+JKiydEuZ7E+Zk/2EFs FqDylnvLwWxeASuJtjtbmUBsRgExie+n1jBBjBSXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rCC2 KNDM719nQ8UVJdqfNjBC9BpIHDl3kxXCtpZYumspG4StLbFs4WtmiL2CEidnPmGZwCg6C8m6 WUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPr4JbfqjsYL79x PMQowMGoxMP7IGxPuBBrYllxZe4hRgkOZiUR3g7zveFCvCmJlVWpRfnxRaU5qcWHGKU5WJTE ef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGJNevBe/LxPPJsp6zkbZu3WG/YFJH04Jn2hbei6t NbijIahsypSTLrEbC2MvTZblFFOaO/+8/+/2Ru2PKeu7IjW0zh3eoGmn4xi14FHrxIANRVKF M9q/HOxhr9Z+PcHY+fv/4PmShm2BCn8sMlauuNLSVfTl79JnqjxVX3PdH0l1OMs+vNdhrcRS nJFoqMVcVJwIAJve86arAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 06:14:07 -0000 Hi Roland, >>The question is whether the INFO request itself, and the MSD content >>transported in the INFO request, are >associated with the same >>"application" (ecall), and whether the MSD therefore must be sent using >>an Info >Package, as stated in 6086. > >Discussing this all the time I'm wondering if we cannot come up with some >text describing the "eCall" use case when using INFO with additional data >for the eCall scenario. And make it clear that the application has to >correlate the information. >I think all other cases are out of scope. > >Or I'm wrong? I don=92t know, because I=92m not sure I understood your comment :) The point is that, when the content (MSD) is associated with the INFO =93application=94 (ecall), the content has to be associated with an Info Package. Regards, Christer > >-----Urspr=FCngliche Nachricht----- >Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Christer >Holmberg >Gesendet: Dienstag, 23. August 2016 18:28 >An: Brian Rosen; Drage, Keith (Nokia - GB) >Cc: ECRIT >Betreff: Re: [Ecrit] Multipart with INFO > >Hi, > >>The notion authors have proposed is that we create a command channel for >>mid call communications between devices and PSAPs using INFO. That >>requires an INFO >package. We can, however, make one INFO package that >>defines this protocol and use it for multiple instances of devices >>communicating with PSAPs, at least those that >have a simple request >>update command. > >Correct. > >>We started this entire set of documents to manage sending of data from >>devices to PSAPs. eCall is one example, an alarm is another. In most >>cases, the initial data >accompanies the INVITE. >>If there is an update, the device can decide to send it. It is also >>possible that the PSAP can request it. Different devices have >>different data. > >Correct. > >>No one has argued that the data sent with the INVITE is carried as >>Additional Data, requiring a schema and a token registered with IANA. > >Correct. The agreement has been to use the mechanism defined in >Additional Data for transporting the data in INVITE. > >> We=92re arguing that the character of the data doesn=92t change and the >> schema of the data doesn=92t change when you send it mid call, and it >>doesn=92t matter what message you attach it to, it=92s Additional Data. >>What we need INFO for is the >> request/response command channel. You send an INFO with a request >>using an INFO package conforming to 6086. >> You may get a response to the request (in another INFO). That=92s the >> INFO transaction and it satisfies all the requirements of 6086. 6086 >> isn=92t a straightjacket. I=92m happy to go get sippcore to tell us the >>obvious: we can send a Call-Info with a CID and a body, no matter what >>the relationship between the INFO and the Call-Info are. Do you want me >>to ask for that? > >First, I'm happy to take this to SIPCORE (I already suggested that >earlier). > >However, simply asking "Can we send a Call-Info with a CID and a body" >isn't very useful. > >The question is whether the INFO request itself, and the MSD content >transported in the INFO request, are associated with the same >"application" (ecall), and whether the MSD therefore must be sent using >an Info Package, as stated in 6086. > >> We want the MSD outside the INFO package because it=92s Additional Data >> and should be carried with a Call-Info pointing to the MIME type and >>schema registered for Additional Data, just like in the INVITE. >> >> We want the INFO package for its command (send the MSD) and response >> (ACK). That can only happen mid-call, so INFO is appropriate. It=92s a >> well defined INFO package, and it satisfies all the requirements of >> 6068. The same idea would work with any device that needs some kind >> of command structure. The example I gave was =93send elevators to >> ground floor=94. That would need a new INFO package because the command >>is different. The elevator status would be Additional Data, and would >>be sent in a body pointed to by the Call-Info, just like it would in the >>INVITE: same MIME type, same Content-Disposition. But if I had a >>container that sent a leak alarm, and that=92s all it can do, using the >>eCall INFO package to request an update of its data would work fine with >>no changes. > >But INFO is not just like the INVITE. 6086 defines rules for how to >transport content using INFO, and Additional Data cannot override those >rules. > >>Using the INFO for command/control and Additional Data for the data is >>clean and makes sense. It allows us to reuse the INFO package for >>other simple devices, and create others for more complex devices. It >>makes processing at the PSAP simpler, because the data comes the same >>way whether it=92s at the beginning of the call, it comes unsolicited or >>it comes as a response to a command to send it. > >I am not sure I understand. You don't have to support the MSD Info >Package in order to use the command/control protocol - it's defined >separately, outside the MSD Info Package. You can use the protocol in >whatever Info Package you want - and if you don't use INFO you don't even >have to define an Info Package in order to use it. > >Regards, > >Christer > > >Brian > > >> On Aug 22, 2016, at 6:05 PM, Drage, Keith (Nokia - GB) >> wrote: >>=20 >> I'm afraid I see somewhat muddled thinking here, and I am sure it is >>not mine. >>=20 >> We have already agreed for the use case of ecall, that the transfer of >>data outside of a call control message using INFO requires the creation >>of an Info package. >>=20 >> Following that use case, and using exactly the same argument, then any >>other use case requiring to use INFO to transfer data would create >>another Info package for the transfer of that data. >>=20 >> While theoretically, an argument might apply that it is valid to use >>additional data in an INFO message, I cannot conceive of a use case >>where only there in addition to the ecall Info package, and never >>required at any other time. If it is required at any other time, then >>the separate Info package must exist, and therefore if it exists, it >>should be used for all the transfers outside of call control messages. >>Conversely, if it is only there when ecall transfer exists, and never >>outside it, I wonder why it is not part of the ecall Info package. >>=20 >> The only exception I can see to this is where some other preexisting >>linking mechanism exists, such as Geolocation, but even this in my mind >>causes issues. >>=20 >> Regards >>=20 >> Keith >>=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 19 August 2016 23:53 >> To: Christer Holmberg; ECRIT >> Subject: Re: [Ecrit] Multipart with INFO >>=20 >> On 8/19/16 6:36 PM, Christer Holmberg wrote: >>> Hi, >>>=20 >>>>>>>>>> The discussion on ecall has become quite heated, with people >>>>>>>>>> dug in on all sides. Can we calm it down a bit? >>>>>>>>>>=20 >>>>>>>>>> IMO a couple of different approaches have been described that >>>>>>>>>> would work and not violate any specs. The differences between >>>>>>>>>> these reflect differences of philosophy and taste. >>>>>>>>>=20 >>>>>>>>> I don=B9t think we have an agreement on the >>>>>>>>> would-not-violate-any-specs part. We clearly have different >>>>>>>>>views on what is allowed by RFC 6086. >>>>>>>>>=20 >>>>>>>>> But, I do agree we need to try to figure out how to move forward. >>>>>>>>=20 >>>>>>>> OK. Maybe we should start there. >>>>>>>>=20 >>>>>>>> I guess there is some dispute on whether it is valid for an INFO >>>>>>>> message to contain a multipart body, where one part contains the >>>>>>>> info package >>>>>>>> (C-D: info-package) and another part (C-D: by-reference) is >>>>>>>> referenced by a cid: uri in some sip header field. >>>>>>>>=20 >>>>>>>> In my mind there is no question that this is valid. Do you >>>>>>>> disagree, and if so, on what basis? >>>>>>>=20 >>>>>>> The dispute is whether a message body must be associated with an >>>>>>> Info Package. >>>>>>>=20 >>>>>>> In my view: >>>>>>>=20 >>>>>>> - RFC 6086 allows bodies not associated with an Info Package in >>>>>>> INFOs in order to be backward compatible with existing pre-6086 >>>>>>>INFO usages. >>>>>>> - Any NEW usage MUST be associated with an Info Package. Sending >>>>>>> of MSD is a new INFO usage. >>>>>>=20 >>>>>> I disagree. I find the following in 6086: >>>>>>=20 >>>>>> NOTE: An INFO request can also contain other body parts that >>>>>>are >>>>>> meaningful within the context of an invite dialog usage but are >>>>>> not specifically associated with the INFO method and the >>>>>> application concerned. >>>>>=20 >>>>> So, you are saying that the MSD is not associated with the ecall >>>>>application??? >>>>>=20 >>>>> RFC 6086 also says: >>>>>=20 >>>>> "Any new usage MUST use the Info Package mechanism defined in this >>>>> specification, since it does not share the issues associated >>>>>with >>>>> legacy INFO usage, and since Info Packages can be registered >>>>>with >>>>> IANA." >>>>>=20 >>>>> And, in my opinion, sending of MSD *is* part of the new INFO usage. >>>>>It's not something else that we add to the INFO. >>>>>=20 >>>>> Otherwise, why did we do RFC 6086 in the first place? We can just >>>>>allow people to use - and standardize such usage - as in the past, >>>>>with all the problems associated, just >> by saying the content is >>>>>not associated with the application... >>>>=20 >>>> We did 6086 so that the usage if INFO to carry associated body parts >>>>could be negotiated. >>>=20 >>> You don't need 6086 to indicate what body parts you support. There is >>>a SIP header field for that. >>>=20 >>> We defined 6086 so that you could define and indicate the semantics >>>associated with the INFO request (including body parts), and to >>>negotiate support of processing that semantics. >>>=20 >>>> IMO if something is in the message, but not in the info-package body >>>> part, then it isn't specifically part of the INFO usage. For >>>>instance, any random header field that you happen to include isn't. >>>=20 >>> MSD is not "something random that you happen to include" in an INFO >>>associated with the ecall application. >>>=20 >>> Or, again, are you saying that MSD is not associated with the ecall >>>application? >>=20 >> I"m saying that I don't know anything about an ecall *application*. I >>agree there might be one, but we aren't defining that. I do know the MSD >>is associated with a call-info header field. I can potentially put that >>call-info in any message I like (that permits call-info). >>=20 >> If there happens to be an ecall application, then the MSD might indeed >> end up at that application. I would expect that the application will >> be >> *loosely* coupled to the sip session. Lots of other things may happen >>in that session that may or may not be anticipated by the application. >> Those things may be processed by other UA application software. So the >>ecall application is just one *user* of the sip session. >>=20 >> Of course the application environment may constrain the possibilities >>in some way. But I think that is outside of our scope here. >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 24 11:07: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 A0D3512D667 for ; Wed, 24 Aug 2016 11:07:51 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 o8GdSXyXH_iv for ; Wed, 24 Aug 2016 11:07:50 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 9673A12D9BF for ; Wed, 24 Aug 2016 11:07:50 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-07v.sys.comcast.net with SMTP id ccZPbcCQyff8qccabbsuNV; Wed, 24 Aug 2016 18:07:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with SMTP id ccabbS11CeKs6ccabbNJxK; Wed, 24 Aug 2016 18:07:49 +0000 To: ecrit@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 24 Aug 2016 14:07:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFKOx59U4aBTo12TJxWL1l539lARnjmNwaJHuxBRExNvibYwc2OFahdn8pUrgX0TZ7V0f9pL2CIgiT7iAAaTty77u+AYbMKke+g6pqsAJj9TrjPeXvP1 XGaFqSm12NoUZaGSlTRqYboAru5r87g+CpL9NEb24/OMEvkhtIyDTPlklB3eFRTfTtICZWRr9w0IYQ== Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 18:07:51 -0000 Christer, On 8/24/16 2:14 AM, Christer Holmberg wrote: >>> The question is whether the INFO request itself, and the MSD content >>> transported in the INFO request, are associated with the same >>> "application" (ecall), and whether the MSD therefore must be sent using >>> an Info Package, as stated in 6086. [snip] > The point is that, when the content (MSD) is associated with the INFO > “application” (ecall), the content has to be associated with an Info > Package. You keep making this argument and I totally fail to understand it. I think your are trying to read more into "application" than makes sense to me. When the ecall first arrives, there is no info package, but there *is* an MSD in additional-data. That MSD presumably gets delivered to where it needs to go. Call that an "ecall application" if you like. Then we have an info package that is used in that call to convey some further information relevant in the context of the call. This also goes where it needs to go - presumably the "ecall application". Thus we have two different means of conveying information to that application. If there is subsequently a reINVITE, presumably it would be acceptable to attach MSD additional-data to it and that would also go to the application. So why would it somehow be wrong to attach MSD additional-data to an INFO? (If it makes you happier, feel free to consider that there is one application that is dedicated to the ecall info package, and another application that is dedicated to MSD additional data, and a higher level application that ties the two together.) Thanks, Paul From nobody Wed Aug 24 11:28:10 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 03C7112D625 for ; Wed, 24 Aug 2016 11:28: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 r_TWqY5yd3GK for ; Wed, 24 Aug 2016 11:28:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D569312D518 for ; Wed, 24 Aug 2016 11:28:06 -0700 (PDT) X-AuditID: c1b4fb30-abfff700000009f9-5c-57bde734faa3 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 7E.7B.02553.437EDB75; Wed, 24 Aug 2016 20:28:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Wed, 24 Aug 2016 20:28:04 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR/c60qNJ7oBH9k0Om6PUXgFpRgaBYR7MAgAAiutA= Date: Wed, 24 Aug 2016 18:28:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC5809D@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+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7uK7p873hBh1TRSwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxo/Mfa8F64YrnO9sYGxi38HcxcnJICJhI /Ov4xdzFyMUhJLCeUWLv3vlMEM4SRol5G3aydjFycLAJWEh0/9MGaRAR8Jb48/sbG4gtLKAh cXjCDCaIuKbE5GsvmEHKRQSsJOYtkQMJswioSqx884UdJMwr4Csx6YQASFhIoEDifPMJZhCb U8BBomPlUTCbUUBM4vupNWATmQXEJW49mc8EcaaAxJI955khbFGJl4//sULYShKNS56wQtTr SCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrMQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk33chI L7UoM7m4OD9PLy+1ZBMjMBYObvltsIPx5XPHQ4wCHIxKPLwLHuwNF2JNLCuuzD3EKMHBrCTC m/cMKMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoHR3c74 1/7zX5asv5yXHTWz9cS1iUbBp3lXflGYMLluw5rcosjSuX1ybQKvFFgf+fv2W2RH7Itz/GHs yvXB/fXqyHPC+iIXOHL8mNkLAtu6vGJLA1xm1x3cYauyTX9Z2NQpqRd8fP1SvVXuSP1h+6xi qc9hJhPzz3t2s2KY2dKMt2+ddnXwaSmxFGckGmoxFxUnAgA0DBzkgQIAAA== Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 18:28:08 -0000 Hi, >>>> The question is whether the INFO request itself, and the MSD content=20 >>>> transported in the INFO request, are associated with the same=20 >>>> "application" (ecall), and whether the MSD therefore must be sent=20 >>>> using an Info Package, as stated in 6086. >>[snip] >> The point is that, when the content (MSD) is associated with the INFO=20 >> "application" (ecall), the content has to be associated with an Info=20 >> Package. > > You keep making this argument and I totally fail to understand it. I thin= k your are trying to read more into "application" than makes sense to me. > > When the ecall first arrives, there is no info package, but there *is* an= MSD in additional-data. That MSD presumably gets delivered > to where it needs to go. Call that an "ecall application" if you like. > > Then we have an info package that is used in that call to convey some fur= ther information relevant in the context of the call. This=20 > also goes where it needs to go - presumably the "ecall application". Thus= we have two different means of conveying information to that application. Yes. But we KNEW that when we did 6086. We were aware of that fact that, ev= enthough the same MIME type can be used for conveying data in INVITE and IN= FO, there will be different mechanisms to convey the same data in INVITEs a= nd INFOs. >If there is subsequently a reINVITE, presumably it would be acceptable to = attach MSD additional-data to it and that would also go to the application. Yes. >So why would it somehow be wrong to attach MSD additional-data to an INFO? Because RFC 6086 defines how to convey data associated with the "applicatio= n". One may not like it, but that's what it says, and you know the reason w= hy it says so. >(If it makes you happier, feel free to consider that there is one applicat= ion that is dedicated to the ecall info package, and another application th= at is dedicated to MSD >additional data, and a higher level application tha= t ties the two together.) I don't want to find ways to get around using an Info Package. I think MSD = is a school book example of Info Package usage. Saying that the request for MSD is associated with the ecall application, b= ut the delivery of the requested MSD isn't, is REALLY farfetched in my opin= ion. It's the ecall application that requests the MSD, and it's the ecall a= pplication that consumes the MSD. Regards, Christer From nobody Wed Aug 24 11:53:02 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 9F1F112D66F for ; Wed, 24 Aug 2016 11:53:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 srFws6rjPeN0 for ; Wed, 24 Aug 2016 11:52:59 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 7AA1412D1A6 for ; Wed, 24 Aug 2016 11:52:59 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with SMTP id cdI7baeIh2NhqcdIIb9Eyd; Wed, 24 Aug 2016 18:52:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with SMTP id cdIHbhm66xqA0cdIIbLMVL; Wed, 24 Aug 2016 18:52:58 +0000 To: Christer Holmberg , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4BC5809D@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 24 Aug 2016 14:52:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC5809D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKjFlxsLto9ar7mQgkIDUaHfb8FhDypsSAF2z7WgWsSZFsyMZHXsaFFRY7h6Xt+VKLZJWbYaK+EVH2L0k+ovy0zrb5RBl8E50hklTuiwmXJok1G5vTl5 cP4lI1cb4Mh2k5/xBRUG1om7A7biet7sRC9jjtdZJK5YR5V0OIPKMcAEmYCq3p4b6e7854Ql2qaCjNVD0eNFdfscaMc8PWjXks+1psEUhb9zPc4J4yxDBFbX Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 18:53:00 -0000 On 8/24/16 2:28 PM, Christer Holmberg wrote: > Hi, > >>>>> The question is whether the INFO request itself, and the MSD content >>>>> transported in the INFO request, are associated with the same >>>>> "application" (ecall), and whether the MSD therefore must be sent >>>>> using an Info Package, as stated in 6086. >>> [snip] >>> The point is that, when the content (MSD) is associated with the INFO >>> "application" (ecall), the content has to be associated with an Info >>> Package. >> >> You keep making this argument and I totally fail to understand it. I think your are trying to read more into "application" than makes sense to me. >> >> When the ecall first arrives, there is no info package, but there *is* an MSD in additional-data. That MSD presumably gets delivered >> to where it needs to go. Call that an "ecall application" if you like. >> >> Then we have an info package that is used in that call to convey some further information relevant in the context of the call. This >> also goes where it needs to go - presumably the "ecall application". Thus we have two different means of conveying information to that application. > > Yes. But we KNEW that when we did 6086. We were aware of that fact that, eventhough the same MIME type can be used for conveying data in INVITE and INFO, there will be different mechanisms to convey the same data in INVITEs and INFOs. > >> If there is subsequently a reINVITE, presumably it would be acceptable to attach MSD additional-data to it and that would also go to the application. > > Yes. > >> So why would it somehow be wrong to attach MSD additional-data to an INFO? > > Because RFC 6086 defines how to convey data associated with the "application". One may not like it, but that's what it says, and you know the reason why it says so. > >> (If it makes you happier, feel free to consider that there is one application that is dedicated to the ecall info package, and another application that is dedicated to MSD >additional data, and a higher level application that ties the two together.) > > I don't want to find ways to get around using an Info Package. I think MSD is a school book example of Info Package usage. > > Saying that the request for MSD is associated with the ecall application, but the delivery of the requested MSD isn't, is REALLY farfetched in my opinion. It's the ecall application that requests the MSD, and it's the ecall application that consumes the MSD. This all begs the question of what *the* application is. It presumes there is exactly one. Can you point me to the specific text in 6086 that leads you to think there is such a rule? (I looked and couldn't find it.) If you want to rely religiously to that, then you also ought to be arguing that if INFO is going to be used, then INFO should be the *only* thing that is used for that application. Hence an additional-data should not be used at all in the same call with it. You could make an alternative proposal for ecall that takes that philosophy. It would be aesthetically pure. If there is no need to have MSD data sooner than it could arrive in an INFO then I think that would be perfectly reasonable. But I have yet to see such a proposal. Thanks, Paul From nobody Wed Aug 24 12:22: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 1125712D733 for ; Wed, 24 Aug 2016 12:22:30 -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 KVXeJSiFUVLs for ; Wed, 24 Aug 2016 12:22:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4911D12D727 for ; Wed, 24 Aug 2016 12:22:28 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-d0-57bdf3f219e9 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id C8.2C.04209.2F3FDB75; Wed, 24 Aug 2016 21:22:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Wed, 24 Aug 2016 21:22:24 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Multipart with INFO Thread-Index: AQHR/c60qNJ7oBH9k0Om6PUXgFpRgaBYR7MAgAAiutD//+niAIAAJQSg Date: Wed, 24 Aug 2016 19:22:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC59363@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC5809D@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7nO6nz3vDDZaskrdoXPSU1WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG6TPXWAuuKld0rL/G0sC4SKaLkYNDQsBE Yne3ZhcjF4eQwHpGia5Jx5khnCWMEhd/bmYCKWITsJDo/qfdxcjJISLgLfHn9zc2EFtYQEPi 8IQZTBBxTYnJ114wg5SLCLhJbN1lARJmEVCVmNDVCVbCK+Ar8frcERaI8a8YJZ4vesAIkuAU cJBoWPeKBcRmFBCT+H5qDVgDs4C4xK0n88FsCQEBiSV7zjND2KISLx//Y4WwlSQalzxhhajX kViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTipNx0I2O9 1KLM5OLi/Dy9vNSSTYzAaDi45bfqDsbLbxwPMQpwMCrx8C54sDdciDWxrLgy9xCjBAezkgjv 1U9AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYyT75w0 ud++I832x1n2HWLdNzbyLph7pKn6XuffdSe+ZUnIGOr1X5T2XbxiZ/z+a4ost9ImvrX8ICf0 P/Io46N6maOxd5yW/y00PSPGvrI48uNxfRWHVZ/aKhRsFx/iL97yznfWxc8znbe8fOW02X4v y9e/9sxhwgFHU8U1b5VJvWkoT/TmYTVSYinOSDTUYi4qTgQAE4aB5oICAAA= Archived-At: Subject: Re: [Ecrit] Multipart with INFO 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, 24 Aug 2016 19:22:30 -0000 Hi, >>>>>> The question is whether the INFO request itself, and the MSD=20 >>>>>> content transported in the INFO request, are associated with the=20 >>>>>> same "application" (ecall), and whether the MSD therefore must be=20 >>>>>> sent using an Info Package, as stated in 6086. >>>> [snip] >>>> The point is that, when the content (MSD) is associated with the=20 >>>> INFO "application" (ecall), the content has to be associated with an=20 >>>> Info Package. >>> >>> You keep making this argument and I totally fail to understand it. I th= ink your are trying to read more into "application" than makes sense to me. >>> >>> When the ecall first arrives, there is no info package, but there=20 >>> *is* an MSD in additional-data. That MSD presumably gets delivered to w= here it needs to go. Call that an "ecall application" if you like. >>> >>> Then we have an info package that is used in that call to convey some=20 >>> further information relevant in the context of the call. This also goes= where it needs to go - presumably=20 >>> the "ecall application". Thus we have two different means of conveying = information to that application. >> >> Yes. But we KNEW that when we did 6086. We were aware of that fact that,= eventhough the same MIME type=20 >> can be used for conveying data in INVITE and INFO, there will be differe= nt mechanisms to convey the same data in INVITEs and INFOs. >> >>> If there is subsequently a reINVITE, presumably it would be acceptable = to attach MSD additional-data to it and that would also go to the applicati= on. >> >> Yes. >> >>> So why would it somehow be wrong to attach MSD additional-data to an IN= FO? >> >> Because RFC 6086 defines how to convey data associated with the "applica= tion". One may not like it, but that's what it says, and you know the reaso= n why it says so. >> >>> (If it makes you happier, feel free to consider that there is one appli= cation that is dedicated to the ecall info package, and another=20 >>> application that is dedicated to MSD >additional data, and a higher lev= el application that ties the two together.) >> >> I don't want to find ways to get around using an Info Package. I think M= SD is a school book example of Info Package usage. >> >> Saying that the request for MSD is associated with the ecall application= , but the delivery of the requested MSD isn't, is REALLY >> farfetched in my opinion. It's the ecall application that requests the M= SD, and it's the ecall application that consumes the MSD. > > This all begs the question of what *the* application is. It presumes ther= e is exactly one. Can you point me to the specific=20 > text in 6086 that leads you to think there is such a rule? (I looked and = couldn't find it.) I didn't say 6086 mandates only one application. I said that the request/co= ntrol protocol, the MSD, and the INFO used to carry those, are all associat= ed with the ecall application. And, EVEN if we did come up with another application X for conveying MSD, a= nd application X sends an INFO with MSD only, it would still have to use an= Info Package, because the INFO and the MSD content is associated with appl= ication X. My point is: if we allow people to word smith their way around using Info P= ackages, claiming that the content in the INFO is not associated with the a= pplication sending the INFO (which is some cases may be true, btw, and then= we do talk about valid piggy backing cases), we can as well throw away 608= 6 (and all the years of work to come up with it)...=20 > If you want to rely religiously to that, then you also ought to be arguin= g that if INFO is going to be used, then INFO should=20 > be the *only* thing that is used for that application. Hence an additiona= l-data should not be used at all in the same call with it. I don't say that. RFC 6086 only covers INFO, but doesn't forbid the same in= formation from being transported also using other SIP methods - using whate= ver mechanisms. And, just to be clear: I have no problem using the Additional Data mechanis= m for sending MSD in INVITEs. > You could make an alternative proposal for ecall that takes that philosop= hy. It would be aesthetically pure. If there is no need to=20 > have MSD data sooner than it could arrive in an INFO then I think that wo= uld be perfectly reasonable. But I have yet to see such a proposal. I support being able to send MSD in INVITE, so I am not going to make such = proposal :) Regards, Christer From nobody Thu Aug 25 06:23:56 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 67CC012B007 for ; Thu, 25 Aug 2016 06:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 P3XjLOtSUCJS for ; Thu, 25 Aug 2016 06:23:53 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (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 2815B12D0B4 for ; Thu, 25 Aug 2016 06:23:52 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7PDNhu7077964; Thu, 25 Aug 2016 09:23:44 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.33.192.33] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC59363@ESESSMB209.ericsson.se> Date: Thu, 25 Aug 2016 09:23:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3CC7BAB0-1C14-447D-8F15-D33E440B3B07@salsgiver.com> References: <7594FB04B1934943A5C02806D1A2204B4BC5809D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC59363@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Multipart with INFO 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, 25 Aug 2016 13:23:55 -0000 For those of you that are not subscribed to the sipcore list, I have = raised the question of whether the language of 6086 would prohibit the = use of Call-Info to carry the MSD. We=E2=80=99ll report the conclusion back to ecrit. Brian > On Aug 24, 2016, at 3:22 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>> The question is whether the INFO request itself, and the MSD=20 >>>>>>> content transported in the INFO request, are associated with the=20= >>>>>>> same "application" (ecall), and whether the MSD therefore must = be=20 >>>>>>> sent using an Info Package, as stated in 6086. >>>>> [snip] >>>>> The point is that, when the content (MSD) is associated with the=20= >>>>> INFO "application" (ecall), the content has to be associated with = an=20 >>>>> Info Package. >>>>=20 >>>> You keep making this argument and I totally fail to understand it. = I think your are trying to read more into "application" than makes sense = to me. >>>>=20 >>>> When the ecall first arrives, there is no info package, but there=20= >>>> *is* an MSD in additional-data. That MSD presumably gets delivered = to where it needs to go. Call that an "ecall application" if you like. >>>>=20 >>>> Then we have an info package that is used in that call to convey = some=20 >>>> further information relevant in the context of the call. This also = goes where it needs to go - presumably=20 >>>> the "ecall application". Thus we have two different means of = conveying information to that application. >>>=20 >>> Yes. But we KNEW that when we did 6086. We were aware of that fact = that, eventhough the same MIME type=20 >>> can be used for conveying data in INVITE and INFO, there will be = different mechanisms to convey the same data in INVITEs and INFOs. >>>=20 >>>> If there is subsequently a reINVITE, presumably it would be = acceptable to attach MSD additional-data to it and that would also go to = the application. >>>=20 >>> Yes. >>>=20 >>>> So why would it somehow be wrong to attach MSD additional-data to = an INFO? >>>=20 >>> Because RFC 6086 defines how to convey data associated with the = "application". One may not like it, but that's what it says, and you = know the reason why it says so. >>>=20 >>>> (If it makes you happier, feel free to consider that there is one = application that is dedicated to the ecall info package, and another=20 >>>> application that is dedicated to MSD >additional data, and a higher = level application that ties the two together.) >>>=20 >>> I don't want to find ways to get around using an Info Package. I = think MSD is a school book example of Info Package usage. >>>=20 >>> Saying that the request for MSD is associated with the ecall = application, but the delivery of the requested MSD isn't, is REALLY >>> farfetched in my opinion. It's the ecall application that requests = the MSD, and it's the ecall application that consumes the MSD. >>=20 >> This all begs the question of what *the* application is. It presumes = there is exactly one. Can you point me to the specific=20 >> text in 6086 that leads you to think there is such a rule? (I looked = and couldn't find it.) >=20 > I didn't say 6086 mandates only one application. I said that the = request/control protocol, the MSD, and the INFO used to carry those, are = all associated with the ecall application. >=20 > And, EVEN if we did come up with another application X for conveying = MSD, and application X sends an INFO with MSD only, it would still have = to use an Info Package, because the INFO and the MSD content is = associated with application X. >=20 > My point is: if we allow people to word smith their way around using = Info Packages, claiming that the content in the INFO is not associated = with the application sending the INFO (which is some cases may be true, = btw, and then we do talk about valid piggy backing cases), we can as = well throw away 6086 (and all the years of work to come up with it)...=20= >=20 >> If you want to rely religiously to that, then you also ought to be = arguing that if INFO is going to be used, then INFO should=20 >> be the *only* thing that is used for that application. Hence an = additional-data should not be used at all in the same call with it. >=20 > I don't say that. RFC 6086 only covers INFO, but doesn't forbid the = same information from being transported also using other SIP methods - = using whatever mechanisms. >=20 > And, just to be clear: I have no problem using the Additional Data = mechanism for sending MSD in INVITEs. >=20 >> You could make an alternative proposal for ecall that takes that = philosophy. It would be aesthetically pure. If there is no need to=20 >> have MSD data sooner than it could arrive in an INFO then I think = that would be perfectly reasonable. But I have yet to see such a = proposal. >=20 > I support being able to send MSD in INVITE, so I am not going to make = such proposal :) >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 25 13:52:10 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 3DDF012D1C7 for ; Tue, 23 Aug 2016 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 58OTNwvpWI3S for ; Tue, 23 Aug 2016 08:31:57 -0700 (PDT) Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (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 55FE012DAFE for ; Tue, 23 Aug 2016 08:12:51 -0700 (PDT) Received: from [10.33.192.33] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.14.3) with ESMTPA id u7NFChRx036260; Tue, 23 Aug 2016 11:12:44 -0400 (EDT) (envelope-from br@salsgiver.com) X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.33.192.33] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 23 Aug 2016 11:12:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDD290B-4DE8-46B6-B6B7-671241F8FF0C@salsgiver.com> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Thu, 25 Aug 2016 13:52:10 -0700 Cc: ECRIT Subject: Re: [Ecrit] Multipart with INFO 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, 23 Aug 2016 15:31:59 -0000 The notion authors have proposed is that we create a command channel for = mid call communications between devices and PSAPs using INFO. That = requires an INFO package. We can, however, make one INFO package that = defines this protocol and use it for multiple instances of devices = communicating with PSAPs, at least those that have a simple request = update command. We started this entire set of documents to manage sending of data from = devices to PSAPs. eCall is one example, an alarm is another. In most = cases, the initial data accompanies the INVITE. If there is an update, the device can decide to send it. It is also = possible that the PSAP can request it. Different devices have = different data. No one has argued that the data sent with the INVITE is carried as = Additional Data, requiring a schema and a token registered with IANA. We=E2=80=99re arguing that the character of the data doesn=E2=80=99t = change and the schema of the data doesn=E2=80=99t change when you send = it mid call, and it doesn=E2=80=99t matter what message you attach it = to, it=E2=80=99s Additional Data. What we need INFO for is the = request/response command channel. You send an INFO with a request = using an INFO package conforming to 6086. You may get a response to the = request (in another INFO). That=E2=80=99s the INFO transaction and it = satisfies all the requirements of 6086. 6086 isn=E2=80=99t a = straightjacket. I=E2=80=99m happy to go get sippcore to tell us the = obvious: we can send a Call-Info with a CID and a body, no matter what = the relationship between the INFO and the Call-Info are. Do you want me = to ask for that? =20 We want the MSD outside the INFO package because it=E2=80=99s Additional = Data and should be carried with a Call-Info pointing to the MIME type = and schema registered for Additional Data, just like in the INVITE. =20 We want the INFO package for its command (send the MSD) and response = (ACK). That can only happen mid-call, so INFO is appropriate. It=E2=80=99= s a well defined INFO package, and it satisfies all the requirements of = 6068. The same idea would work with any device that needs some kind of = command structure. The example I gave was =E2=80=9Csend elevators to = ground floor=E2=80=9D. That would need a new INFO package because the = command is different. The elevator status would be Additional Data, and = would be sent in a body pointed to by the Call-Info, just like it would = in the INVITE: same MIME type, same Content-Disposition. But if I had a = container that sent a leak alarm, and that=E2=80=99s all it can do, = using the eCall INFO package to request an update of its data would work = fine with no changes. Using the INFO for command/control and Additional Data for the data is = clean and makes sense. It allows us to reuse the INFO package for other = simple devices, and create others for more complex devices. It makes = processing at the PSAP simpler, because the data comes the same way = whether it=E2=80=99s at the beginning of the call, it comes unsolicited = or it comes as a response to a command to send it. Brian > On Aug 22, 2016, at 6:05 PM, Drage, Keith (Nokia - GB) = wrote: >=20 > I'm afraid I see somewhat muddled thinking here, and I am sure it is = not mine. >=20 > We have already agreed for the use case of ecall, that the transfer of = data outside of a call control message using INFO requires the creation = of an Info package. >=20 > Following that use case, and using exactly the same argument, then any = other use case requiring to use INFO to transfer data would create = another Info package for the transfer of that data. >=20 > While theoretically, an argument might apply that it is valid to use = additional data in an INFO message, I cannot conceive of a use case = where only there in addition to the ecall Info package, and never = required at any other time. If it is required at any other time, then = the separate Info package must exist, and therefore if it exists, it = should be used for all the transfers outside of call control messages. = Conversely, if it is only there when ecall transfer exists, and never = outside it, I wonder why it is not part of the ecall Info package. >=20 > The only exception I can see to this is where some other preexisting = linking mechanism exists, such as Geolocation, but even this in my mind = causes issues. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 19 August 2016 23:53 > To: Christer Holmberg; ECRIT > Subject: Re: [Ecrit] Multipart with INFO >=20 > On 8/19/16 6:36 PM, Christer Holmberg wrote: >> Hi, >>=20 >>>>>>>>> The discussion on ecall has become quite heated, with people=20= >>>>>>>>> dug in on all sides. Can we calm it down a bit? >>>>>>>>>=20 >>>>>>>>> IMO a couple of different approaches have been described that=20= >>>>>>>>> would work and not violate any specs. The differences between=20= >>>>>>>>> these reflect differences of philosophy and taste. >>>>>>>>=20 >>>>>>>> I don=C2=B9t think we have an agreement on the=20 >>>>>>>> would-not-violate-any-specs part. We clearly have different = views on what is allowed by RFC 6086. >>>>>>>>=20 >>>>>>>> But, I do agree we need to try to figure out how to move = forward. >>>>>>>=20 >>>>>>> OK. Maybe we should start there. >>>>>>>=20 >>>>>>> I guess there is some dispute on whether it is valid for an INFO=20= >>>>>>> message to contain a multipart body, where one part contains the=20= >>>>>>> info package >>>>>>> (C-D: info-package) and another part (C-D: by-reference) is=20 >>>>>>> referenced by a cid: uri in some sip header field. >>>>>>>=20 >>>>>>> In my mind there is no question that this is valid. Do you=20 >>>>>>> disagree, and if so, on what basis? >>>>>>=20 >>>>>> The dispute is whether a message body must be associated with an=20= >>>>>> Info Package. >>>>>>=20 >>>>>> In my view: >>>>>>=20 >>>>>> - RFC 6086 allows bodies not associated with an Info Package in=20= >>>>>> INFOs in order to be backward compatible with existing pre-6086 = INFO usages. >>>>>> - Any NEW usage MUST be associated with an Info Package. Sending=20= >>>>>> of MSD is a new INFO usage. >>>>>=20 >>>>> I disagree. I find the following in 6086: >>>>>=20 >>>>> NOTE: An INFO request can also contain other body parts that = are >>>>> meaningful within the context of an invite dialog usage but = are >>>>> not specifically associated with the INFO method and the >>>>> application concerned. >>>>=20 >>>> So, you are saying that the MSD is not associated with the ecall = application??? >>>>=20 >>>> RFC 6086 also says: >>>>=20 >>>> "Any new usage MUST use the Info Package mechanism defined in = this >>>> specification, since it does not share the issues = associated with >>>> legacy INFO usage, and since Info Packages can be = registered with >>>> IANA." >>>>=20 >>>> And, in my opinion, sending of MSD *is* part of the new INFO usage. = It's not something else that we add to the INFO. >>>>=20 >>>> Otherwise, why did we do RFC 6086 in the first place? We can just = allow people to use - and standardize such usage - as in the past, with = all the problems associated, just >> by saying the content is not = associated with the application... >>>=20 >>> We did 6086 so that the usage if INFO to carry associated body parts = could be negotiated. >>=20 >> You don't need 6086 to indicate what body parts you support. There is = a SIP header field for that. >>=20 >> We defined 6086 so that you could define and indicate the semantics = associated with the INFO request (including body parts), and to = negotiate support of processing that semantics. >>=20 >>> IMO if something is in the message, but not in the info-package body=20= >>> part, then it isn't specifically part of the INFO usage. For = instance, any random header field that you happen to include isn't. >>=20 >> MSD is not "something random that you happen to include" in an INFO = associated with the ecall application. >>=20 >> Or, again, are you saying that MSD is not associated with the ecall = application? >=20 > I"m saying that I don't know anything about an ecall *application*. I = agree there might be one, but we aren't defining that. I do know the MSD = is associated with a call-info header field. I can potentially put that = call-info in any message I like (that permits call-info). >=20 > If there happens to be an ecall application, then the MSD might indeed = end up at that application. I would expect that the application will be > *loosely* coupled to the sip session. Lots of other things may happen = in that session that may or may not be anticipated by the application.=20= > Those things may be processed by other UA application software. So the = ecall application is just one *user* of the sip session. >=20 > Of course the application environment may constrain the possibilities = in some way. But I think that is outside of our scope here. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Fri Aug 26 15:14: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 DB93412D149 for ; Fri, 26 Aug 2016 15:14:19 -0700 (PDT) X-Quarantine-ID: <9A8qnSFsZJ4N> 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: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 9A8qnSFsZJ4N for ; Fri, 26 Aug 2016 15:14:18 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4D12B016 for ; Fri, 26 Aug 2016 15:14:18 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 26 Aug 2016 15:14:17 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4d72d2808e9d4db5ac32d33e48cfb1e1@HE105660.emea1.cds.t-internal.com> References: <7594FB04B1934943A5C02806D1A2204B4BC27707@ESESSMB209.ericsson.se> <14243aab-b5f5-d3df-a7ea-a096cb37e0a8@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC279EB@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADF57389@FR712WXCHMBA11.zeu.alcatel-l ucent.com> <1EDD290B-4DE8-46B6-B6B7-671241F8FF0C@salsgiver.com> <7594FB04B1934943A5C02806D1A2204B4BC3552B@ESESSMB209.ericsson.se> <4d72d2808e9d4db5ac32d33e48cfb1e1@HE105660.emea1.cds.t-internal.com> X-Mailer: Eudora for Mac OS X Date: Fri, 26 Aug 2016 15:14:13 -0700 To: , , , From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Multipart with INFO 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, 26 Aug 2016 22:14:20 -0000 Hi Roland, At 5:53 AM +0000 8/24/16, wrote: > Hi, > Looking on Christer's Comment: > >>The question is whether the INFO request itself, and the MSD >> content transported in the INFO request, are >associated with the >> same "application" (ecall), and whether the MSD therefore must be >> sent using an Info >Package, as stated in 6086. > > Discussing this all the time I'm wondering if we cannot come up > with some text describing the "eCall" use case when using INFO with > additional data for the eCall scenario. And make it clear that the > application has to correlate the information. > I think all other cases are out of scope. > > Or I'm wrong? > > Best regards > > Roland The eCall use case when using INFO with additional data for the eCall scenario is: 1: IVS sends initial MSD in INVITE using Additional-Data 2: During the call, the PSAP call taker wants to see an updated MSD 2A: PSAP sends an INFO containing a request for the updated MSD (using INFO package) 2B: IVS responds with an INFO containing an ACK (using INFO package) 2C: IVS attaches an updated MSD to any convenient message using additional-data. The message might be the INFO with the ACK Note that the request and the ACK, which use an INFO package, can be considered a request/response application, which is a sub-component of the overall eCall application. Does this help clarify? --Randy -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nothing is so embarrassing as watching someone do something that you said couldn't be done. --Sam Ewing From nobody Tue Aug 30 08:00: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 5783712D92F for ; Tue, 30 Aug 2016 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Gj6F-Ho0hrtx for ; Tue, 30 Aug 2016 08:00:38 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 297F212D741 for ; Tue, 30 Aug 2016 07:54:55 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with SMTP id ekQHbOiRs1XXBekRCbZPb8; Tue, 30 Aug 2016 14:54:54 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-10v.sys.comcast.net with SMTP id ekRBbgTo2qnakekRCb9EYG; Tue, 30 Aug 2016 14:54:54 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UEsruZ009223 for ; Tue, 30 Aug 2016 10:54:53 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UEsrqU009220; Tue, 30 Aug 2016 10:54:53 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: ecrit@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Aug 2016 10:54:52 -0400 Message-ID: <87twe21f43.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOM+rP1SJ46WvBKNSPmIi8Rb3jEEZ+OTdGrUWk7M+GxVpm0EofOi6743geWXdF5ntPfK5eX3iBvJ2Eg89D0S/o+qMu1NZ8cipZuxj2k+bMW+6v0RfODI H1KeOFoZv5rZ0FtPhcuLiLb/2DnWPQirfUYSwyjYeOJ9d48Zo+dG3NEf Archived-At: Subject: [Ecrit] Errata and queries re draft-ietf-ecrit-ecall-11 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, 30 Aug 2016 15:00:39 -0000 Note that the <...> around the URL in the value of a Call-Info header is mandatory (RFC 3261 section 25.1): Call-Info = "Call-Info" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( "purpose" EQUAL ( "icon" / "info" / "card" / token ) ) / generic-param All four example Call-Info headers in draft-ietf-ecrit-ecall-11 omit the <...>: Call-Info: cid:1234567890@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; Call-Info: cid:2345678901@atlanta.example.com; purpose=emergencyCallData.eCall.control; Call-Info: cid:3456789012@atlanta.example.com; purpose=emergencyCallData.eCall.control; Call-Info: cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; In addition, all of these headers end with an incorrect semicolon. RFC 6086 section 4.2.1 says: The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods (and their responses) listed in Section 5. But draft-ietf-ecrit-ecall-11 has two places in section 11 where example INFO requests contain a Recv-Info header: INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=9fxced76sl From: Exemplar PSAP Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:3456789012@atlanta.example.com; purpose=emergencyCallData.eCall.control; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml, application/emergencyCallData.eCall.MSD+per CSeq: 41862 INFO Recv-Info: emergencyCallData.eCall.MSD ... INFO urn:service:sos.ecall.automatic SIP/2.0 To: urn:service:sos.ecall.automatic From: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Call-Info: cid:4567890123@atlanta.example.com; purpose=emergencyCallData.eCall.MSD; Accept: application/sdp, application/pidf+xml, application/emergencyCallData.eCall.control+xml CSeq: 51862 INFO Recv-Info: emergencyCallData.eCall.MSD ... Why do the example INFO requests in that draft not have Info-Package headers, even though the Info-Package header is central to the interpretation of an info package INFO request? It is clear how the caller detects that it must resend its Additional Data, it is requested to by the callee. But how do the transit networks detect that they must resend their Additional Data, i.e., attach it to the resulting INFO request? Must they scan all transiting INFO requests for use of the ACK info package? I suppose that that can be specified, and indeed, only requests to urn:service:sos:* URIs need be scanned, so the overhead is probably small. (Scanning the INFO requests would be much the same as scanning the INVITE requests, but everybody expects INVITE processing to be heavier than in-dialog request processing.) Dale From nobody Tue Aug 30 08:45: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 A295E12D925 for ; Tue, 30 Aug 2016 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 0R-j_Gage50M for ; Tue, 30 Aug 2016 08:45:52 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 619C312D92B for ; Tue, 30 Aug 2016 08:21:29 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-04v.sys.comcast.net with SMTP id ekpNbLnVy8PeaekqubXW2G; Tue, 30 Aug 2016 15:21:28 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-18v.sys.comcast.net with SMTP id ekqtbbDLa67itekqubtj1z; Tue, 30 Aug 2016 15:21:28 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UFLR7O011898 for ; Tue, 30 Aug 2016 11:21:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UFLQsY011895; Tue, 30 Aug 2016 11:21:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: ecrit@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 30 Aug 2016 11:21:26 -0400 Message-ID: <87k2ey1dvt.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfE54EgVvx4ru82HVBGH5/r3DehI5VfuQZcUSJ1SP5pklCSSdmWFYQHoRv86k0YIdcB+lW9fE5ikz/0rO7Wkum/gNwO78dRX2GpYbuRmTa33bx7/bHVlp shzd/9ZhvUlAYbH7D9LReoAP6/c2ffY7iUc74ohM/UQqEn4pYGpBsSsS Archived-At: Subject: [Ecrit] Comments on draft-ietf-ecrit-ecall-11 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, 30 Aug 2016 15:45:54 -0000 The section structure of section 10 is not what we want. It seems that the section is intended to be the registration of the info package, but section 10.1 is titled "INFO Package Requirements". But that section doesn't contain requirements, it contains within it all of the details of the definition of the info package as subsections. I think we want to remove the secction header 10.1 and promote all of its subsections to subsections of section 10, retitled "Definition of the emergencyCallData.eCall.MSD INFO package". Dale From nobody Tue Aug 30 08:58: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 0FCF812D8B3 for ; Tue, 30 Aug 2016 08:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=KNOemmfR; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=mZb8WOct 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 LEXI04yLXOPe for ; Tue, 30 Aug 2016 08:58:00 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4882712B025 for ; Tue, 30 Aug 2016 08:36:03 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B318620571 for ; Tue, 30 Aug 2016 11:36:02 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 30 Aug 2016 11:36:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=jXn iXauSmxahkuuGwPkAEi/GFK4=; b=KNOemmfRGTU75bQmDp0LvFUXhP8HZ/vrClM qsUjmdmSJ+U2/4d9HrHrgjC2XSvTQa4QI5WvX0twYYRTFa18z67+TAJny/z2KjIP YZ8kmt3G4ln7jwtyrLnNvqF0lnU5uHQhkplmtGPLp9VPwL7GKksXHylIKa2n3M/o tsu3AZq8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=jXniXauSmxahkuuGwPkAEi/GFK4=; b=mZb8W OctyFSiYqWOUI6k6mHe2A1AMGbChOQskkLorA+sWIWk5qRkFGRSIFVW19LtdVJAq LiRiy8MATPYISboh0d933zrs1E9K7s45MnVnCgDJYGoi+Jjef07/XlNq26Ngh494 TBcgLJ/RoHQ+ElO4gaIQEsLZysJ+YfvuWbEqA8= X-Sasl-enc: lkDOI3EQMU05POL/+dcj+5kQ5kqP4mg7Zo5LCYKZYlfZ 1472571362 Received: from dhcp-10-150-9-143.cisco.com (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 70A06F29CC for ; Tue, 30 Aug 2016 11:36:02 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 30 Aug 2016 11:36:01 -0400 To: Emergency Context Resolution with Internet Technologies Discussion List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Ecrit] Chair update 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, 30 Aug 2016 15:58:03 -0000 Hi all, Marc Linsner has stepped down as ECRIT co-chair. Huge thanks to Marc for = his many years of leadership in this WG. Allison Mankin has agreed to join Roger as ECRIT co-chair. Welcome, = Allison!=20 Alissa=