From nobody Tue Mar 1 13:55:48 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 DF33B1B4240; Tue, 1 Mar 2016 13:55:46 -0800 (PST) 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.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160301215546.4661.85781.idtracker@ietfa.amsl.com> Date: Tue, 01 Mar 2016 13:55:46 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-11.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:55:47 -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 : Data-Only Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Randall Gellens Filename : draft-ietf-ecrit-data-only-ea-11.txt Pages : 23 Date : 2016-03-01 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is all that is needed. Examples of such environments include alerts issued by a temperature sensor, burglar alarm, or chemical spill sensor. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-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 Thu Mar 3 12:29:51 2016 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A611B4120 for ; Thu, 3 Mar 2016 11:47:44 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee7TG5g_QwrN for ; Thu, 3 Mar 2016 11:47:42 -0800 (PST) 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 9C3851B4242 for ; Thu, 3 Mar 2016 11:47:41 -0800 (PST) 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 u23JlIKv022483 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2016 11:47:18 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.119]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Thu, 3 Mar 2016 11:47:17 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-11.txt Thread-Index: AQHRdAUsxx/fGmoO/0aCbjZdL8Y4ZZ9GygPggAFXqHA= Date: Thu, 3 Mar 2016 19:47:17 +0000 Message-ID: References: <20160301215546.4661.85781.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 03 Mar 2016 12:29:49 -0800 Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-11.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 19:47:44 -0000 IoT is getting lots of attention, and so is its potential impact on emergen= cy services.=20 The chairs of ECRIT would like to get some reviews for the ecrit-data-only-= ea draft, the goal being to submit it for IESG processing ahead of IETF95. = =20 Please respond to the list if you are able to provide a review w/comments t= o this draft over the next couple weeks. Thanks. -roger marshall. roger.marshall@comtechtel.com -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Tuesday, March 01, 2016 1:56 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Internet= Technologies of the IETF. Title : Data-Only Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Randall Gellens Filename : draft-ietf-ecrit-data-only-ea-11.txt Pages : 23 Date : 2016-03-01 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is all that is needed. Examples of such environments include alerts issued by a temperature sensor, burglar alarm, or chemical spill sensor. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-11 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ 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. From nobody Wed Mar 9 07:25: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 4B38C12E219 for ; Wed, 9 Mar 2016 07:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obzt6km8Iw99 for ; Wed, 9 Mar 2016 07:19:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C1C12E0EE for ; Wed, 9 Mar 2016 07:05:13 -0800 (PST) Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnCkb-1aCYva09td-00hJr9 for ; Wed, 09 Mar 2016 16:05:11 +0100 To: "ecrit@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56E03BA4.5080104@gmx.net> Date: Wed, 9 Mar 2016 16:05:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lthrgxdX54BTWdGiIF9gVTDJSbDaDWqrD" X-Provags-ID: V03:K0:GMOBuA+BhF3bhQGdHkVmGWf5L/YmLV80m6i13QlxZcpd1PCKo+L xgEGkSU5cSru+Nw21xGDljwXAVMdkiHMW0te5fm3Zli2u9fhxLfpLzZwHM0bqynaG8YDob0 ZvQet3RI5mR53+S65VXhrKURgNi4wYUtLH4wy2Q4o2i0AlQcUfgoQWifWoZzNOptvZHYaCh lq6kdudwUsvIokL86qZpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GurQC4w+5As=:WNLlR6VnPJW3wtdICXzzka noYOUhNzewdwD0k5UdHFca188p0I7c1jzP7btcmFHaxBMIOGyDPRPa/HTCJHjj/eEjYyzqyHe cG3L12jazPF6IddjG5NlcQNlQ5i1bI9AEJmO6Td2Qe/xMoiMIVomH8V/n+AAlHIX1r0U6Z2Of VNGELv9HY3Z8ZMMAK2O3V6Fq2uin2Y23N9hIo6Lfes9mZnT3qZLiAn4SDf2Bgghm4AhvT9Oo8 b63jgdDhIzrlgDV3I/4UI2ZOPju7Xb6ESlTmAiGlD33syN9MBwEduCtlE0JLC71WqDBgfOKGp uozY6LhIwb4JUisTLGrs7Iuyfq8/JPoNGlBSre5K0WAQg4Ma2XQqCOo35vZhYkx4W6r01Pk5+ t7Xb86NEjMbnYF2HYMF0YqAN8BowIBesXo7fylEdMjXPGwTFcGxX2Qfq9456tn+rrbNvIuEIw TUthwvudVNfYjlja8IzA8xhGL9wzENoeOeQ5G22YlRJGF2DLY7CVCymk+7F4iNb24YCyiAfYi WYdgsLHXHZW9AMjQUGp/hYfTtOXpFv7F+YGeoG+Unol0lopc4UuTwISLjbA34yrxMBC3RAeYT +IKojp1QNpqvqPZrBnPL3Dtp1q8d+2sseDhqukkjdH4D5cQ/lOk+gg9zmZ4ihzvjAXUG0o/XZ Qk6Fb3qNRfPagzIAQw6Ny3Ita74+Avj43qC2B748U44j2yaLo+bRp277ikNN/PB5svC1hqNJY 1pU5gKVFAXpefxDr9AbJGFaf0iY+50pu2u+qKWH0jSGQkudSNgJeCFXE0tk= Archived-At: Subject: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 09 Mar 2016 15:19:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lthrgxdX54BTWdGiIF9gVTDJSbDaDWqrD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, James has been working in EENA on extensions for the additional data draft and has also been playing around with code. As part of that exercise he discovered bugs, which I like to bring to your attention. As a high-level summary, we believe the following changes are needed based on the bugs he discovered: * fixes to examples, * normative changes to the vcard XML schema found in the appendix, and * addition of a new IANA registry. Here are the details: -- Issue #1: James discovered a bug in Figure 17 of version -37 with regard to the xc namespace prefix. Here is the snippet: This is a copy-and-paste error since the referenced schemas at http://ip-emergency.net/additional-data.zip contain the correct instance documents. -- Issue #2: James noticed a problem with the value 'main-number' used in the following example: work voice *main-number* sips:john.doe@example.com main-number is not a valid type according the schema from Section 6.4.1 of RFC 6351. RFC 6351 lists the valid types as: * =E2=80=9Cwork" * =E2=80=9Chome" * =E2=80=9Ctext" * =E2=80=9Cvoice" * =E2=80=9Cfax" * =E2=80=9Ccell" * =E2=80=9Cvideo" * =E2=80=9Dpager" * "textphone" This looks like a minor issue since we already state in the text that 'main-number' is a new value this draft introduces. However, the way the XML schema in RFC 6351 is defined you cannot just add values since it contains an enumeration with a fixed list of values. The reason we have not noticed this earlier is because the example in Figure 17 the content of the zip file is again out of sync with what is in the draft. The example in the zip file does not contain the text main-number and hence no error shows up. Of course, if I use the main-number (as shown in the body of the draft) then an error is thrown. Needless to say that this is a problem. What can we do about this? Currently, the XML schema in Appendix A is informative and the Relax NG schema in RFC 6351 is normative. We can make the XSD schema currently found in Appendix A normative and, at least, add this new value (main-number). Then, there is the question whether this will be the only value ever added. If so, then it is fine to add it to the enumeration. If it is not then we need to go a different path, namely to just declare it as a string and register the values with IANA. Because of this normative change we need to reach out to you. If you have other suggestions on what we should do please let us know! Ciao Hannes --lthrgxdX54BTWdGiIF9gVTDJSbDaDWqrD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW4DukAAoJEGhJURNOOiAt14AH/RbkowhbGQ6QMjuCT+EFNZ0/ XE6T8RChoxNsnD0RN/OgCnZcYWCcv1+Cuzfj0Y5f8POFot1DqQJdntcy0EGQQQTb IZ3RMtQuGJZ+JvGxSZVmvVZRx+2vAt/xZlq/60jxTs1c+nOGkUSZGHMjHnvDDgvK iyqtPO86CbrH0Jg9OdO8dPbZZ0hpKb2sz3zQrQASOXgRG2AVxpO17WT2VpZMPWAY IKARAPDH+MOxnujlnwLxMMYAH9hxi5YVAVXppmQfLtEJvFizRNGxpMAt7SnJ1v5A uYL/nmWAo2OtqtQJeprT3A6Yue6Ju28ZD2EOjhfzl/3pNGJXCU0Og2LNoYUqcMA= =9QTs -----END PGP SIGNATURE----- --lthrgxdX54BTWdGiIF9gVTDJSbDaDWqrD-- From a.james.winterbottom@gmail.com Wed Mar 9 12:45: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 C251112D9A9 for ; Wed, 9 Mar 2016 12:45:44 -0800 (PST) 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, FREEMAIL_FROM=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=gmail.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 bnv_e7QhCl6F for ; Wed, 9 Mar 2016 12:45:42 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 A7E6812D88E for ; Wed, 9 Mar 2016 12:45:42 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id fl4so48470923pad.0 for ; Wed, 09 Mar 2016 12:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=KfapR0L95CC686gAEZnkddFS7rpTLUtznNSYDEJzI+I=; b=yTtUCvfIp165fOTBd27fDpkN1PuibKIm/tNrnMzx/MLIZe/32olKxqRuZr94rK2Ui+ YwdPMgZEExT6bcGf7TRFYb6DyqCBAVw3zNEaboCZnP5QGziZ3L+0zXhQwgNSNsw1AzZC dt9wjm149XyMqVimClu55M9BbMIp5/aUo+NNRgs6Z05UNBpky2hdD691dtC4zH9cENn7 WmXScrL7daR2qLBhU2UzbaYZi91XE2VSgoQq3n9kW+SVWQoHLXZp3BQhq0jxCpv1PNEO KZwUMuUo2f3EXTrooVAYOSUk9AnFlOzfi0ZOaN6u3XRwww+YkF7iPkTEqXGOahB+Zkqt j/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=KfapR0L95CC686gAEZnkddFS7rpTLUtznNSYDEJzI+I=; b=lVIP63PE86T5e8XF/6FW3HPIpiZhkePhsD1POZIPfncjrWJv3vk3q5bXgRvLNQNcQ/ pTMylsxOFTYxdx+xM0YZ8TksQpoUZQUQ5DGE/ZM7DPn7UwWmZ3AcKwjlqE7jn8OMAGRF 5lawg5OhKg0p25ZNKFjkeRxl76XBXtkkGQ5bST+EZ1qZNdvqG/ZkHceqFFNae7dy8Vcd eV1+J+R4rKYnKRCNslRFQHV74KAlrcqTN6VrwuUeZm5UrR18KFHrW5ICTzQnJlOlMliY s84A0yO13j2jaQTBr99nTKiICHaWaFnSHcsLW4wA5UbD/VQHpYm1d7XcpxvkCNG453qs WbLQ== X-Gm-Message-State: AD7BkJIQVbYj734oVMuDEQZXZaX0dfOBvhSYjetaRLH/jzcrS8tMxj1YlaKzGNTniaROEQ== X-Received: by 10.67.4.233 with SMTP id ch9mr338149pad.29.1457556342288; Wed, 09 Mar 2016 12:45:42 -0800 (PST) Received: from [192.168.1.13] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id 23sm267545pfs.34.2016.03.09.12.45.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 12:45:41 -0800 (PST) References: <56E03BA4.5080104@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <56E03BA4.5080104@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <50C72F39-5F7A-4311-9C7B-A184900C2F7A@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Thu, 10 Mar 2016 07:45:34 +1100 To: Hannes Tschofenig Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 09 Mar 2016 20:45:44 -0000 It is also worth noting that we will require a new namespace for the cad sch= ema if we make it normative and update the examples accordingly. Cheers James Sent from my iPhone > On 10 Mar 2016, at 2:05 am, Hannes Tschofenig w= rote: >=20 > Hi all, >=20 > James has been working in EENA on extensions for the additional data > draft and has also been playing around with code. As part of that > exercise he discovered bugs, which I like to bring to your attention. >=20 > As a high-level summary, we believe the following changes are needed > based on the bugs he discovered: > * fixes to examples, > * normative changes to the vcard XML schema found in the appendix, and > * addition of a new IANA registry. >=20 > Here are the details: >=20 > -- Issue #1: James discovered a bug in Figure 17 of version -37 with > regard to the xc namespace prefix. Here is the snippet: >=20 > xmlns:xc=3D"urn:ietf:params:xml:ns:vcard-4.0"> >=20 > This is a copy-and-paste error since the referenced schemas at > http://ip-emergency.net/additional-data.zip contain the correct instance > documents. >=20 > -- Issue #2: James noticed a problem with the value 'main-number' used > in the following example: >=20 > > > > work > voice > *main-number* > > > sips:john.doe@example.com > >=20 > main-number is not a valid type according the schema from Section 6.4.1 > of RFC 6351. RFC 6351 lists the valid types as: >=20 > * =E2=80=9Cwork" > * =E2=80=9Chome" > * =E2=80=9Ctext" > * =E2=80=9Cvoice" > * =E2=80=9Cfax" > * =E2=80=9Ccell" > * =E2=80=9Cvideo" > * =E2=80=9Dpager" > * "textphone" >=20 > This looks like a minor issue since we already state in the text that > 'main-number' is a new value this draft introduces. However, the way the > XML schema in RFC 6351 is defined you cannot just add values since it > contains an enumeration with a fixed list of values. >=20 > The reason we have not noticed this earlier is because the example in > Figure 17 the content of the zip file is again out of sync with what is > in the draft. The example in the zip file does not contain the text > main-number and hence no error shows up. Of course, if I use the > main-number (as shown in the body of the draft) then an error is thrown. >=20 > Needless to say that this is a problem. >=20 > What can we do about this? >=20 > Currently, the XML schema in Appendix A is informative and the Relax NG > schema in RFC 6351 is normative. >=20 > We can make the XSD schema currently found in Appendix A normative and, > at least, add this new value (main-number). Then, > there is the question whether this will be the only value ever added. If > so, then it is fine to add it to the enumeration. If it is not then we > need to go a different path, namely to just declare it as a string and > register the values with IANA. >=20 > Because of this normative change we need to reach out to you. If you > have other suggestions on what we should do please let us know! >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Mar 9 16:38: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 C577C12DCF8 for ; Wed, 9 Mar 2016 16:38:29 -0800 (PST) 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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 YoUFmWE1QkIO for ; Wed, 9 Mar 2016 16:38:27 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 545F712DCC0 for ; Wed, 9 Mar 2016 16:38:27 -0800 (PST) Received: from [121.160.49.48] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 9 Mar 2016 16:38:54 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <56E03BA4.5080104@gmx.net> References: <56E03BA4.5080104@gmx.net> X-Mailer: Eudora for Mac OS X Date: Wed, 9 Mar 2016 16:35:31 -0800 To: Hannes Tschofenig , "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] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 10 Mar 2016 00:38:30 -0000 At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote: > Hi all, > > James has been working in EENA on extensions for the additional data > draft and has also been playing around with code. As part of that > exercise he discovered bugs, which I like to bring to your attention. > > As a high-level summary, we believe the following changes are needed > based on the bugs he discovered: > * fixes to examples, > * normative changes to the vcard XML schema found in the appendix, and > * addition of a new IANA registry. > > Here are the details: > > -- Issue #1: James discovered a bug in Figure 17 of version -37 with > regard to the xc namespace prefix. Here is the snippet: > > xmlns:xc="urn:ietf:params:xml:ns:vcard-4.0"> > > This is a copy-and-paste error since the referenced schemas at > http://ip-emergency.net/additional-data.zip contain the correct instance > documents. > > -- Issue #2: James noticed a problem with the value 'main-number' used > in the following example: > > > > > work > voice > *main-number* > > > sips:john.doe@example.com > > > main-number is not a valid type according the schema from Section 6.4.1 > of RFC 6351. RFC 6351 lists the valid types as: > > * "work" > * "home" > * "text" > * "voice" > * "fax" > * "cell" > * "video" > * "pager" > * "textphone" > > This looks like a minor issue since we already state in the text that > 'main-number' is a new value this draft introduces. However, the way the > XML schema in RFC 6351 is defined you cannot just add values since it > contains an enumeration with a fixed list of values. > > The reason we have not noticed this earlier is because the example in > Figure 17 the content of the zip file is again out of sync with what is > in the draft. The example in the zip file does not contain the text > main-number and hence no error shows up. Of course, if I use the > main-number (as shown in the body of the draft) then an error is thrown. > > Needless to say that this is a problem. > > What can we do about this? > > Currently, the XML schema in Appendix A is informative and the Relax NG > schema in RFC 6351 is normative. > > We can make the XSD schema currently found in Appendix A normative and, > at least, add this new value (main-number). Then, > there is the question whether this will be the only value ever added. If > so, then it is fine to add it to the enumeration. If it is not then we > need to go a different path, namely to just declare it as a string and > register the values with IANA. > > Because of this normative change we need to reach out to you. If you > have other suggestions on what we should do please let us know! The solution detailed by Hannes is a fine one, and is the approach I'd recommend if the draft was earlier in the process. Given the late stage, my preference is to make minimal changes to the draft. The minimalist approach would be the following: (1) fix the example to use 'main-number' (2) fix the xCard schema in Appendix A to add 'main-number' to the list of values (3) in the text in Section 4 that normatively adds 'main-number' to xCard, add an explanatory note that this new value is added in the xCard schema in the document but does not appear in RFC 6351, and note that should additional values be needed in the future, a new IANA registry of the values is recommended (4) in Appendix A, add a note that the schema is a simplified version of RFC 6351 with the addition of 'main-number' These changes are a way to fix the document with the least impact. There is no requirement that XML schemas in RFCs be normative since the text is always normative. There is no requirement to add an IANA registry when a list of strings is expanded. In new documents, it is cleaner and better to do both, but to fix late-stage bugs we can skip both. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The great Chinese philosopher Confucius wrote, "When words lose their meaning, the universe crumbles." Theologically and cosmologically, I'm not sure about that. I am sure that when our government is characterized as "amoral, godless and secularist," our public schools as "failures" and our judges as "tyrants," simplistic solutions promoted by demagogues will seem appropriate. -- Barry Lynn, Executive Director of Americans United for Separation of Church and State From nobody Wed Mar 9 17:23: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 460F312D692 for ; Wed, 9 Mar 2016 17:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 kPDdguUimQF5 for ; Wed, 9 Mar 2016 17:23:11 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 BEE1112D8C4 for ; Wed, 9 Mar 2016 17:23:11 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id tt10so53700485pab.3 for ; Wed, 09 Mar 2016 17:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=9/K3gcNHzimmQfgaZ5st7h5WS1yJRYV5qhIM8uwhR/Y=; b=FeeALNiR7zAZJUvOC6iwItavyE4LtWLacrUb9S6cyUzRlibTON9xc5ioBPm4uT6UgQ YVJdsTddbQTWiZsf6J/zoYS1PibIZ9Vif92vl+KW7Kbx9NPjhmHjImD2wottxHbyDcAC PirpLP4EW8CCO/xmIXhTWLevZ+XQFwA3nKAreRoLpct4xNx5ZhbXWv1eNNFC1az5wdR5 jK3Oz/UBvKrMeL5r/6y6jYW3oDuhrYTSfYtCIhKUBj4qDMR5vdjln1HKte+PCAGScc1P IHO9YVC0UzXXz0AM8DsYb9wLZ71O1kvI1Y/qnAsQ8n0brrirLlDkOU0Uj30PMAfwV3Zd guFQ== 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=9/K3gcNHzimmQfgaZ5st7h5WS1yJRYV5qhIM8uwhR/Y=; b=Gp25nKrBCUsY5A0hM5wf21VMcwAtFAtpKJlVFDy6qBm2UXXnFR2+XTD+m20wKq6IOd MonpYpIZE2jlZn8Xlh81vM8cQXD2urHira6xvEIReCCOlRu1HCfmBtKVVpq59EnRAmg6 zDAc48IOqkM4G52M5vnCvrJjRrm+cXOVNgImwGmwgdKKWSDurSogNBf0i2Bnr/md8mHj 33ndzkbPluhuzliHqYw5CCuuW/1c6xADiQuJ8Puok29DpJtAfJ/6Xn/fYUfwQ9pIx8PM /1cP4QmBdQ2Hi6LDp54LwU1/dfyni+mCdOGDk99kD+N8wMVv8sK5GVcBE/D5h/PEStSX JKDQ== X-Gm-Message-State: AD7BkJIjvt8XEz169iN/P4KkipMPtEGJe6rW3IVrYlvxPKaULpAMqN6qN4P9OcQAr1qTZw== X-Received: by 10.67.5.68 with SMTP id ck4mr1099895pad.3.1457572991321; Wed, 09 Mar 2016 17:23:11 -0800 (PST) Received: from [192.168.1.100] ([1.129.13.56]) by smtp.gmail.com with ESMTPSA id cq9sm898860pac.26.2016.03.09.17.23.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 17:23:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_92148B3D-246D-4CC5-B571-F2E9408833F5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Thu, 10 Mar 2016 12:23:05 +1100 Message-Id: References: <56E03BA4.5080104@gmx.net> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 10 Mar 2016 01:23:14 -0000 --Apple-Mail=_92148B3D-246D-4CC5-B571-F2E9408833F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I totally disagree with this approach and the argument that the document = is far progressed not a reasonable excuse for publishing a document that = has clear issues. The approach below results in two different schemas with the same = namespace one of which is considered normative and the other informative = yet the additional-data specification will require use of the = informative schema. What is the issue with altering the schema to accommodate what we want, = move the undesirable token sets into a repository, change the namespace = and making it normative? This ensures integrity of namespaces, it doesn=E2=80=99t really = structurally change the document, but it does result in a much better = outcome. Cheers James > On 10 Mar 2016, at 11:35 am, Randall Gellens = wrote: >=20 > At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote: >=20 >>=20 >> Because of this normative change we need to reach out to you. If you >> have other suggestions on what we should do please let us know! >=20 > The solution detailed by Hannes is a fine one, and is the approach I'd = recommend if the draft was earlier in the process. Given the late = stage, my preference is to make minimal changes to the draft. The = minimalist approach would be the following: >=20 > (1) fix the example to use 'main-number' > (2) fix the xCard schema in Appendix A to add 'main-number' to the = list of values > (3) in the text in Section 4 that normatively adds 'main-number' to = xCard, add an explanatory note that this new value is added in the xCard = schema in the document but does not appear in RFC 6351, and note that = should additional values be needed in the future, a new IANA registry of = the values is recommended > (4) in Appendix A, add a note that the schema is a simplified = version of RFC 6351 with the addition of 'main-number' >=20 > These changes are a way to fix the document with the least impact. = There is no requirement that XML schemas in RFCs be normative since the = text is always normative. There is no requirement to add an IANA = registry when a list of strings is expanded. In new documents, it is = cleaner and better to do both, but to fix late-stage bugs we can skip = both. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The great Chinese philosopher Confucius wrote, "When words lose their > meaning, the universe crumbles." Theologically and cosmologically, = I'm > not sure about that. I am sure that when our government is > characterized as "amoral, godless and secularist," our public schools > as "failures" and our judges as "tyrants," simplistic solutions > promoted by demagogues will seem appropriate. > -- Barry Lynn, > Executive Director of > Americans United for Separation of Church and State >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_92148B3D-246D-4CC5-B571-F2E9408833F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I totally disagree with this approach and the argument that = the document is far progressed not a reasonable excuse for publishing a = document that has clear issues.

The approach below results in two different schemas with the = same namespace one of which is considered normative and the other = informative yet the additional-data specification will require use of = the informative schema.

What is the issue with altering the schema to accommodate = what we want, move the undesirable token sets into a repository, change = the namespace and making it normative?
This ensures = integrity of namespaces, it doesn=E2=80=99t really structurally change = the document, but it does result in a much better outcome.

Cheers
James




On 10 Mar 2016, at 11:35 am, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

At 4:05 PM +0100 3/9/16, Hannes Tschofenig = wrote:


Because of this normative change we need = to reach out to you. If you
have other suggestions on what = we should do please let us know!

The solution detailed by Hannes is a fine one, = and is the approach I'd recommend if the draft was earlier in the = process.  Given the late stage, my preference is to make minimal = changes to the draft. The minimalist approach would be the = following:

  (1) fix the = example to use 'main-number'
  (2) fix the = xCard schema in Appendix A to add 'main-number' to the list of = values
  (3) in the = text in Section 4 that normatively adds 'main-number' to xCard, add an = explanatory note that this new value is added in the xCard schema in the = document but does not appear in RFC 6351, and note that should = additional values be needed in the future, a new IANA registry of the = values is recommended
  (4) in = Appendix A, add a note that the schema is a simplified version of RFC = 6351 with the addition of 'main-number'

These changes are a way to fix the document with = the least impact. There is no requirement that XML schemas in RFCs be = normative since the text is always normative.  There is no = requirement to add an IANA registry when a list of strings is expanded. =  In new documents, it is cleaner and better to do both, but to fix = late-stage bugs we can skip both.

-- 
Randall Gellens
Opinions are personal;    facts = are suspect;    I speak for myself only
-------------- Randomly selected tag: = ---------------
The great Chinese = philosopher Confucius wrote, "When words lose their
meaning, the universe crumbles." =  Theologically and cosmologically, I'm
not sure about that.  I am sure that when = our government is
characterized as "amoral, = godless and secularist," our public schools
as "failures" and our judges as "tyrants," = simplistic solutions
promoted by demagogues = will seem appropriate.
-- Barry Lynn,
 Executive Director of
 Americans United for Separation of Church = and State

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

= --Apple-Mail=_92148B3D-246D-4CC5-B571-F2E9408833F5-- From nobody Wed Mar 9 18:55: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 DEA8E12DAE3 for ; Wed, 9 Mar 2016 18:55:43 -0800 (PST) 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, FREEMAIL_FROM=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=gmail.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 SmpS3J3gntwa for ; Wed, 9 Mar 2016 18:55:41 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 64BE512DB0B for ; Wed, 9 Mar 2016 18:55:41 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id z76so90451467iof.3 for ; Wed, 09 Mar 2016 18:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Tn+RNc3MgyfGmqGlAKexmTcaWmsx+GLoWeqpl20b0gs=; b=jkvCE2GgPQwFqcB7F3YmHp1N2UaqwciyD3yYu5vfwIcPohMQr3Muw1h6lcMR3PzdD5 UygNgiLT3Uf/hhb65kLOxwVrxTEcZO9w5pvlK1kjychN/DoOA+NLQ8qDtMn+v1hnUdwf VZGLVyc8A9uphmFCnH8M/pXp9U+wd0eAJNPk5laTsENH/8m76GufPio9Eot6usRBdw2B musFFvTbEOYjh8EuQTLutjknwCEpU1UPRTyGBwxndPI1Cp4aSbkSKiegdvV4173lSUI1 d6ns0juQJaZzklSd0jlKrL8F9Z7uOKi5LundMEhc3L7c/w+Wca+giPwbG5mgIHPZnQJP aANg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Tn+RNc3MgyfGmqGlAKexmTcaWmsx+GLoWeqpl20b0gs=; b=DBmQ9r+ZlPZJYvvkNUwlNBozSPnBSgpSZ3yZTbH/5WFjUfU4vCq2MGa7o/irVy4R5q cPTWIZzRUSOc9sW+okuhBxGj9BKjLvaXkf3yXyVdjDjq6EjpzRUHbuv93cElGVb0hYos nXTAkIrl6czitB6fNcXY8fCrDvF8J47w0aXysL8IfVgINwkPiL4sdjoIi1lIEnSjt4Cg VKk0hQbJf+bGNkv5XaIz2lHcMU8cXptNcL4TYWegD0zJXxXjtn5lRvR2IDuijvsL3pYh WaAXaldKsyWHFBWjf4RtWyJpcyUs13uxDIYarl1g/U/A7RGcbjrwNP/osGU/cSBIPizB vw1A== X-Gm-Message-State: AD7BkJIvnfHvS05o+PL0PU+YJWrPdWKxT0ljLNM8OJGT9GB6pWh77m55YwgG+vPWXO4DifuYylID69Tb9fDWJw== MIME-Version: 1.0 X-Received: by 10.107.131.105 with SMTP id f102mr1218912iod.190.1457578540482; Wed, 09 Mar 2016 18:55:40 -0800 (PST) Received: by 10.36.43.5 with HTTP; Wed, 9 Mar 2016 18:55:40 -0800 (PST) In-Reply-To: References: <56E03BA4.5080104@gmx.net> Date: Thu, 10 Mar 2016 13:55:40 +1100 Message-ID: From: Martin Thomson To: James Winterbottom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 10 Mar 2016 02:55:44 -0000 James is right here. An implementation of RFC 6351 will choke on this new value. The correct way to address this is to make a new schema that patches the RFC 6351 schema. In relax NG that's easy [1], because you only have to redefine "property-tel". But you do need to give it a new namespace. An XML schema is tough. [1] http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html On 10 March 2016 at 12:23, James Winterbottom wrote: > I totally disagree with this approach and the argument that the document = is > far progressed not a reasonable excuse for publishing a document that has > clear issues. > > The approach below results in two different schemas with the same namespa= ce > one of which is considered normative and the other informative yet the > additional-data specification will require use of the informative schema. > > What is the issue with altering the schema to accommodate what we want, m= ove > the undesirable token sets into a repository, change the namespace and > making it normative? > This ensures integrity of namespaces, it doesn=E2=80=99t really structura= lly change > the document, but it does result in a much better outcome. > > Cheers > James > > > > > On 10 Mar 2016, at 11:35 am, Randall Gellens > wrote: > > At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote: > > > Because of this normative change we need to reach out to you. If you > have other suggestions on what we should do please let us know! > > > The solution detailed by Hannes is a fine one, and is the approach I'd > recommend if the draft was earlier in the process. Given the late stage,= my > preference is to make minimal changes to the draft. The minimalist approa= ch > would be the following: > > (1) fix the example to use 'main-number' > (2) fix the xCard schema in Appendix A to add 'main-number' to the list= of > values > (3) in the text in Section 4 that normatively adds 'main-number' to xCa= rd, > add an explanatory note that this new value is added in the xCard schema = in > the document but does not appear in RFC 6351, and note that should > additional values be needed in the future, a new IANA registry of the val= ues > is recommended > (4) in Appendix A, add a note that the schema is a simplified version o= f > RFC 6351 with the addition of 'main-number' > > These changes are a way to fix the document with the least impact. There = is > no requirement that XML schemas in RFCs be normative since the text is > always normative. There is no requirement to add an IANA registry when a > list of strings is expanded. In new documents, it is cleaner and better = to > do both, but to fix late-stage bugs we can skip both. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The great Chinese philosopher Confucius wrote, "When words lose their > meaning, the universe crumbles." Theologically and cosmologically, I'm > not sure about that. I am sure that when our government is > characterized as "amoral, godless and secularist," our public schools > as "failures" and our judges as "tyrants," simplistic solutions > promoted by demagogues will seem appropriate. > -- Barry Lynn, > Executive Director of > Americans United for Separation of Church and State > > _______________________________________________ > 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 Mar 11 12:31: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 0FAE012DB55 for ; Fri, 11 Mar 2016 12:31:51 -0800 (PST) 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: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 JX6FAqeS_W6Q for ; Fri, 11 Mar 2016 12:31:48 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B8EED12DB5E for ; Fri, 11 Mar 2016 12:31:23 -0800 (PST) Received: from [172.16.45.173] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 11 Mar 2016 12:31:52 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <56E03BA4.5080104@gmx.net> X-Mailer: Eudora for Mac OS X Date: Fri, 11 Mar 2016 12:31:17 -0800 To: James Winterbottom , Randall Gellens 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] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 11 Mar 2016 20:31:51 -0000 At 12:23 PM +1100 3/10/16, James Winterbottom wrote: > I totally disagree with this approach and the argument that the > document is far progressed not a reasonable excuse for publishing a > document that has clear issues. I never said to publish a document with defects. I was proposing one approach to solve the defects without opening up a lot of new work. > > The approach below results in two different schemas with the same > namespace one of which is considered normative and the other > informative yet the additional-data specification will require use > of the informative schema. So we also need to add a new namespace for the corrected schema. > > What is the issue with altering the schema to accommodate what we > want, move the undesirable token sets into a repository, change the > namespace and making it normative? > This ensures integrity of namespaces, it doesn't really > structurally change the document, but it does result in a much > better outcome. I said that was the cleaner approach, and one I'd take with a new document. I just don't think we need to do all those steps now. >> On 10 Mar 2016, at 11:35 am, Randall Gellens >> <rg+ietf@randy.pensive.org> >> wrote: >> >> At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote: >> >>> >>> Because of this normative change we need to reach out to you. If you >>> have other suggestions on what we should do please let us know! >>> >> >> The solution detailed by Hannes is a fine one, and is the approach >> I'd recommend if the draft was earlier in the process. Given the >> late stage, my preference is to make minimal changes to the draft. >> The minimalist approach would be the following: >> >> (1) fix the example to use 'main-number' >> (2) fix the xCard schema in Appendix A to add 'main-number' to >> the list of values >> (3) in the text in Section 4 that normatively adds 'main-number' >> to xCard, add an explanatory note that this new value is added in >> the xCard schema in the document but does not appear in RFC 6351, >> and note that should additional values be needed in the future, a >> new IANA registry of the values is recommended >> (4) in Appendix A, add a note that the schema is a simplified >> version of RFC 6351 with the addition of 'main-number' >> >> These changes are a way to fix the document with the least impact. >> There is no requirement that XML schemas in RFCs be normative >> since the text is always normative. There is no requirement to >> add an IANA registry when a list of strings is expanded. In new >> documents, it is cleaner and better to do both, but to fix >> late-stage bugs we can skip both. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> The great Chinese philosopher Confucius wrote, "When words lose their >> meaning, the universe crumbles." Theologically and cosmologically, I'm >> not sure about that. I am sure that when our government is >> characterized as "amoral, godless and secularist," our public schools >> as "failures" and our judges as "tyrants," simplistic solutions >> promoted by demagogues will seem appropriate. >> -- Barry Lynn, >> Executive Director of >> Americans United for Separation of Church and State >> >> _______________________________________________ >> 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: --------------- One might say that the right's approach is to release the dogs of the market, throwing all traditional values into disarray; and then, in this tumult of insecurity, offer themselves up as the last bastion of order and hierarchy, the stalwart defenders of the authority of churches and fathers against the barbarians they have themselves unleashed. A scam it may be, but it is a remarkably effective one; and one result is that the right ends up seeming to have a monopoly on value. --David Graeber, "Army of Altruists", Harper's, January 2007. From nobody Sat Mar 12 19:33: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 EAC1E12D5DF for ; Sat, 12 Mar 2016 19:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 GDGmTIQlRUyP for ; Sat, 12 Mar 2016 19:33:53 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 6CD4D12D8AE for ; Sat, 12 Mar 2016 19:33:52 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id u190so81615629pfb.3 for ; Sat, 12 Mar 2016 19:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=qJP6cSyR16PO2TNzy6RkCSRLu7abyv/lu0ZjDffYwgc=; b=bxro8KmAEoyRewmjqO+S+oxnXaZzDQ+fO9Vp8MBc1bvB97O/Ihjaye4PEHdr47jE0p rR89x/c6ekFZOFi10u0kR3d1JC85aSRFImDpBts0vid5OVYR758f3IrEjG2/vr59S0xp 0zfOgSDsd4lt2TLUQWhPIBeSYn56GDhrfoGlLLwzcQ4j/TMVin/flAUTOVFjhbm2tr3Z Bbcexa2Rc5ZTvo4N3elIvlC+yuKrNu5EZoXTH6s8D67D3KvkFoDqaxiC0q7GWXmjKLYm 6Aq1HXms/4B9UocWOW2HvFRrdepEo+86rPvBrEwIda84cNr6Yc4FWw7I8IOlxyLtvXjC Uvyw== 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=qJP6cSyR16PO2TNzy6RkCSRLu7abyv/lu0ZjDffYwgc=; b=LYoVQ+7XLrcELMUjYf/xpUKv8c0/uJjEqlJLx+GDtr7YEtib1nNkEjxT+eClppS0cW OtuhXUFpppUAEvLPUMMoTI3hFOQpc4gigeDnAw+ynBuKpdB20Uh66P5db3tRRDUfsKIt wksgG1zGh0SLE1DkEiqakTmceqEqzEK+XZ1J+ijme28ayCGHe1amAsdRJemyRqMbWIYE 6zFGU1wGA3HpA0EBTz0zGvLlobinxQ6KPVDjMw7fO/lfTQLo+NzoorGwc0aZqadj3/dW UwUN7e3kw2LD+KKuEN1QIHCoQMr6lwk/qCqPKFypCWFVDjmeGM83eAo1cj9R6S7xL7PS MOFw== X-Gm-Message-State: AD7BkJKA3Kb71DRZOn+PeNGWBgnv3g71RWG9kyHH260wiWB46bDSzwjBvTnP4O01wg3wsA== X-Received: by 10.98.8.74 with SMTP id c71mr19957400pfd.155.1457840031982; Sat, 12 Mar 2016 19:33:51 -0800 (PST) Received: from [192.168.1.100] ([1.144.87.93]) by smtp.gmail.com with ESMTPSA id 79sm22633487pfq.65.2016.03.12.19.33.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 19:33:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4432DF00-3EE9-4482-878A-DD150E838AAF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Sun, 13 Mar 2016 14:33:46 +1100 Message-Id: <42350452-98EE-40EF-915D-EBBC186BEEED@gmail.com> References: <56E03BA4.5080104@gmx.net> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 13 Mar 2016 03:33:56 -0000 --Apple-Mail=_4432DF00-3EE9-4482-878A-DD150E838AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Mar 2016, at 7:31 am, Randall Gellens = wrote: >=20 > At 12:23 PM +1100 3/10/16, James Winterbottom wrote: >=20 >> I totally disagree with this approach and the argument that the=20 >> document is far progressed not a reasonable excuse for publishing a=20= >> document that has clear issues. >=20 > I never said to publish a document with defects. I was proposing one=20= > approach to solve the defects without opening up a lot of new work. >=20 >>=20 >> The approach below results in two different schemas with the same=20 >> namespace one of which is considered normative and the other=20 >> informative yet the additional-data specification will require use=20 >> of the informative schema. >=20 > So we also need to add a new namespace for the corrected schema. [AJW] I am afraid that we do and this means that we should probably = normatively update RFC 6351 >=20 >>=20 >> What is the issue with altering the schema to accommodate what we=20 >> want, move the undesirable token sets into a repository, change the=20= >> namespace and making it normative? >> This ensures integrity of namespaces, it doesn't really=20 >> structurally change the document, but it does result in a much=20 >> better outcome. >=20 > I said that was the cleaner approach, and one I'd take with a new=20 > document. I just don't think we need to do all those steps now. [AJW] I don=E2=80=99t think that it is a question of =E2=80=9Cneed to do = all those steps now=E2=80=9D. If we don=E2=80=99t do them, then they are = not done. This isn=E2=80=99t something that we are going to go and clean = up later. We aren=E2=80=99t going to change the structure, or even make = other corrections that I would dearly love to see. We are just going to = change the name space, change an enumeration into a token that is filled = from a repository, and make the schema normative. Small changes, but = will allow the document to move forward in a clean fashion. >=20 >=20 >>> On 10 Mar 2016, at 11:35 am, Randall Gellens=20 >>> <rg+ietf@randy.pensive.org>=20 >>> wrote: >>>=20 >>> At 4:05 PM +0100 3/9/16, Hannes Tschofenig wrote: >>>=20 >>>>=20 >>>> Because of this normative change we need to reach out to you. If = you >>>> have other suggestions on what we should do please let us know! >>>>=20 >>>=20 >>> The solution detailed by Hannes is a fine one, and is the approach=20= >>> I'd recommend if the draft was earlier in the process. Given the=20 >>> late stage, my preference is to make minimal changes to the draft.=20= >>> The minimalist approach would be the following: >>>=20 >>> (1) fix the example to use 'main-number' >>> (2) fix the xCard schema in Appendix A to add 'main-number' to=20 >>> the list of values >>> (3) in the text in Section 4 that normatively adds 'main-number'=20= >>> to xCard, add an explanatory note that this new value is added in=20 >>> the xCard schema in the document but does not appear in RFC 6351,=20 >>> and note that should additional values be needed in the future, a=20 >>> new IANA registry of the values is recommended >>> (4) in Appendix A, add a note that the schema is a simplified=20 >>> version of RFC 6351 with the addition of 'main-number' >>>=20 >>> These changes are a way to fix the document with the least impact.=20= >>> There is no requirement that XML schemas in RFCs be normative=20 >>> since the text is always normative. There is no requirement to=20 >>> add an IANA registry when a list of strings is expanded. In new=20 >>> documents, it is cleaner and better to do both, but to fix=20 >>> late-stage bugs we can skip both. >>>=20 >>> --=20 >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> The great Chinese philosopher Confucius wrote, "When words lose = their >>> meaning, the universe crumbles." Theologically and cosmologically, = I'm >>> not sure about that. I am sure that when our government is >>> characterized as "amoral, godless and secularist," our public = schools >>> as "failures" and our judges as "tyrants," simplistic solutions >>> promoted by demagogues will seem appropriate. >>> -- Barry Lynn, >>> Executive Director of >>> Americans United for Separation of Church and State >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>>=20 >>> = https://www.ietf.org/mailman/= listinfo/ecrit >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > One might say that the right's approach is to release the dogs of the > market, throwing all traditional values into disarray; and then, in > this tumult of insecurity, offer themselves up as the last bastion of > order and hierarchy, the stalwart defenders of the authority of > churches and fathers against the barbarians they have themselves > unleashed. A scam it may be, but it is a remarkably effective one; > and one result is that the right ends up seeming to have a monopoly on > value. --David Graeber, "Army of Altruists", Harper's, January 2007. --Apple-Mail=_4432DF00-3EE9-4482-878A-DD150E838AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Mar 2016, at 7:31 am, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

At 12:23 PM +1100 = 3/10/16, James Winterbottom wrote:

I totally disagree with = this approach and the argument that the
document is far = progressed not a reasonable excuse for publishing a
document that has clear issues.

I never said to publish a document with defects.  I was = proposing one
approach to solve the defects without = opening up a lot of new work.


The approach below results in = two different schemas with the same
namespace one of = which is considered normative and the other
informative = yet the additional-data specification will require use
of = the informative schema.

So we = also need to add a new namespace for the corrected schema.

[AJW] I am afraid that we do = and this means that we should probably normatively update RFC = 6351



What is the issue with altering the schema to = accommodate what we
want, move the undesirable token sets = into a repository, change the
namespace and making it = normative?
This ensures integrity of namespaces, it = doesn't really
structurally change the document, but it = does result in a much
better outcome.

I said that was the cleaner = approach, and one I'd take with a new
document.  I = just don't think we need to do all those steps now.

[AJW] I don=E2=80=99t think = that it is a question of =E2=80=9Cneed to do all those steps = now=E2=80=9D. If we don=E2=80=99t do them, then they are not done. This = isn=E2=80=99t something that we are going to go and clean up later. = We aren=E2=80=99t going to change the structure, or even make other = corrections that I would dearly love to see. We are just going to change = the name space, change an enumeration into a token that is filled from a = repository, and make the schema normative. Small changes, but will allow = the document to move forward in a clean = fashion.



On 10 Mar = 2016, at 11:35 am, Randall Gellens
<<mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org>
wrote:

At 4:05 PM +0100 3/9/16, Hannes Tschofenig = wrote:


Because of this normative change we need to = reach out to you. If you
have other suggestions on what = we should do please let us know!


The solution detailed by Hannes = is a fine one, and is the approach
I'd recommend if the = draft was earlier in the process.  Given the
late = stage, my preference is to make minimal changes to the draft.
The minimalist approach would be the following:

  (1) fix the example to use = 'main-number'
  (2) fix the xCard schema in = Appendix A to add 'main-number' to
the list of values
  (3) in the text in Section 4 that normatively = adds 'main-number'
to xCard, add an explanatory note that = this new value is added in
the xCard schema in the = document but does not appear in RFC 6351,
and note that = should additional values be needed in the future, a
new = IANA registry of the values is recommended
=   (4) in Appendix A, add a note that the schema is a = simplified
version of RFC 6351 with the addition of = 'main-number'

These changes are a way to = fix the document with the least impact.
There is no = requirement that XML schemas in RFCs be normative
since = the text is always normative.  There is no requirement to
add an IANA registry when a list of strings is expanded. =  In new
documents, it is cleaner and better to do = both, but to fix
late-stage bugs we can skip both.

--
Randall Gellens
Opinions are personal;    facts are suspect; =    I speak for myself only
-------------- = Randomly selected tag: ---------------
The great Chinese = philosopher Confucius wrote, "When words lose their
= meaning, the universe crumbles."  Theologically and cosmologically, = I'm
not sure about that.  I am sure that when our = government is
characterized as "amoral, godless and = secularist," our public schools
as "failures" and our = judges as "tyrants," simplistic solutions
promoted by = demagogues will seem appropriate.
-- Barry Lynn,
 Executive Director of
 Americans = United for Separation of Church and State

= _______________________________________________
Ecrit = mailing list
<mailto:Ecrit@ietf.org>Ecrit@ietf.org

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


-- =
Randall Gellens
Opinions are personal; =    facts are suspect;    I speak for = myself only
-------------- Randomly selected tag: = ---------------
One might say that the right's approach is = to release the dogs of the
market, throwing all = traditional values into disarray; and then, in
this tumult = of insecurity, offer themselves up as the last bastion of
order and hierarchy, the stalwart defenders of the authority = of
churches and fathers against the barbarians they have = themselves
unleashed.  A scam it may be, but it is a = remarkably effective one;
and one result is that the right = ends up seeming to have a monopoly on
value.  --David = Graeber, "Army of Altruists", Harper's, January 2007.

= --Apple-Mail=_4432DF00-3EE9-4482-878A-DD150E838AAF-- From nobody Mon Mar 14 06:04:05 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 6F30212DDA4; Fri, 11 Mar 2016 15:05:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230524.15028.49520.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:24 -0800 Archived-At: X-Mailman-Approved-At: Mon, 14 Mar 2016 06:04:04 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] ecrit - Requested session has been scheduled for IETF 95 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:24 -0000 Dear Roger Marshall, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ecrit Session 1 (2:00:00) Wednesday, Morning Session I 1000-1230 Room Name: Quebracho A size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Emergency Context Resolution with Internet Technologies Area Name: Applications and Real-Time Area Session Requester: Roger Marshall Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 25 Conflicts to Avoid: First Priority: artarea Special Requests: No Friday meeting, please. --------------------------------------------------------- From nobody Tue Mar 15 12:33: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 8AC4312DD28 for ; Tue, 15 Mar 2016 12:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 AxarWYuBN29V for ; Tue, 15 Mar 2016 12:33:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D1012DD22 for ; Tue, 15 Mar 2016 12:33:18 -0700 (PDT) Received: from [192.168.10.140] ([129.192.176.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MTvUT-1aFgaI2DY1-00QnKy for ; Tue, 15 Mar 2016 20:33:16 +0100 References: To: "ecrit@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: Message-ID: <56E86378.7030107@gmx.net> Date: Tue, 15 Mar 2016 20:33:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PTCT1GnlPG8ede6AMUBXL7KASc8q8bNpf" X-Provags-ID: V03:K0:zRt6oJ6zIrqqwLP1tMhhNDnZKEh5OucIeTuAYIE6xTtKK2z9JQg PuGzdNPb29yQs0gxTmlV9+LdBxpj5waHiUssXpzsw+EnJ7qdH1nYfndn7gfmOCl8G5VA8EK MFEI5ItPbb0bs11c9os9IYNSOO/o91p9Y+hZPAMfy4DDSCaYvmJL4KCF/bTJGBafeSo5qD4 +o67gkv3rXkZJavJmzjzg== X-UI-Out-Filterresults: notjunk:1;V01:K0:LWMTya1Y1mw=:NwP8OU5DKtq+K15AgUukZB RbZuobijhoyVSMDI5wzloW+FRMtvXGgMecXG/cDnWizNLPW5oBBkupvrbdIF9QPBFo0GmUSsy IvFrX3JMFITIrZXaVNIoDpsWRQyZ/F/BS8vIJS3+RXBhJe1QC/bY3+Dne2QOVJTlLOWPGpl2i Auuh3AgIZAcwbhG8rXnzXIIE6vKpQdxCKK59CUitRthNNVQQ33JFE6y5nRc3VXsgm/TzehKwU LDkYFpvTrD8HQbHiFS48KMVlul2oOtGgfTeGFlUApUbUB5O2m/czywCs23UHkOErNcm3kQFtX m42RHC/gMVOFOS0tugg3QLPW6CnIFbkqFXlyl6xJHj9K2vlhLEtvXRWR97fD0DZOaHanm5ZuZ hdizoWpRy3+GSrqH5burlLfBogYw7z+xBOfPKzkDsy8BNEM5WAFkg71/5tnYclNpt6tVMcl9p Y7+D36Jxxakty1eDxEPEzlWKdX3webs0hgPDDgjeq5ay75jVynalt7xXKg06TMw8AjT9MrW6w EdnGgG9VZVUttnIOeuY82F2chzJuLWsjuU+XOXkmcBkQDVhPSZvpdyt0appTEmiGYXf9PnLuo ZV56EEByiklgzVjYUwuHBd20vysum6h705vvqzoIC1NyCZFZq3/7LSqssgG+7wjRgrzbX7LfA gS5wRute78Od0q0lOkfqswFTNPcehCwIw16ZLbxns+mZB9coe1J3lQb63lF3OX21dsv2lEvrK ssm2z3nApjGN78Dm+BCIeTVGyntvoplwfaC+HL0bMO6Bb6xAcNLaCsaVw7Y= Archived-At: Subject: [Ecrit] Fwd: Re: Additional Data Draft Bug X-BeenThere: ecrit@ietf.org 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, 15 Mar 2016 19:33:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PTCT1GnlPG8ede6AMUBXL7KASc8q8bNpf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI: I asked Philip, who discovered issues with the schema end of last year, for feedback on this topic. See below. -------- Forwarded Message -------- Subject: Re: Additional Data Draft Bug Date: Thu, 10 Mar 2016 12:37:13 -0800 From: Philip Reichl To: Hannes Tschofenig Hannes, Issue 1: It looks like: needs to be changed to: If I am interpreting the issue correctly then this is a simple editorial change that should be done. Issue 2: I think the simplest thing to do is to make the XSD schema in Appendix A normative and then add the "main-number" value to the enumeration. Regards, Philip H. Reichl Modular Communication Systems Inc. On Thu, Mar 10, 2016 at 12:27 AM, Hannes Tschofenig > wrote: Hi Philip, Could you take a brief look at this issue: http://www.ietf.org/mail-archive/web/ecrit/current/msg09380.html Your feedback would be appreciated. Ciao Hannes --=20 Philip H. Reichl Modular Communication Systems Tel: 818-764-1333 ext. 308 --PTCT1GnlPG8ede6AMUBXL7KASc8q8bNpf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW6GN5AAoJEGhJURNOOiAtYSEH/iIGCby0gM1yTNrhZ2l/GKI3 AG/JStANXA2olEwEn6VsdlsY8Cf9FeHNDf7pN/kZhHp7/jftnvwuIqBQXzXrOPXv fZIk2raxsiIXq0B7RWJKSxL820LWQvX9BauAbSQdV80IU65cPb1pBxvaCPR7Pkrk ew1RiQhSAGMHecNMub2rTBmGAgZ/C/1zA4QuYUneNvphhVI4ZzwPPHwx0ov0gU// jPyvvNm1mdphJr/RCyqpnlmhfRrgvIHFaBUyPJ2+vh2wLWJ2kaM0Eo1PN2RVOpTM f929OUCPIOTJva0b+lfun8ZrNFW3VRLY/faxrv2kxuHZhmLwNEM52Wl+05Bh//Q= =XYqf -----END PGP SIGNATURE----- --PTCT1GnlPG8ede6AMUBXL7KASc8q8bNpf-- From nobody Tue Mar 15 12:36: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 A956C12DA7F for ; Tue, 15 Mar 2016 12:36:11 -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, FREEMAIL_FROM=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=gmail.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 kOMRXYqa8CfE for ; Tue, 15 Mar 2016 12:36:09 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 7940C12D6EE for ; Tue, 15 Mar 2016 12:36:08 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 124so41335044pfg.0 for ; Tue, 15 Mar 2016 12:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YbtnjVQSI/14viml42m1/kVvwhDniSx/QAevAuHodTw=; b=lIkazbpuDXOZ00WXqdxvNmHJ1pXUlv0meyuOvP7Brd5A6ZJ6RWi/FjByQMPtsiOoy8 4Fc7yZ2wRt7TH0VU5/XThAicoAALpKlifZFYcNhTsH774UP2EmryISm/91pLtD6I4Qu7 ybmW5fFZmuoZdn752PnPO8EbyHrpSAieHOH73rR6cuqjkkpVkmUoz8ZQI1LaO3Zv/gfI JO448O9GTc4AXz41rTlMFGcPYtdAPBSaB4C21Oh2imty29/fWbMFxOoSnxyaHBix/f3Q X3d5VulCE59GygOFg3xYTDFxztkJmx4CQbxDIgO7MZgaEdXqBgV2JB+UUjzixAHxHslS c+UA== 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=YbtnjVQSI/14viml42m1/kVvwhDniSx/QAevAuHodTw=; b=eBnwUxpFkO/q17IQ/tgeDKBGWBr56nrQSiartEiXND93W6ZBlAuXhCbhzVs/axuUoB 4Ckp7IXsTkEddoqzzm3a2rzYXopQYwS7gPKyD1ZMo+i9T+TOvSh1OEg66SPZrduYQxTZ IQGAbno2FLOIq1BDrjn0zDvjPlR0LiXEw+cuCiKbwgm4yZaGERvgosLyzXtTYqUBsWKX lzMUuSeanVWHDj99u/eIUhp9HI46++Suwl3zWvWRkVrJKhGS0bc3RfreE4/D5fmRyFxz 8LvIMN1V2EZQK7LME2C7nVNRDVh0PjatLijNL3jX4yXdicYHxH3VSkCOPGLhfdYLYa3B KV0g== X-Gm-Message-State: AD7BkJJVIop0qeGvRTdHhUGTlOauRmfFI1PX+IBQ7Y7a/Tige2NJ4uCPK/KV/gstuq9kZQ== X-Received: by 10.98.73.142 with SMTP id r14mr41499938pfi.140.1458070568003; Tue, 15 Mar 2016 12:36:08 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id y68sm41526459pfi.6.2016.03.15.12.36.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 12:36:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: <56E86378.7030107@gmx.net> Date: Wed, 16 Mar 2016 06:36:01 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <916EA357-6A42-45DB-8E06-EFC024A0C391@gmail.com> References: <56E86378.7030107@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft Bug X-BeenThere: ecrit@ietf.org 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, 15 Mar 2016 19:36:11 -0000 We would still have to change the namespace. Cheers James > On 16 Mar 2016, at 6:33 am, Hannes Tschofenig = wrote: >=20 > FYI: I asked Philip, who discovered issues with the schema end of last > year, for feedback on this topic. See below. >=20 > -------- Forwarded Message -------- > Subject: Re: Additional Data Draft Bug > Date: Thu, 10 Mar 2016 12:37:13 -0800 > From: Philip Reichl > To: Hannes Tschofenig >=20 >=20 >=20 > Hannes, >=20 > Issue 1: > It looks like: >=20 > >=20 > needs to be changed to: >=20 > >=20 > If I am interpreting the issue correctly then this is a simple = editorial > change that should be done. >=20 > Issue 2: > I think the simplest thing to do is to make the XSD schema in Appendix = A > normative and then add the "main-number" value to the enumeration. >=20 > Regards, > Philip H. Reichl > Modular Communication Systems Inc. >=20 > On Thu, Mar 10, 2016 at 12:27 AM, Hannes Tschofenig > > wrote: >=20 > Hi Philip, >=20 > Could you take a brief look at this issue: > http://www.ietf.org/mail-archive/web/ecrit/current/msg09380.html >=20 > Your feedback would be appreciated. >=20 > Ciao > Hannes >=20 >=20 >=20 >=20 > --=20 > Philip H. Reichl > Modular Communication Systems > Tel: 818-764-1333 ext. 308 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Mar 15 12:56: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 096B612D76E for ; Tue, 15 Mar 2016 12:56: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=hxr-us.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 GVhzmcZi3Fnx for ; Tue, 15 Mar 2016 12:56:44 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c: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 A998D12D712 for ; Tue, 15 Mar 2016 12:56:43 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id l68so42465285wml.1 for ; Tue, 15 Mar 2016 12:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=PG9mcqWrW5XB+KIWF6pHWpw2FXzsdQhbIuvLMt5HXVc=; b=MEwDOxUJA1TQ3dk13rEIYC0lTVWoDFT0OXOy1WB9U5oLD2ArhwybjpIr6ANYceMO+v QIPWPeitzC+CXy5mVqSS07iG9EbFyn1FHbc8uriwogkncsBPpPQ9ulRu4TOW4FEABuJl wieD9wSsq1Z9dfdAQttsILjGN0KwqetNEq6LeVt0B+GIZtbSsj7KpHVcwsd8DIRDcEJK 9JMolmPFi6qwsrlrL1mvnpdrRanu46dUEWusz6Mc0b6UVcBrEIcpYiAXAtTa9BecVWM9 3ixqOS12dYCHVCJ5QpluAx7qxau1qqwTgNyzmf6dPHfDlom7DaqrjU+MT4ki7Vg99Da3 WKHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=PG9mcqWrW5XB+KIWF6pHWpw2FXzsdQhbIuvLMt5HXVc=; b=ebL+liAcXY5bjWEeyojdtoRLLgbHyq2TtBudeZAiKExVUsdSoLhJJtSTA3oBjwvqZc UaodiYzeoFOp3KpQx2lD76sv4n87x2PsPu+QCwwWAmeUyPzycO2qo75xn/O5rbQ9INVO sGUenezaidvIh+GylyK0hLkg5UJsE6zzZ6yeafcw38y2sCA8eRlNcpZNd7qyIa7hQY2g V638Tdw2cXfb+IpoqfPn0Dx6Eo7uBe+itTjE5uAQUiTMsEvdJg6ArnawJqYzsHGELLmk e2w2tFF4QmOLZ7PUK35KqNLZN9jAoWEk8nUnQgIY7xzoUgdnKzmPKD+Lih8eEA+MePgz yjTw== X-Gm-Message-State: AD7BkJLfdWr6JLiKh1Lsq2qJx/FG0ntPFvrUoEDtydZw/djEGJmM4ep5020/mPntC5XN2U48sIfq3vASy03WsA== MIME-Version: 1.0 X-Received: by 10.194.216.40 with SMTP id on8mr34956224wjc.40.1458071802180; Tue, 15 Mar 2016 12:56:42 -0700 (PDT) Received: by 10.194.41.131 with HTTP; Tue, 15 Mar 2016 12:56:42 -0700 (PDT) X-Originating-IP: [2001:500:4:15:a047:1d11:88bc:d5a1] In-Reply-To: <56E03BA4.5080104@gmx.net> References: <56E03BA4.5080104@gmx.net> Date: Tue, 15 Mar 2016 15:56:42 -0400 Message-ID: From: Andrew Newton To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 15 Mar 2016 19:56:46 -0000 On Wed, Mar 9, 2016 at 10:05 AM, Hannes Tschofenig wrote: > -- Issue #2: James noticed a problem with the value 'main-number' used > in the following example: > > > > > work > voice > *main-number* > > > sips:john.doe@example.com > > > main-number is not a valid type according the schema from Section 6.4.1 > of RFC 6351. RFC 6351 lists the valid types as: > > * =E2=80=9Cwork" > * =E2=80=9Chome" > * =E2=80=9Ctext" > * =E2=80=9Cvoice" > * =E2=80=9Cfax" > * =E2=80=9Ccell" > * =E2=80=9Cvideo" > * =E2=80=9Dpager" > * "textphone" Is there a reason why something new is being invented instead of using the parameter preference feature built into xCard/vCard/jCard ? Also, the URI element above is broken. The angle bracket(s) of the embedded URI need to be escaped. -andy From nobody Tue Mar 15 13:04: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 F1C8F12D62C for ; Tue, 15 Mar 2016 13:04:48 -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, FREEMAIL_FROM=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=gmail.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 w8Lpq6saI-rX for ; Tue, 15 Mar 2016 13:04:47 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 086ED12D567 for ; Tue, 15 Mar 2016 13:04:47 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 124so42215599pfg.0 for ; Tue, 15 Mar 2016 13:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l2DmdLMmZAgNIK8co/A/XC1Wv13RPGJDWnRUINRRrt0=; b=N3p4HMmiytW7ymvEI06QEoFMCW3jHRAzRh91Cv4xYOx1XkyTJ/9tHFiwCLTbpXf/9T r66d/J4SKo6UfsqfHAkoTS5w7BX51oNa7Yv4DvKQdHy7JtouWV/60y9D53PhQ5tTxTTu qALKeg8lDXYeIdNp+aUZVzm86uIfDo/xuNK7hjpPQNuuTSgtnBzRXDv+FbtO3z/biIsG TyNaV6Q+maLxQ6+v0nGMY7lS3I0qIyyjgfswdCar2TwPYJgbwxOREiskiPbqJzAI61U+ c7K5K3mfjmbSngryNA3QPqXZFJfKvI9aKHtyUhX+ZagMNaA7+lnvP4G3R2p7sWMOObQP UqSQ== 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=l2DmdLMmZAgNIK8co/A/XC1Wv13RPGJDWnRUINRRrt0=; b=QNKspXC+ugeBXA6UvtSL82JNME6w36/ukk9b2cA7z9DPW/qrIUTPG8/AGqUn/QEucR feujINi8vnBYWQjyr1ols5haj21c5N8ljQK8iEFFkiO+OExgzglIXb7vtcCG/ZGtu5Qb A9CKrPp8/KDaWdnOL840C52mQnbb0MM2tAtscUVGZbp5dM5aqtKfKSrUo0UVVJow8hHR 8SrvGIIyRGQKOdXcIgnTTBdQryYoyJftilRyO9R0lDDpJZRxAXrFf6baxpGOt/DjIzbk 7f+36QsGs/+e5M+3nKYLN8mjmfwXY8F++xcgOwv8Vy7MLFKJG1x6+0LOU4bNFBCB3NRr hqlA== X-Gm-Message-State: AD7BkJIGhnACX+BIjcrNhOIMFiOpRU/9vlu+DAsopl11g1U3xcKYzuRG4QGl3cy7UKxIZQ== X-Received: by 10.98.79.9 with SMTP id d9mr40866484pfb.46.1458072286592; Tue, 15 Mar 2016 13:04:46 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id h2sm41552092pfd.91.2016.03.15.13.04.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2016 13:04:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Wed, 16 Mar 2016 07:04:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> References: <56E03BA4.5080104@gmx.net> To: Andrew Newton X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 15 Mar 2016 20:04:49 -0000 Given that the it is inside the section, I am not convinced that = it makes sense to have the http URI in there anyway=E2=80=A6 *8) > On 16 Mar 2016, at 6:56 am, Andrew Newton wrote: >=20 > On Wed, Mar 9, 2016 at 10:05 AM, Hannes Tschofenig > wrote: >> -- Issue #2: James noticed a problem with the value 'main-number' = used >> in the following example: >>=20 >> >> >> >> work >> voice >> *main-number* >> >> >> sips:john.doe@example.com >> >>=20 >> main-number is not a valid type according the schema from Section = 6.4.1 >> of RFC 6351. RFC 6351 lists the valid types as: >>=20 >> * =E2=80=9Cwork" >> * =E2=80=9Chome" >> * =E2=80=9Ctext" >> * =E2=80=9Cvoice" >> * =E2=80=9Cfax" >> * =E2=80=9Ccell" >> * =E2=80=9Cvideo" >> * =E2=80=9Dpager" >> * "textphone" >=20 > Is there a reason why something new is being invented instead of using > the parameter preference feature built into xCard/vCard/jCard ? >=20 > Also, the URI element above is broken. The angle bracket(s) of the > embedded URI need to be escaped. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Mar 16 08:50: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 B02E012D969 for ; Wed, 16 Mar 2016 08:50:49 -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 2FhqvS1rZLKk for ; Wed, 16 Mar 2016 08:50:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0064.outbound.protection.outlook.com [65.55.169.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C22412D6C7 for ; Wed, 16 Mar 2016 08:50:45 -0700 (PDT) Received: from CY1PR17MB0362.namprd17.prod.outlook.com (10.163.253.148) by CY1PR17MB0363.namprd17.prod.outlook.com (10.163.253.149) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 15:50:41 +0000 Received: from CY1PR17MB0362.namprd17.prod.outlook.com ([10.163.253.148]) by CY1PR17MB0362.namprd17.prod.outlook.com ([10.163.253.148]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 15:50:41 +0000 From: Dan Banks To: James Winterbottom , Andrew Newton , Hannes Tschofenig Thread-Topic: [Ecrit] Additional Data Draft (again) Thread-Index: AQHRehc7GyoeNQdC4UWa5Np9Lwqyrp9a9WgAgAACOgCAAUJrwA== Date: Wed, 16 Mar 2016 15:50:40 +0000 Message-ID: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> In-Reply-To: <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: aa19becd-ec2c-423a-9896-08d34db2ba4b x-microsoft-exchange-diagnostics: 1; CY1PR17MB0363; 5:/QvegSPW8Kqt3NFxD8nMUxH2PDhKVgCoR2bR+mA4Pkt4uv+Y05bkakZnlr5owE15cUjyoq63MMtnG7c83RndNIVnG0cpq/Fee3Gc+8bEcHiKo/tgF1CAu/4ouQqxs/L/MFDeZKF19/3MrIAqmMb+hQ==; 24:BnmOerm65iTzMLaYFw8pcJAyYRM2r5Dty0YCdIlIPMyD79MhNxJGxq+9nOzT8h6p3W5snhNdXDLxyQpsbfTYBj9PL3Yh4y4AQqn1H275UPg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR17MB0363; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR17MB0363; BCL:0; PCL:0; RULEID:; SRVR:CY1PR17MB0363; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(24454002)(81166005)(3846002)(102836003)(6116002)(86362001)(1220700001)(1096002)(66066001)(99286002)(19580395003)(106116001)(122556002)(19580405001)(92566002)(586003)(54356999)(76176999)(50986999)(5003600100002)(10400500002)(74316001)(87936001)(3660700001)(3280700002)(5001770100001)(189998001)(2906002)(76576001)(4326007)(33656002)(2950100001)(2900100001)(5008740100001)(15975445007)(77096005)(80792005)(5002640100001)(5004730100002)(11100500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR17MB0363; H:CY1PR17MB0362.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 15:50:40.9718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR17MB0363 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 16 Mar 2016 15:50:49 -0000 V2hlbiBsb29raW5nIGF0IHRoaXMgaXNzdWUsIEkgZGlzY292ZXJlZCBhIGNvdXBsZSB0aGluZ3Mg dGhhdCBtYXkgYmUgaGVscGZ1bC4gIHhDYXJkIGlzIGludGVuZGVkIHRvIGFsbG93IGEgMToxIG1h cHBpbmcgdG8gdkNhcmQgKGFjY29yZGluZyB0byB0aGUgc3RhdGVtZW50IGluIHRoZSBSRkMgNjM1 MSBpbnRybykuICBTbyBJIHdlbnQgYmFjayB0byBSRkMgNjM1MCwgYW5kIGl0IHNlZW1zIHRoZSB0 eXBlIHBhcmFtZXRlciBpcyBpbnRlbmRlZCB0byBib3RoIGJlIGV4dGVuc2libGUgdmlhIHRoZSB1 c2Ugb2YgYSByZWdpc3RyeSwgYW5kIHdpdGggdW5yZWdpc3RlcmVkIHZhbHVlcyAodHlwaWNhbGx5 IGZvciBleHBlcmltZW50YXRpb24gb3IgcHJpdmF0ZSB1c2UpOg0KdHlwZS1wYXJhbS10ZWwgPSAi dGV4dCIgLyAidm9pY2UiIC8gImZheCIgLyAiY2VsbCIgLyAidmlkZW8iDQogICAgICAgICAgICAg ICAgICAgIC8gInBhZ2VyIiAvICJ0ZXh0cGhvbmUiIC8gaWFuYS10b2tlbiAvIHgtbmFtZQ0KDQpU aGUgcmVnaXN0cnkgaXMgYXQgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy92Y2FyZC1l bGVtZW50cy92Y2FyZC1lbGVtZW50cy54aHRtbCBhbmQgcGVyIHNlY3Rpb24gMTAuMi4xLCB1cGRh dGVzIHJlcXVpcmVzIGV4cGVydCByZXZpZXcgYW5kIGFuIFJGQy4NCg0KUkZDIDYzNTEgZG9lcyBu b3QgYXBwZWFyIHRvIGFjY29tbW9kYXRlIHRoaXMgaW4gdGhlIHNjaGVtYSBpdCBwcm92aWRlcywg YW5kIHRoYXQgc2VlbXMgdG8gYmUgY29udHJhcnkgdG8gdGhlIGludGVudCBvZiBhIDE6MSBtYXBw aW5nLiAgU3VyZSBlbm91Z2gsIHRoaXMgaGFzIGFscmVhZHkgYmVlbiBkaXNjb3ZlcmVkLCByZXBv cnRlZCwgYW5kIHZlcmlmaWVkIGFzIGVycmF0YSAzMDQ3Og0KDQotLS0tLS0tLS0tLS0tLS0tLQ0K U2VjdGlvbiBBcHBlbmRpeCBBLiBzYXlzOg0KDQojIDYuNC4xDQpwcm9wZXJ0eS10ZWwgPSBlbGVt ZW50IHRlbCB7DQogICAgZWxlbWVudCBwYXJhbWV0ZXJzIHsNCiAgICAgIHBhcmFtLWFsdGlkLA0K ICAgICAgcGFyYW0tcGlkLA0KICAgICAgcGFyYW0tcHJlZiwNCiAgICAgIGVsZW1lbnQgdHlwZSB7 DQogICAgICAgIGVsZW1lbnQgdGV4dCB7ICJ3b3JrIiB8ICJob21lIiB8ICJ0ZXh0IiB8ICJ2b2lj ZSINCiAgICAgICAgICAgICAgICAgICAgIHwgImZheCIgfCAiY2VsbCIgfCAidmlkZW8iIHwgInBh Z2VyIg0KICAgICAgICAgICAgICAgICAgICAgfCAidGV4dHBob25lIiB9Kw0KICAgICAgfT8sDQog ICAgICBwYXJhbS1tZWRpYXR5cGUNCiAgICB9PywNCiAgICAodmFsdWUtdGV4dCB8IHZhbHVlLXVy aSkNCiAgfQ0KDQpJdCBzaG91bGQgc2F5Og0KDQojIDYuNC4xDQpwcm9wZXJ0eS10ZWwgPSBlbGVt ZW50IHRlbCB7DQogICAgZWxlbWVudCBwYXJhbWV0ZXJzIHsNCiAgICAgIHBhcmFtLWFsdGlkLA0K ICAgICAgcGFyYW0tcGlkLA0KICAgICAgcGFyYW0tcHJlZiwNCiAgICAgIGVsZW1lbnQgdHlwZSB7 DQogICAgICAgIGVsZW1lbnQgdGV4dCB7ICJ3b3JrIiB8ICJob21lIiB8ICJ0ZXh0IiB8ICJ2b2lj ZSINCiAgICAgICAgICAgICAgICAgICAgIHwgImZheCIgfCAiY2VsbCIgfCAidmlkZW8iIHwgInBh Z2VyIg0KICAgICAgICAgICAgICAgICAgICAgfCAidGV4dHBob25lIiB8IHgtbmFtZSB8IGlhbmEt dG9rZW4gfSsNCiAgICAgIH0/LA0KICAgICAgcGFyYW0tbWVkaWF0eXBlDQogICAgfT8sDQogICAg KHZhbHVlLXRleHQgfCB2YWx1ZS11cmkpDQogIH0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K SSBhbSBub3QgdmVyeSBmYW1pbGlhciB3aXRoIHRoZSBwcm9jZXNzIGFyb3VuZCB1cGRhdGluZyBk b2N1bWVudHMsIGJ1dCB0byBtZSB0aGlzIHN1Z2dlc3RzOg0KCS0gd2Ugc2hvdWxkIG5vdCBuZWVk IHRvIGRvIGFuIHVwZGF0ZSB0byBSRkMgNjM1MSwNCgktIHdlIHNob3VsZCBmaXggdGhlIGluZm9y bWF0aXZlIHNjaGVtYSBpbiB0aGUgYWRkaXRpb25hbCBkYXRhIGRvY3VtZW50IHRvIHRha2UgaW50 byBhY2NvdW50IHRoZSB2ZXJpZmllZCBlcnJhdGEgKHRoZXJlIGFyZSBzZXZlcmFsKSwNCgktIHdl IHNob3VsZCBzZWVrIHJldmlldyBvZiAibWFpbi1udW1iZXIiIGFzIGFuIGFkZGl0aW9uIHRvIHRo ZSByZWdpc3RyeSwgYW5kIHVwZGF0ZSB0aGUgYWRkaXRpb25hbCBkYXRhIGRyYWZ0IHRvIGZvcm1h bGx5IG1ha2UgdGhhdCBhZGRpdGlvbi4NCg0KRGFuIEJhbmtzDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEphbWVzIFdpbnRlcmJvdHRvbQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTUs IDIwMTYgNDowNSBQTQ0KVG86IEFuZHJldyBOZXd0b24NCkNjOiBlY3JpdEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtFY3JpdF0gQWRkaXRpb25hbCBEYXRhIERyYWZ0IChhZ2FpbikNCg0KR2l2ZW4g dGhhdCB0aGUgaXQgaXMgaW5zaWRlIHRoZSA8dGVsPiBzZWN0aW9uLCBJIGFtIG5vdCBjb252aW5j ZWQgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byBoYXZlIHRoZSBodHRwIFVSSSBpbiB0aGVyZSBhbnl3 YXnigKYgKjgpDQoNCg0KPiBPbiAxNiBNYXIgMjAxNiwgYXQgNjo1NiBhbSwgQW5kcmV3IE5ld3Rv biA8YW5keUBoeHIudXM+IHdyb3RlOg0KPiANCj4gT24gV2VkLCBNYXIgOSwgMjAxNiBhdCAxMDow NSBBTSwgSGFubmVzIFRzY2hvZmVuaWcgDQo+IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3 cm90ZToNCj4+IC0tIElzc3VlICMyOiBKYW1lcyBub3RpY2VkIGEgcHJvYmxlbSB3aXRoIHRoZSB2 YWx1ZSAnbWFpbi1udW1iZXInIA0KPj4gdXNlZCBpbiB0aGUgZm9sbG93aW5nIGV4YW1wbGU6DQo+ PiANCj4+ICAgICAgPHRlbD4NCj4+ICAgICAgICAgICAgPHBhcmFtZXRlcnM+DQo+PiAgICAgICAg ICAgICAgIDx0eXBlPg0KPj4gICAgICAgICAgICAgICAgICA8dGV4dD53b3JrPC90ZXh0Pg0KPj4g ICAgICAgICAgICAgICAgICA8dGV4dD52b2ljZTwvdGV4dD4NCj4+ICAgICAgICAgICAgICAgICAg PHRleHQ+Km1haW4tbnVtYmVyKjwvdGV4dD4NCj4+ICAgICAgICAgICAgICAgPC90eXBlPg0KPj4g ICAgICAgICAgICA8L3BhcmFtZXRlcnM+DQo+PiAgICAgICAgICAgIDx1cmk+c2lwczpqb2huLmRv ZUBleGFtcGxlLmNvbSA8aHR0cDovL2V4YW1wbGUuY29tPjwvdXJpPg0KPj4gICAgICA8L3RlbD4N Cj4+IA0KPj4gbWFpbi1udW1iZXIgaXMgbm90IGEgdmFsaWQgdHlwZSBhY2NvcmRpbmcgdGhlIHNj aGVtYSBmcm9tIFNlY3Rpb24gDQo+PiA2LjQuMSBvZiBSRkMgNjM1MS4gUkZDIDYzNTEgbGlzdHMg dGhlIHZhbGlkIHR5cGVzIGFzOg0KPj4gDQo+PiAgKiDigJx3b3JrIg0KPj4gICog4oCcaG9tZSIN Cj4+ICAqIOKAnHRleHQiDQo+PiAgKiDigJx2b2ljZSINCj4+ICAqIOKAnGZheCINCj4+ICAqIOKA nGNlbGwiDQo+PiAgKiDigJx2aWRlbyINCj4+ICAqIOKAnXBhZ2VyIg0KPj4gICogInRleHRwaG9u ZSINCj4gDQo+IElzIHRoZXJlIGEgcmVhc29uIHdoeSBzb21ldGhpbmcgbmV3IGlzIGJlaW5nIGlu dmVudGVkIGluc3RlYWQgb2YgdXNpbmcgDQo+IHRoZSBwYXJhbWV0ZXIgcHJlZmVyZW5jZSBmZWF0 dXJlIGJ1aWx0IGludG8geENhcmQvdkNhcmQvakNhcmQgPw0KPiANCj4gQWxzbywgdGhlIFVSSSBl bGVtZW50IGFib3ZlIGlzIGJyb2tlbi4gVGhlIGFuZ2xlIGJyYWNrZXQocykgb2YgdGhlIA0KPiBl bWJlZGRlZCBVUkkgbmVlZCB0byBiZSBlc2NhcGVkLg0KPiANCj4gLWFuZHkNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxp bmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo= From nobody Wed Mar 16 11:54: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 774AC12D6D9 for ; Wed, 16 Mar 2016 11:54:22 -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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 NPSD_FBnw6tz for ; Wed, 16 Mar 2016 11:54:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3029012D68F for ; Wed, 16 Mar 2016 11:54:09 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 16 Mar 2016 11:54:07 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Mar 2016 11:54:06 -0700 To: Dan Banks , James Winterbottom , Andrew Newton , Hannes Tschofenig 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] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 16 Mar 2016 18:54:22 -0000 At 3:50 PM +0000 3/16/16, Dan Banks wrote: > I am not very familiar with the process around updating documents, > but to me this suggests: > - we should not need to do an update to RFC 6351, > - we should fix the informative schema in the additional data > document to take into account the verified errata (there are > several), > - we should seek review of "main-number" as an addition to the > registry, and update the additional data draft to formally make > that addition. This sounds reasonable to me. We also won't need to change the namespace. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A list is only as strong as its weakest link. --Donald Knuth From nobody Thu Mar 17 04:00: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 E71E312D8C2 for ; Thu, 17 Mar 2016 04:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z_a556q1Mp_H for ; Thu, 17 Mar 2016 04:00:30 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 1DDF312D510 for ; Thu, 17 Mar 2016 04:00:30 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id q129so10781553pfb.3 for ; Thu, 17 Mar 2016 04:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X31v0fQ55/iSctp/rU2Z1Zfez5Oh4wED0QXVarsKdO4=; b=WWLLaZkgKq4Tpy1CFuRF+7CDLA0yfGDETXvoKNtXvgIBuaa3KICSFb+geoExHhnKf+ YT0db6L4Ayv5B10d0QUmXDdyiKjsgLxJY0L81Fo0KT4HVbpNpg2W9S+BLy6RWAcXB7eS bq8MM9GQDGJaBgMBo53Hkv1VkfejZPVA3wjYw3EmytSZPx402nJoyES/OMTriZrnxbHj CUgXl1duZxyS7Zuals2S6QIWUP78qLWIBHNDvBN32d3wMIxANW+WMSrd1tlnEd4dUr5e jAkOBf0kPyyQ5xw6FkPKg/4l7Mg09BBGGZ3LU+QBlqWxse5fbir0QQYs3HDkJXGiF/Ob uzTA== 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=X31v0fQ55/iSctp/rU2Z1Zfez5Oh4wED0QXVarsKdO4=; b=MhtcuE/jI73SGDBwDkZfxWCJhYsXcRXY9rhuMQkA3kMRkjJaO1LGMOLf/iPe7t0bPy woAa1sffqnVkFGy/e5rwlriFTjDgXLkdpscS/BMb8Q9y/3Tcyk/zJIVV3Ud7qV5nWHfE OOYodPwuLbN9mBfK7p6q3To0dczJAK1OyUSJPJcppsOvqiGOKaYgx8c/D48m8R9cRCUj dtpKbL9W+onOJDv3LYPqDqYqiqxgc3FRVBJ/HUyEhSszbcJIDtdajszSw732gwDLXve0 Kr0qRPBPuY2gup201PZaeiKf4Mly3GKQOZ0F1YN20ck1s3myDFK7b6YZAxsjbG5BxQzD lINQ== X-Gm-Message-State: AD7BkJLQ+rVwvptYgzt3rWFPI2dhBoUCWjfyaVGq23AUW0aq/FCjkTW+qA4zph6rqTvaGw== X-Received: by 10.98.13.130 with SMTP id 2mr13879928pfn.97.1458212429150; Thu, 17 Mar 2016 04:00:29 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id 62sm12449141pfk.83.2016.03.17.04.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 04:00:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Thu, 17 Mar 2016 18:51:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 17 Mar 2016 11:00:34 -0000 I think that the general approach is okay, I remain unconvinced that we = don=E2=80=99t need a new namespace however, because the schema in RFC = 6351 is normative and it has an error and our solution requires the = error be corrected. Cheers James > On 17 Mar 2016, at 5:54 am, Randall Gellens = wrote: >=20 > At 3:50 PM +0000 3/16/16, Dan Banks wrote: >=20 >> I am not very familiar with the process around updating documents,=20 >> but to me this suggests: >> - we should not need to do an update to RFC 6351, >> - we should fix the informative schema in the additional data=20 >> document to take into account the verified errata (there are=20 >> several), >> - we should seek review of "main-number" as an addition to the=20= >> registry, and update the additional data draft to formally make=20 >> that addition. >=20 > This sounds reasonable to me. We also won't need to change the = namespace. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > A list is only as strong as its weakest link. --Donald Knuth From nobody Fri Mar 18 14:51: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 84D2C12D531 for ; Fri, 18 Mar 2016 14:51:37 -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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 OX1XOy-yiXGk for ; Fri, 18 Mar 2016 14:51:36 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF312D522 for ; Fri, 18 Mar 2016 14:51:34 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 18 Mar 2016 14:51:27 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> X-Mailer: Eudora for Mac OS X Date: Fri, 18 Mar 2016 14:51:25 -0700 To: James Winterbottom 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] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 18 Mar 2016 21:51:37 -0000 I'm OK with changing the namespace if we need to. At 6:51 PM +1100 3/17/16, James Winterbottom wrote: > I think that the general approach is okay, I remain unconvinced > that we don't need a new namespace however, because the schema in > RFC 6351 is normative and it has an error and our solution requires > the error be corrected. > > Cheers > James > > > >> On 17 Mar 2016, at 5:54 am, Randall Gellens >> wrote: >> >> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >> >>> I am not very familiar with the process around updating documents, >>> but to me this suggests: >>> - we should not need to do an update to RFC 6351, >>> - we should fix the informative schema in the additional data >>> document to take into account the verified errata (there are >>> several), >>> - we should seek review of "main-number" as an addition to the >>> registry, and update the additional data draft to formally make >>> that addition. >> >> This sounds reasonable to me. We also won't need to change the namespace. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> A list is only as strong as its weakest link. --Donald Knuth -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- 640K ought to be enough for anybody. --Bill Gates, 1981 From nobody Fri Mar 18 15:05: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 984D812D6F0 for ; Fri, 18 Mar 2016 15:05:40 -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, FREEMAIL_FROM=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=gmail.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 Ze-KeztlAJeQ for ; Fri, 18 Mar 2016 15:05:39 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 2452512D6DA for ; Fri, 18 Mar 2016 15:05:39 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id n5so184122125pfn.2 for ; Fri, 18 Mar 2016 15:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k2frgqpnfz1k8/w2yXF4Ji1nkbv36OI865x3hknjZHI=; b=0vbiP1aNzB7SiyisNrN6vGOYdea4346Dob+gmyBewr+sECdIbXgN0Y4QFdx63lJmWk pK+ilvwwkSJYR8Bd51E7LNguMxh3c9e/mqeRbCSSfn+fWa7i5UhdkNSqh4thclA4F1LR EST7+7H+K2k44Gse3ZFTVv6YPaN2DBv5jetnwm9UoP321hFBC1NkF6qN6jT/kp2K8Arp doHTRFNrubq889njCg25Ass2fpCT7a6xTR8L7cRVSp6tZzhGZTRgMZ/YkBzRJxBgg90Q 7+KImla1Hk108DtCZQ+fyoHZ1OUboJ8UoilTsWxSymsX1ZTJeWEFWV6KzQ3rjMt3+znc yLzA== 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=k2frgqpnfz1k8/w2yXF4Ji1nkbv36OI865x3hknjZHI=; b=cBK0FBZQIzX8xPpwSpRfX+qDI0P382FRKO9qMemyNefBx0BO1dBvzbzlE3ZynkOAUZ efiWy2wYGDT9VvJuKtV575FlHb5ppx/eCEI6UvkRBJNRvZPiiqvGDlCB0j2EtENt5oTK c8y7y06noKka1MsY/KInPgo3DkyarqJldq9+oU4ri5CIdns9+LUnh4k0l58eea3KPLOU smiqQw2CBQGfVsrSQFmfD/WAFmi5MW6bN4BzFdF6xU7xrIt8XwW4DCxM/ObS8w3gNXZC 00I7vgHxNZeWVL3aQF4rFCHSDvr+CCgKsbvKepKmPgv6FDWB6LBhZBWqOi+R5B/wTTx9 Y15g== X-Gm-Message-State: AD7BkJLRVWstwMs0AQtsdlN6pzeTFGvi6pt3zfG+UqRhtGBGPtkjZkyTNSCiPtXWFsRUTQ== X-Received: by 10.66.192.195 with SMTP id hi3mr26949682pac.149.1458338738769; Fri, 18 Mar 2016 15:05:38 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id 9sm23250165pfm.10.2016.03.18.15.05.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2016 15:05:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Sat, 19 Mar 2016 09:05:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 18 Mar 2016 22:05:40 -0000 So, just make sure I am clear on what the plan is: 1) Remove the enumeration for the schema so all values now come from the = registry only 2) Add main number to the registry 3) Change the namespace 4) Update all examples to use the new namespace 5) register the namespace and schema with IANA Cheers James > On 19 Mar 2016, at 8:51 am, Randall Gellens = wrote: >=20 > I'm OK with changing the namespace if we need to. >=20 > At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >=20 >> I think that the general approach is okay, I remain unconvinced=20 >> that we don't need a new namespace however, because the schema in=20 >> RFC 6351 is normative and it has an error and our solution requires=20= >> the error be corrected. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >>> On 17 Mar 2016, at 5:54 am, Randall Gellens=20 >>> wrote: >>>=20 >>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>=20 >>>> I am not very familiar with the process around updating documents, >>>> but to me this suggests: >>>> - we should not need to do an update to RFC 6351, >>>> - we should fix the informative schema in the additional data >>>> document to take into account the verified errata (there are >>>> several), >>>> - we should seek review of "main-number" as an addition to the >>>> registry, and update the additional data draft to formally make >>>> that addition. >>>=20 >>> This sounds reasonable to me. We also won't need to change the = namespace. >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> A list is only as strong as its weakest link. --Donald Knuth >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > 640K ought to be enough for anybody. --Bill Gates, 1981 From nobody Fri Mar 18 16:20: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 C1BA012D64F for ; Fri, 18 Mar 2016 16:20:42 -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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 s1dn7_DBMgaq for ; Fri, 18 Mar 2016 16:20:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 48D3112D55D for ; Fri, 18 Mar 2016 16:20:41 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 18 Mar 2016 16:20:41 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> X-Mailer: Eudora for Mac OS X Date: Fri, 18 Mar 2016 16:20:36 -0700 To: James Winterbottom 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] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 18 Mar 2016 23:20:43 -0000 Thanks for listing the steps, James. Hannes, does this sound like the plan to you? Brian, do you concur? Thanks everyone. At 9:05 AM +1100 3/19/16, James Winterbottom wrote: > So, just make sure I am clear on what the plan is: > 1) Remove the enumeration for the schema so all values now come > from the registry only > 2) Add main number to the registry > 3) Change the namespace > 4) Update all examples to use the new namespace > 5) register the namespace and schema with IANA > > Cheers > James > > > >> On 19 Mar 2016, at 8:51 am, Randall Gellens >> wrote: >> >> I'm OK with changing the namespace if we need to. >> >> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >> >>> I think that the general approach is okay, I remain unconvinced >>> that we don't need a new namespace however, because the schema in >>> RFC 6351 is normative and it has an error and our solution requires >>> the error be corrected. >>> >>> Cheers >>> James >>> >>> >>> >>>> On 17 Mar 2016, at 5:54 am, Randall Gellens >>>> wrote: >>>> >>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>> >>>>> I am not very familiar with the process around updating documents, >>>>> but to me this suggests: >>>>> - we should not need to do an update to RFC 6351, >>>>> - we should fix the informative schema in the additional data >>>>> document to take into account the verified errata (there are >>>>> several), >>>>> - we should seek review of "main-number" as an addition to the >>>>> registry, and update the additional data draft to formally make >>>>> that addition. >>>> >>>> This sounds reasonable to me. We also won't need to change the namespace. >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- >>>> A list is only as strong as its weakest link. --Donald Knuth >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> 640K ought to be enough for anybody. --Bill Gates, 1981 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Conscience is the inner voice that warns us somebody is looking --H. L. Mencken From nobody Sun Mar 20 05:26: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 ACC2312D725 for ; Sun, 20 Mar 2016 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 E-s5CKbcMUjn for ; Sun, 20 Mar 2016 05:26:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C72D12D6F0 for ; Sun, 20 Mar 2016 05:26:30 -0700 (PDT) Received: from [192.168.10.140] ([88.128.80.42]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lqm3a-1aC76i3gCQ-00eI6q; Sun, 20 Mar 2016 13:26:22 +0100 To: Dan Banks , James Winterbottom , Andrew Newton References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56EE96EF.9030505@gmx.net> Date: Sun, 20 Mar 2016 13:26:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tlWMGWSeF2O2XhBhLAbPLk3gGC5MvmOqN" X-Provags-ID: V03:K0:OjR69LdXegQLgxBMQUnML7RE/rIeb+GS7BFZaxMmfhVMoqCzmVo ArEv8kYb030Y3DCz/Ci4gvnujTJJ6IcVsDYekhPH3QCV+t7/+z0zMvZQKhURFPjCI4mRX93 IG9EIs7PXSV03D3UBxHRpTuoxnV4RgOyBfTKpWeGNWi1c6Jt/AOOmEJnp0/unMX+6tzwVO3 PRIyu25XAOUex4Hx+r3LQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GdgseNNGqS8=:kJuyPW2rnA5+/78g6ToLmq g0F+rkocoGdmM4Rss5qOBP8zUyXGeaTGZA4rONAc36W6PIkssEk1w5DHXQXJlHI6z0HMGYX0h FPYb5dM6RE9PLYOzjF44MubohHa8cDe6tACpzQjA6SWJbGGuqn7A4EzD/cDu4NNdyo3y+6F/W w5KcIHpUaRlpKyH0HAqLeCTPZEo8qMpiFDF7ZjYd2MFSYhc0EJJabtGstDEXJiLPAnEG47HOJ ST/eowPxL+GQ+MQtKlPMKVfJJ9NX+gzNfzg/yQ5F2hevHWTC+qutzpvCrXnzVLuu2GzItka0D EF0pZolcnolLu0tM1D/zz9EBtnEYFyO4oemTZ3V9CLsY2wqzgphH5eCoHNdSkShdahzGL3nb0 1TY/D6qpErJTUUh4PUcnZIk99yNs3h4N9weUgewsaRy0OXZBaFxXu72Jp/MZwM+c4U/ChdA5W V5kr9v2+6JMMIfvKQOqZmewS+Uinf/YBpjcijWfqHlYwAIXM8HpquhHuZZFHhZ84eEjHV4iYy A0fSm956jdzJDXYDSKykgXDfOUBFMLWFzuwwq8XNHvXhFm2MVmwna/Pt/wW1/IkoTcwh+dUhr ir4cV+90cU4t7ABNejsxeTs3vVXo3oIgIJ/FRF4l8nEkaUTgDKCucJAFpG2gNfiIV4pmBDSTV dAjXk2X5hhY2INAtRgK0pO4QQjrc4pPXXakS+QNZ43m9u3o6TCuy0e+IHOu1+0nYnlNvWS1MH 4hdDl9pGt9HA8gDagR+zGx29Z/hNnlVgrRzVfcrYClmQObDVxNlgNF1twRM= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 20 Mar 2016 12:26:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tlWMGWSeF2O2XhBhLAbPLk3gGC5MvmOqN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dan, thanks a lot for your feedback. I did not check the errata and therefore failed to notice that this issue already surfaced earlier. Ciao Hannes On 03/16/2016 04:50 PM, Dan Banks wrote: > When looking at this issue, I discovered a couple things that may be he= lpful. xCard is intended to allow a 1:1 mapping to vCard (according to t= he statement in the RFC 6351 intro). So I went back to RFC 6350, and it = seems the type parameter is intended to both be extensible via the use of= a registry, and with unregistered values (typically for experimentation = or private use): > type-param-tel =3D "text" / "voice" / "fax" / "cell" / "video" > / "pager" / "textphone" / iana-token / x-name >=20 > The registry is at http://www.iana.org/assignments/vcard-elements/vcard= -elements.xhtml and per section 10.2.1, updates requires expert review an= d an RFC. >=20 > RFC 6351 does not appear to accommodate this in the schema it provides,= and that seems to be contrary to the intent of a 1:1 mapping. Sure enou= gh, this has already been discovered, reported, and verified as errata 30= 47: >=20 > ----------------- > Section Appendix A. says: >=20 > # 6.4.1 > property-tel =3D element tel { > element parameters { > param-altid, > param-pid, > param-pref, > element type { > element text { "work" | "home" | "text" | "voice" > | "fax" | "cell" | "video" | "pager" > | "textphone" }+ > }?, > param-mediatype > }?, > (value-text | value-uri) > } >=20 > It should say: >=20 > # 6.4.1 > property-tel =3D element tel { > element parameters { > param-altid, > param-pid, > param-pref, > element type { > element text { "work" | "home" | "text" | "voice" > | "fax" | "cell" | "video" | "pager" > | "textphone" | x-name | iana-token }+ > }?, > param-mediatype > }?, > (value-text | value-uri) > } > -------------------- >=20 >=20 > I am not very familiar with the process around updating documents, but = to me this suggests: > - we should not need to do an update to RFC 6351, > - we should fix the informative schema in the additional data document= to take into account the verified errata (there are several), > - we should seek review of "main-number" as an addition to the registr= y, and update the additional data draft to formally make that addition. >=20 > Dan Banks >=20 >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James Winterbo= ttom > Sent: Tuesday, March 15, 2016 4:05 PM > To: Andrew Newton > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data Draft (again) >=20 > Given that the it is inside the section, I am not convinced that = it makes sense to have the http URI in there anyway=E2=80=A6 *8) >=20 >=20 >> On 16 Mar 2016, at 6:56 am, Andrew Newton wrote: >> >> On Wed, Mar 9, 2016 at 10:05 AM, Hannes Tschofenig=20 >> wrote: >>> -- Issue #2: James noticed a problem with the value 'main-number'=20 >>> used in the following example: >>> >>> >>> >>> >>> work >>> voice >>> *main-number* >>> >>> >>> sips:john.doe@example.com >>> >>> >>> main-number is not a valid type according the schema from Section=20 >>> 6.4.1 of RFC 6351. RFC 6351 lists the valid types as: >>> >>> * =E2=80=9Cwork" >>> * =E2=80=9Chome" >>> * =E2=80=9Ctext" >>> * =E2=80=9Cvoice" >>> * =E2=80=9Cfax" >>> * =E2=80=9Ccell" >>> * =E2=80=9Cvideo" >>> * =E2=80=9Dpager" >>> * "textphone" >> >> Is there a reason why something new is being invented instead of using= =20 >> the parameter preference feature built into xCard/vCard/jCard ? >> >> Also, the URI element above is broken. The angle bracket(s) of the=20 >> embedded URI need to be escaped. >> >> -andy >> >> _______________________________________________ >> 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 --tlWMGWSeF2O2XhBhLAbPLk3gGC5MvmOqN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW7pbvAAoJEGhJURNOOiAtsDsH/35oRg3pVWZ2AxcOmO0RkXVv pE4N3XUYtQ0U9E5Z9c3TyhQTBRI75yqn3Z7weHc01d1ANitRAbJFGYwGFGT+RqUS DNJ0G5q81lS1yCj3gZcrxS13MqcIQzl2ugnd/jCDaQV0z/K+PiKU2eZcO+V3q7gR LlnTdKcGllLJkVWmJ/1ukUNwj7A7PyFcXN9ltd8zevXbZG4FT4v/6oz55mHTOj2N mkx6tSpIMdCkz2wv+TIIooDMZmrQ7F6En+kQLCiHOdZuS1bptwRNHxLWJgeeTr+D GZq7q770hbvy6KH9oQoEHvk5K8TjqmgGmkp6uHL5IV1imPvNkpRhnmZ4fZWvz1Y= =rYor -----END PGP SIGNATURE----- --tlWMGWSeF2O2XhBhLAbPLk3gGC5MvmOqN-- From nobody Sun Mar 20 06:09: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 1FFB012D551 for ; Sun, 20 Mar 2016 06:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 keUIbxk-T35E for ; Sun, 20 Mar 2016 06:09:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC64412D5D8 for ; Sun, 20 Mar 2016 06:09:26 -0700 (PDT) Received: from [192.168.10.140] ([88.128.80.42]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MgXCF-1aT9Hk3u6R-00O0Zc; Sun, 20 Mar 2016 14:09:20 +0100 To: Randall Gellens , James Winterbottom References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56EEA101.6010409@gmx.net> Date: Sun, 20 Mar 2016 14:09:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CWMXbtA7KdVHLmMstQfDvQXgXnDrWWpVq" X-Provags-ID: V03:K0:h6SJrG6uqTJTzW+/+9IbGJdxmxOS2jXPczZolbso8e2mCID0Rf8 mgl9Ng6Cr8c7fSux3buITm5AislLzlyBoxevc2toXspevcsO/LWpTFakTnq8pJe7m4GwrPe ogXVqhQ0rCfHIf+1FlkhRp1ytVWHZBmNFXX/KQzM1G8KP2AaX6QRddvnrCCjVk+6BnK1lol J1PErISU7xwRgcx9/62Qw== X-UI-Out-Filterresults: notjunk:1;V01:K0:CYtTesY9FPs=:XBQWu4UaMkyiAhXP2dcQpX jzDjWZYUGFyVQtsaMCKuy46LTe80ek3kH1Y2S7q2zloJFcPCo2EFlhilTSJANBfGbcHR38JPn 3yhmH29U1AtWDI3pYeUy5dL8Xpb9AbFI7vfLn5x11azeZ9tagjjootdaIBbBw6jZv9H7VLRH4 qIwyeieajMyFik2kgsskiDVj8TnJi1PF347XZyav7n9vHqkFDhvkqmus3GheVCuj7qYw81T2R BX68g8S2O++oxwiz5MbJPRqvBS+25pwKZpnOYKvgLT5+TivHh2gAa1uXg0uV498aHNs43J2+n hM5N7NyG3qRYcJqh7LOWlNadcr9dGQLBjx3VhTo9Yir25RuxR4DaMQ47RawJOYWHZFb7j0on0 k3mkXSfL6sogB5oidQDOTKI02Bqk3i86TRi0zVcYY9utXFYI+PUQYChgqUsZGwYx/nXwmC/G0 BazUWyC6OUh4VJvYKg8QRC8XGc3hzfGT7g/ObYY07W2TkWvKGYiAP9bz+ogX3XGUpsdczpMNi 62xUYYHAMWKew+fE/nozqzCOkGxekRhukiUwmUdiwAF+mA1uy3GnrLWwT3RwrAJyac3dkcUdx LbK7gczqxUOMQQVolwkK39mpUssP67oqV/TLHZawEPBCLOUUb7F7vTvH0hrb+pVVrvDwWISBn J1poDzfQtgANEgGianl3lVB1UFV9Luuq2BGLA9V2Vv2JSf/OT0j7TUWYYf5WmdCouXDFWZe/9 OEumvQXsF3aWyF6VFL191xFCz6cQnIuClK73LPSjkFkpcEiCGzmT9l9bzFk= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 20 Mar 2016 13:09:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CWMXbtA7KdVHLmMstQfDvQXgXnDrWWpVq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Randy, Hi James, the proposal makes sense to me an I have been working on an update to reflect these changes. Here is the link to the work in progress document: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional= -data/draft-ietf-ecrit-additional-data-38.txt Ciao Hannes On 03/19/2016 12:20 AM, Randall Gellens wrote: > Thanks for listing the steps, James. >=20 > Hannes, does this sound like the plan to you? >=20 > Brian, do you concur? >=20 > Thanks everyone. >=20 > At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >=20 >> So, just make sure I am clear on what the plan is: >> 1) Remove the enumeration for the schema so all values now come from >> the registry only >> 2) Add main number to the registry >> 3) Change the namespace >> 4) Update all examples to use the new namespace >> 5) register the namespace and schema with IANA >> >> Cheers >> James >> >> >> >>> On 19 Mar 2016, at 8:51 am, Randall Gellens >>> wrote: >>> >>> I'm OK with changing the namespace if we need to. >>> >>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>> >>>> I think that the general approach is okay, I remain unconvinced >>>> that we don't need a new namespace however, because the schema in >>>> RFC 6351 is normative and it has an error and our solution requires= >>>> the error be corrected. >>>> >>>> Cheers >>>> James >>>> >>>> >>>> >>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens >>>>> wrote: >>>>> >>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>> >>>>>> I am not very familiar with the process around updating documents= , >>>>>> but to me this suggests: >>>>>> - we should not need to do an update to RFC 6351, >>>>>> - we should fix the informative schema in the additional data >>>>>> document to take into account the verified errata (there are >>>>>> several), >>>>>> - we should seek review of "main-number" as an addition to the= >>>>>> registry, and update the additional data draft to formally make >>>>>> that addition. >>>>> >>>>> This sounds reasonable to me. We also won't need to change the >>>>> namespace. >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself= >>>>> only >>>>> -------------- Randomly selected tag: --------------- >>>>> A list is only as strong as its weakest link. --Donald Knuth >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself o= nly >>> -------------- Randomly selected tag: --------------- >>> 640K ought to be enough for anybody. --Bill Gates, 1981 >=20 >=20 --CWMXbtA7KdVHLmMstQfDvQXgXnDrWWpVq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW7qEBAAoJEGhJURNOOiAtAu4H+gP6mXgAi3E6KAeSSyPqw4VU /+ZZSfDHuknZnxvlYxBlOLNkGZT+DXaV5WrYv921AaXcHQ5Wo5JYPWj5DGw/+wa9 d94XpSPQbOGMCBMkrxxn4dX5ucLmqYc0uM9uyvEU/eRqKWvlveMLmxLDBB980/GG I5ty2vgTvBTIgWJQtIqX0VajCKGd8ufYMJoH20nbjq1388xmMsyDHaEvMpG/mQAB LsGze8BmkVsZ4RcQ62cPy151bokYq75IvxgPghsuGVvniJNhcu6AFkdZZ0+IVtMU +0lhxtkr4HrIxwE3Am6Se7mwADlFTv1+OAbKBDqAsEqbU4J9QpdhX6+kFEtWDhQ= =DWm+ -----END PGP SIGNATURE----- --CWMXbtA7KdVHLmMstQfDvQXgXnDrWWpVq-- From nobody Mon Mar 21 09:20: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 D2DEF12D7BF for ; Mon, 21 Mar 2016 09:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApfbnhqBLAdo for ; Mon, 21 Mar 2016 09:20:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0636.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8D412D89C for ; Mon, 21 Mar 2016 09:20:39 -0700 (PDT) Received: from SN1PR17MB0366.namprd17.prod.outlook.com (10.163.223.143) by SN1PR17MB0368.namprd17.prod.outlook.com (10.163.223.145) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 21 Mar 2016 16:20:22 +0000 Received: from SN1PR17MB0366.namprd17.prod.outlook.com ([10.163.223.143]) by SN1PR17MB0366.namprd17.prod.outlook.com ([10.163.223.143]) with mapi id 15.01.0434.021; Mon, 21 Mar 2016 16:20:23 +0000 From: Dan Banks To: Hannes Tschofenig , Randall Gellens , James Winterbottom Thread-Topic: [Ecrit] Additional Data Draft (again) Thread-Index: AQHRehc7GyoeNQdC4UWa5Np9Lwqyrp9a9WgAgAACOgCAAX6lhoAA2UIAgAJ86oCAAAPwAIAAFPsAgAJ54oCAAZ9/MA== Date: Mon, 21 Mar 2016 16:20:22 +0000 Message-ID: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> In-Reply-To: <56EEA101.6010409@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: b7cb0773-029b-433c-936b-08d351a4b445 x-microsoft-exchange-diagnostics: 1; SN1PR17MB0368; 5:QytOkxZGV4E0i1tMNUDCxHJ9n4YBtW765cItHvDNprJQ7F8+yjVUkj7ozergN16tfK7XtakU/Slqw+LDiMYdCdEkRSv29Mg0DIzKkMZxA1I6lPnOCyp64qnlaqU2S9wqOAzds5x+2TSx87bsJBQdbA==; 24:Zdf4KEnqIOnN5Bd2osxrq4takd34tG7dUjb0PCbnkNK/+ZpeuxbqgMJxvx77sVDdgVDOWC4y1z0T4AJi2MdYkyFT4bIhUw0mkju1gX6NAy8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR17MB0368; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR17MB0368; BCL:0; PCL:0; RULEID:; SRVR:SN1PR17MB0368; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51444003)(52604005)(24454002)(377454003)(13464003)(586003)(5003600100002)(66066001)(19580395003)(19580405001)(5002640100001)(1096002)(102836003)(1220700001)(99286002)(561944003)(106116001)(4326007)(3846002)(2900100001)(2950100001)(15975445007)(3660700001)(93886004)(6116002)(33656002)(2906002)(122556002)(5001770100001)(50986999)(77096005)(189998001)(3280700002)(10400500002)(5004730100002)(86362001)(76176999)(74316001)(5008740100001)(54356999)(76576001)(87936001)(81166005)(80792005)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR17MB0368; H:SN1PR17MB0366.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 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: 21 Mar 2016 16:20:22.7035 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR17MB0368 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 16:20:43 -0000 I'm not entirely sure this is the right way to go. First, if the values can only come from the registry, that still excludes t= he x-name values (which seems to me to be nearly as big of an omission as l= eaving out the iana-token values). Second, is changing the namespace really necessary? Perhaps I don't unders= tand the errata process correctly, but James' argument that the RFC 6351 sc= hema error requires it does not seem persuasive to me in light of the exist= ing errata already being verified status (as opposed to held for update). = That suggests to me that any RFC 6351 implementation should take this errat= a into account. Changing the namespace also brings new complications: the xCards will not b= e interoperable with an RFC 6351 implementation (even one that considers th= e errata), and the Appendix A schema would have to be normative. This esse= ntially redefines the entire xCard schema with an XML schema when the previ= ous version was a Relax NG schema. This doesn't seem like a good idea to m= e. Dan Banks =20 -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Sunday, March 20, 2016 9:09 AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew Newton; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data Draft (again) Hi Randy, Hi James, the proposal makes sense to me an I have been working on an update to refle= ct these changes. Here is the link to the work in progress document: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-d= ata/draft-ietf-ecrit-additional-data-38.txt Ciao Hannes On 03/19/2016 12:20 AM, Randall Gellens wrote: > Thanks for listing the steps, James. >=20 > Hannes, does this sound like the plan to you? >=20 > Brian, do you concur? >=20 > Thanks everyone. >=20 > At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >=20 >> So, just make sure I am clear on what the plan is: >> 1) Remove the enumeration for the schema so all values now come from=20 >> the registry only >> 2) Add main number to the registry >> 3) Change the namespace >> 4) Update all examples to use the new namespace >> 5) register the namespace and schema with IANA >> >> Cheers >> James >> >> >> >>> On 19 Mar 2016, at 8:51 am, Randall Gellens=20 >>> wrote: >>> >>> I'm OK with changing the namespace if we need to. >>> >>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>> >>>> I think that the general approach is okay, I remain unconvinced =20 >>>> that we don't need a new namespace however, because the schema in =20 >>>> RFC 6351 is normative and it has an error and our solution requires =20 >>>> the error be corrected. >>>> >>>> Cheers >>>> James >>>> >>>> >>>> >>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens =20 >>>>> wrote: >>>>> >>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>> >>>>>> I am not very familiar with the process around updating=20 >>>>>> documents, but to me this suggests: >>>>>> - we should not need to do an update to RFC 6351, >>>>>> - we should fix the informative schema in the additional data =20 >>>>>> document to take into account the verified errata (there are =20 >>>>>> several), >>>>>> - we should seek review of "main-number" as an addition to=20 >>>>>> the registry, and update the additional data draft to formally=20 >>>>>> make that addition. >>>>> >>>>> This sounds reasonable to me. We also won't need to change the=20 >>>>> namespace. >>>>> >>>>> -- >>>>> Randall Gellens >>>>> Opinions are personal; facts are suspect; I speak for myself >>>>> only >>>>> -------------- Randomly selected tag: --------------- A list is=20 >>>>> only as strong as its weakest link. --Donald Knuth >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself onl= y >>> -------------- Randomly selected tag: --------------- 640K ought=20 >>> to be enough for anybody. --Bill Gates, 1981 >=20 >=20 From nobody Mon Mar 21 10:13: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 F193112D90C for ; Mon, 21 Mar 2016 10:13:44 -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, FREEMAIL_FROM=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=gmail.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 4RCxhnwZyBfw for ; Mon, 21 Mar 2016 10:13:43 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 672CA12D82F for ; Mon, 21 Mar 2016 10:13:31 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id 4so140622813pfd.0 for ; Mon, 21 Mar 2016 10:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vuisJ2u886z08f9/gUAThO4ZmYPG2vbzRNJaSml4x8Y=; b=fWRvT0FAFkgY/Xf/j4gSJjOBgPhaq8Wasq6/Lu6kttHp/hmOXfzVkgEcA1OSgE4XYn EY3m7cGnwkGD0E32YgNsPl1X9Ap1TorCUkgUAwchA3XFhVgEnYFUcum0OCqpBkyHZPAR LdklGBDw13oxZiA2KJIMntKcZmVqSWjx1q50kdqjvD6kiNXYXHsKcu63ZAzcwMy6ig9O gp9DhxhQjMLVr/PyVhXguYO7s2r2y/iPFCcC/c3j5oz06Ig6jl6AAskHHkfOiH8OiJfD z272cSw2aShLJpC/Da0VVX7ifSGZsQWM9oZwirunwMgkWKrlVpvN6DGcXvR9R9wBVphw z+fw== 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=vuisJ2u886z08f9/gUAThO4ZmYPG2vbzRNJaSml4x8Y=; b=Rs7AYl9qxim0ZQCUGjgR9Bf4lImQYIi0Aq/PeDgLF0R/r8k1ULJKi6dgUr9qQmUyAg w6u2EcDZRxNBWSpvgMFAJYAT2OyBnpYNyE/EHlrWOEQaPKEr0XVTuJOSiPjPfncSxWC1 cpcouQmwyJtD6nPzvNEGmVPunJsbJe0oK7QVRpMfdKdGNiuZEXGi0o17ayiNH2DskV2k JmDdpJeNYl2GpAoK4hhwoMKkqBCnWlHnUc2Uf/5Rchr4/e/5sOaa5bD1Y8N5hoP5mhkz HrJ7AI4cjHIAQsfdjqx2KuZCYsXJbs0vC5qBRPVzGXdhbTEhL9MvcBkX7LROTi+hWQuC PiPg== X-Gm-Message-State: AD7BkJKFKrCHfmtQM31r2ioi3DVTRmFo2r27K20ChweiZXavHwMNI6pIAm1Rf+idX7xTqg== X-Received: by 10.98.8.14 with SMTP id c14mr46552035pfd.42.1458580411030; Mon, 21 Mar 2016 10:13:31 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id 23sm42045209pfs.34.2016.03.21.10.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 10:13:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Tue, 22 Mar 2016 04:13:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> To: Dan Banks X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 17:13:45 -0000 Hi Dan, The =E2=80=9Cheld for update=E2=80=9D status is used for issues found = that are not necessary for an update to the RFC, so =E2=80=9Cverified=E2=80= =9D is the only status available that fits the problem. It isn=E2=80=99t = clear to me that this means that it is okay to make changes to the = schema in a registered namespace, it just says that the errata should be = available to implementors. That is to say does the errata say =E2=80=9Cbe = aware=E2=80=9D of the limitation that shouldn=E2=80=99t be there or fix = the schema in the current namespace and move on? I think that the Errata = status definitions could be more clear on this. I am not keen in just = changing bits of a registered schema because there are errors and = leaving it in the same namespace, this will certainly lead to = implementation errors. In the changes that have just gone in, the XML has moved to being = normative and it spells out that it is for additional-data, so while = x-names might be useful in a straight vCard, I question their = applicability to the additional-data work. To my mind the approach we have taken is unambiguous, where suppositions = about what the errata actual means could lead to problems. Cheers James > On 22 Mar 2016, at 3:20 am, Dan Banks wrote: >=20 > I'm not entirely sure this is the right way to go. >=20 > First, if the values can only come from the registry, that still = excludes the x-name values (which seems to me to be nearly as big of an = omission as leaving out the iana-token values). >=20 > Second, is changing the namespace really necessary? Perhaps I don't = understand the errata process correctly, but James' argument that the = RFC 6351 schema error requires it does not seem persuasive to me in = light of the existing errata already being verified status (as opposed = to held for update). That suggests to me that any RFC 6351 = implementation should take this errata into account. >=20 > Changing the namespace also brings new complications: the xCards will = not be interoperable with an RFC 6351 implementation (even one that = considers the errata), and the Appendix A schema would have to be = normative. This essentially redefines the entire xCard schema with an = XML schema when the previous version was a Relax NG schema. This = doesn't seem like a good idea to me. >=20 > Dan Banks >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Sunday, March 20, 2016 9:09 AM > To: Randall Gellens; James Winterbottom > Cc: Dan Banks; Andrew Newton; ecrit@ietf.org > Subject: Re: [Ecrit] Additional Data Draft (again) >=20 > Hi Randy, Hi James, >=20 > the proposal makes sense to me an I have been working on an update to = reflect these changes. >=20 > Here is the link to the work in progress document: > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-= data/draft-ietf-ecrit-additional-data-38.txt >=20 > Ciao > Hannes >=20 > On 03/19/2016 12:20 AM, Randall Gellens wrote: >> Thanks for listing the steps, James. >>=20 >> Hannes, does this sound like the plan to you? >>=20 >> Brian, do you concur? >>=20 >> Thanks everyone. >>=20 >> At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >>=20 >>> So, just make sure I am clear on what the plan is: >>> 1) Remove the enumeration for the schema so all values now come from=20= >>> the registry only >>> 2) Add main number to the registry >>> 3) Change the namespace >>> 4) Update all examples to use the new namespace >>> 5) register the namespace and schema with IANA >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>>> On 19 Mar 2016, at 8:51 am, Randall Gellens=20 >>>> wrote: >>>>=20 >>>> I'm OK with changing the namespace if we need to. >>>>=20 >>>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>>>=20 >>>>> I think that the general approach is okay, I remain unconvinced =20= >>>>> that we don't need a new namespace however, because the schema in =20= >>>>> RFC 6351 is normative and it has an error and our solution = requires =20 >>>>> the error be corrected. >>>>>=20 >>>>> Cheers >>>>> James >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens =20 >>>>>> wrote: >>>>>>=20 >>>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>>>=20 >>>>>>> I am not very familiar with the process around updating=20 >>>>>>> documents, but to me this suggests: >>>>>>> - we should not need to do an update to RFC 6351, >>>>>>> - we should fix the informative schema in the additional data = =20 >>>>>>> document to take into account the verified errata (there are =20 >>>>>>> several), >>>>>>> - we should seek review of "main-number" as an addition to=20 >>>>>>> the registry, and update the additional data draft to formally=20= >>>>>>> make that addition. >>>>>>=20 >>>>>> This sounds reasonable to me. We also won't need to change the=20= >>>>>> namespace. >>>>>>=20 >>>>>> -- >>>>>> Randall Gellens >>>>>> Opinions are personal; facts are suspect; I speak for = myself >>>>>> only >>>>>> -------------- Randomly selected tag: --------------- A list is=20= >>>>>> only as strong as its weakest link. --Donald Knuth >>>>=20 >>>>=20 >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself = only >>>> -------------- Randomly selected tag: --------------- 640K ought=20= >>>> to be enough for anybody. --Bill Gates, 1981 >>=20 >>=20 >=20 From nobody Mon Mar 21 12: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 0779312DAC2 for ; Mon, 21 Mar 2016 12:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 bUUCwPF1uGVt for ; Mon, 21 Mar 2016 12:31:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A4F12DAC0 for ; Mon, 21 Mar 2016 12:31:23 -0700 (PDT) Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVedf-1aHOAP1rNX-00Z2IT; Mon, 21 Mar 2016 20:31:15 +0100 To: Dan Banks , Randall Gellens , James Winterbottom References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F04C03.4010105@gmx.net> Date: Mon, 21 Mar 2016 20:31:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ELDMM56M5aS3k0JnhDtKsHbOPJv1B7X3N" X-Provags-ID: V03:K0:98Zm6aNwzsiF5ECuxNtnVL7qsIQ+F0fZFjEZqqdM/msJa7Mqgwa Lw5oc/AUlpbSVuAm/7I+PONNSozsLPgbLyTRuAAieyCBvP/To2m5wYDPWsofeGuGlAJlboq LLcvcNXWbKTfuoA2LEAv6rNlAkmwdiLV9HprhCMTiBIifOnjef2ybmEr1b6A0sy/ncmawSK qnwc+hOYeBB4C3OFr4zNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lk6k/sm0xrc=:JqOJSWSxGcjSCHaXrGntQG Lo+7NbxbFNIx+81NdXo8iyTQfsc5wOd6oXtHrmqIaOBvQ6RB7ve3cDQJdrKXhyR1g7M+eEgN9 Mrv2lchIWG6ZcxmQZ07i4eRxZVuk1pdncfZgQXht/tEdLgO0mmKZYyNnlkaxvE6mgp0DeKFut E28n4nOGgpmXrIorkUHP8LCjr9IsyBmRTirBWDGEI+uqyl9VqKls4I/igDsVtukVB7Hh78yjP +2Za/PQ3n6shxqqhkzcCCzOAMD9/Wkj0rxvMwFHt+BuCTSfJFTVrONFvCGs0IJmvweOcIozCo FI+OnJxHA5ze4Hm419zeDJ7B3iskS9SczRRVNn5P3L6aKdGqe/HdQF+lE6W6QEIxukgJBJZFz 1Ii45cudxyvOl1SGBjUcsrLgXytcTTVQoLW5GiGv2XfqSdM+Tk7RWe0E+9ZM+aAGAOn4AWeN0 AWN15Z9m8xSDMsTT8/T1qC/9/+D32qsLE1a92JdIvBwum9z+d8TWWo6HFJdOpghGyPb2WStn5 gCIqzvUwW18hOhpS8MXlyHJwrm/ukgOcxLxrLYH6oBk5faNxNnxElP43AXYvJV+M3KNUDqfbU tXdreme8HUTdlPfS7bxYkJiGiHcErxfKK8Z4HzUmvpQvDDBCUlYy6kplC8/hJXSCNMIlhjPxp tfGTATmtuKBIzdYB68gvFTESrnEwGO880hFas0dniArq6pIC7BMYWGrUObtaJ/6/Z+60PuJU3 +Dp2qos7+s9C9ynOwWkCeYjTTZDbNDQqKZlR10oCW2+C32yqPp6htmCNdBw= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 19:31:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ELDMM56M5aS3k0JnhDtKsHbOPJv1B7X3N Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, the situation looks a bit tricky. It seems that accepting the errata wasn't quite the right thing since it changes an XML schema without defining a new namespace and without registering the new schema. In some sense, we could be equally "relaxed" and just change their schema again (without changing the namespace). I believe it ultimately boils down to the question what the value of the XML schema actually is. I see a couple of different usages: a) If someone uses the XML schema to generate code then anything other than defining our own, corrected XML schema will lead to problems b) If the XML schema is only used by an implementer to validate instance documents than defining our own, corrected XML schema will also be needed= =2E c) If the XML schema is, however, only used as a different way of reading the document content then changing the schema within the text (as we had done up to version -37) is fine. I personally think that most developers don't do (a) and (b) and that's why most of the XML schemas in technical specifications are actually broken (not only in the IETF but also elsewhere). The "most developers" is important here since we have found developers, such as Philip, who actually produce code based on the schema (which is why he found problems= ). However, by making these types of "fixes" we are obviously not going to improve the situation. It is also the question what the IESG and the area directors think about this situation. In some sense it is not only about the use of XML schemas but the issue is a bit more broadly related to the use of formal languages in the IETF in general. There are many other places where we messed things up, such as with ABNF. Ultimately, it fear it will boil down to a different question, namely: What does it mean if the VCard schema in our spec is different from the original VCard schema in terms of re-use with existing software. Ciao Hannes On 03/21/2016 05:20 PM, Dan Banks wrote: > I'm not entirely sure this is the right way to go. >=20 > First, if the values can only come from the registry, that still > excludes the x-name values (which seems to me to be nearly as big of > an omission as leaving out the iana-token values). >=20 > Second, is changing the namespace really necessary? Perhaps I don't > understand the errata process correctly, but James' argument that the > RFC 6351 schema error requires it does not seem persuasive to me in > light of the existing errata already being verified status (as > opposed to held for update). That suggests to me that any RFC 6351 > implementation should take this errata into account. >=20 > Changing the namespace also brings new complications: the xCards will > not be interoperable with an RFC 6351 implementation (even one that > considers the errata), and the Appendix A schema would have to be > normative. This essentially redefines the entire xCard schema with > an XML schema when the previous version was a Relax NG schema. This > doesn't seem like a good idea to me. >=20 > Dan Banks >=20 > -----Original Message----- From: Hannes Tschofenig > [mailto:hannes.tschofenig@gmx.net] Sent: Sunday, March 20, 2016 9:09 > AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew > Newton; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data Draft > (again) >=20 > Hi Randy, Hi James, >=20 > the proposal makes sense to me an I have been working on an update to > reflect these changes. >=20 > Here is the link to the work in progress document:=20 > https://github.com/hannestschofenig/tschofenig-ids/blob/master/addition= al-data/draft-ietf-ecrit-additional-data-38.txt > > Ciao Hannes >=20 > On 03/19/2016 12:20 AM, Randall Gellens wrote: >> Thanks for listing the steps, James. >>=20 >> Hannes, does this sound like the plan to you? >>=20 >> Brian, do you concur? >>=20 >> Thanks everyone. >>=20 >> At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >>=20 >>> So, just make sure I am clear on what the plan is: 1) Remove the >>> enumeration for the schema so all values now come from the >>> registry only 2) Add main number to the registry 3) Change the >>> namespace 4) Update all examples to use the new namespace 5) >>> register the namespace and schema with IANA >>>=20 >>> Cheers James >>>=20 >>>=20 >>>=20 >>>> On 19 Mar 2016, at 8:51 am, Randall Gellens=20 >>>> wrote: >>>>=20 >>>> I'm OK with changing the namespace if we need to. >>>>=20 >>>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>>>=20 >>>>> I think that the general approach is okay, I remain >>>>> unconvinced that we don't need a new namespace however, >>>>> because the schema in RFC 6351 is normative and it has an >>>>> error and our solution requires the error be corrected. >>>>>=20 >>>>> Cheers James >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens=20 >>>>>> wrote: >>>>>>=20 >>>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>>>=20 >>>>>>> I am not very familiar with the process around updating=20 >>>>>>> documents, but to me this suggests: - we should not need >>>>>>> to do an update to RFC 6351, - we should fix the >>>>>>> informative schema in the additional data document to >>>>>>> take into account the verified errata (there are=20 >>>>>>> several), - we should seek review of "main-number" as an >>>>>>> addition to the registry, and update the additional data >>>>>>> draft to formally make that addition. >>>>>>=20 >>>>>> This sounds reasonable to me. We also won't need to change >>>>>> the namespace. >>>>>>=20 >>>>>> -- Randall Gellens Opinions are personal; facts are >>>>>> suspect; I speak for myself only -------------- Randomly >>>>>> selected tag: --------------- A list is only as strong as >>>>>> its weakest link. --Donald Knuth >>>>=20 >>>>=20 >>>> -- Randall Gellens Opinions are personal; facts are suspect; >>>> I speak for myself only -------------- Randomly selected tag: >>>> --------------- 640K ought to be enough for anybody. --Bill >>>> Gates, 1981 >>=20 >>=20 >=20 --ELDMM56M5aS3k0JnhDtKsHbOPJv1B7X3N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW8EwDAAoJEGhJURNOOiAt4WkIAIAeGHnCCL9Xe1Qho1JUq4MX is4eWyWceKK0EoHXmvHV9wu7HzitdWd36O3uPpcWWn8CEf/99vAewzI1Haz6nZO1 18wNvGjPVV0Zvjp709Bl9CBS6VrL9oXTIWFMp8jaQDqQysDVY9sxSNb1Pfc47Edo IxbBT541MoKTbLdQKnTi7E8GcDtS9+Szy6j7Jx8j5UYAeKHGskuv5vKlLZSlenf8 e4FLhNrlbCkQhxE1RcfeUMeDEMxMMU7RbZ3nkI5RGSC3A1gskoDn+LZfXymeHDan Adc4UQvFZSPHbWvGl4d5qsq0c4EdugOcUp+/6GrxVkQG0KrnDqA09BnAXWAWDzs= =3rq8 -----END PGP SIGNATURE----- --ELDMM56M5aS3k0JnhDtKsHbOPJv1B7X3N-- From nobody Mon Mar 21 12:37: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 7213512DA7A for ; Mon, 21 Mar 2016 12:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-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 tPql7D1zW_V5 for ; Mon, 21 Mar 2016 12:37:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B0512DA51 for ; Mon, 21 Mar 2016 12:37:36 -0700 (PDT) Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSMP5-1aKfrR2NH1-00TXsl for ; Mon, 21 Mar 2016 20:37:34 +0100 To: "ecrit@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F04D81.4020307@gmx.net> Date: Mon, 21 Mar 2016 20:37:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mFMRXRQmKI9Dn9RtXJcol2fOGXPKIQvtd" X-Provags-ID: V03:K0:dgaS8htRzM/unS8+wjcheQN2kpIgFZej0nP8M65SBdQMi+HlALy 8FQZHTUY413DTchH4zlKbLi+TWa33y263rosXDaZAsNEvKx3JW9u0Ooalm9rlgjHn9BOX9t +4AVeRFJSQ9CGr/xaYZM2EMazB6FAYuzt0hNBthC/mAIAzcRwPpoIhFrntNyt1o45SMdooE qL6yfow/BFBSKlyG+0RwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:SDTImNjW2/o=:ocVNJwYq0caVrWW2GMxrvw 40h4v+dWeEgTZVQM1V5upCMHZ6JU9i5pLuI5+7mMxj47dCYlbsqLd+ewW3SZKKHLGYkO3We2I agL1WswiIqdFUeTPyXbuYm4JNiSymTr8+xYqIR3abuOFQx+o1ofwrDetzwBol+nIRASPTLXWl BBucpCn44ZrEMwuIml7ZgLBK6mUR9+Oc5steByb6pONrGJyn/x3YEw0g5ZaTZVVWLFY8yZlU0 1p8zgiiia/QQkEloVQdjskNP+6+gumhi14PPgrNWQZQuB6HZ80uYoyI9LZrptxhpDZ0ZMdbU2 maFOA+3WTVnGLAwYphjQSH8Qi3h/x9e3Mr36Y3YdcByV4wUdVYBUfEflRuYzlTm/BbvRGTjZU 5T1iaWHTZcD2DpvOrf1d9bFFrlm1Ia4l6wQiH3OMZS9bB6znGEXt8BlSBMAaAA9Gu3B1hv4qa I0nkyd6RHh9/g8uMrb/Bb4J2dVzEqptk/f+pS3indr0tn44I3x7jVUH2mAnxQpWwtv7G+jgRO /s2F/lzXmhAdjBuO6wmOGz9emMbcCyaw95t7p8qPNh3wRp2FhHtDDf29Ua/geicDupU5RSi8p BAca6MPCFJkLEeQZekxn7zBYb6Kh7HbH40WzAsep+Vmdmtzx1UlIYQjSdlBv7FXLfWWEnDWJv e/1QW53SPPc0h6BQZJAIpZXbPJeEc7+9v8Uzr9Xd5AgeIWGRwCB3/lzmMXVMbvXAl1Ue2yxkM B7TmtQwlt+oqmtcSgn0VUGFOlnhnnUdctensRtTCgEIUl/ZVHk+KHjdodrM= Archived-At: Subject: [Ecrit] Additional Data Draft: Editor's copy X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 19:37:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mFMRXRQmKI9Dn9RtXJcol2fOGXPKIQvtd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, it seems that our discussions on the additional data draft cannot be settled before the submission deadline. For this reason I prefer not to upload a new version yet. There is, however, a version in the Github repository where we made changes to the XML schema and this draft version can be found at: https://raw.githubusercontent.com/hannestschofenig/tschofenig-ids/master/= additional-data/draft-ietf-ecrit-additional-data-38.txt The diff to version -37 can be found at: http://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-ecrit-additional-data-37.txt&url2=3Dhttps://raw.githubusercontent.com/h= annestschofenig/tschofenig-ids/master/additional-data/draft-ietf-ecrit-ad= ditional-data-38.txt I don't know how my other co-authors see this issue. Ciao Hannes --mFMRXRQmKI9Dn9RtXJcol2fOGXPKIQvtd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW8E2BAAoJEGhJURNOOiAtHMgIAIMIzyh4LFRoFzmWDGscSrIu NiBFfc+sslFsYKF9nViETR97Ka7Y6CjUhtQP4dzd8WLsAhFk5ak2ldszZ9FIhbJZ PlofeRaqhzQOdC6QWBmM963q62qCyLHsyP4+XVvTkjgMkE1PVl33UvEVk3m0KsBY 5Xpn+PmDowWFwQy9Cdj1f7rd2X3+qg7N/iHE3tqt0Rt57FYms1VKKuzCHFPgVH3z SZHvyEAu1TGGTVw81ylYqeVj2pFDG2wmtnLHk7XN3lw3hK7uTHjIe7r9sw8wbuMc vIQgRjUbmYEcXkPFYdB1+ZckbPQoxT+f6Y6ay5anaOUEqOTLsdN0/noAbaBZpZk= =IwOG -----END PGP SIGNATURE----- --mFMRXRQmKI9Dn9RtXJcol2fOGXPKIQvtd-- From nobody Mon Mar 21 13:27: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 C0E6F12DAF2 for ; Mon, 21 Mar 2016 13:24:44 -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 LeqzsZ5sfRbL for ; Mon, 21 Mar 2016 13:24:37 -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 7E92D12DA88 for ; Mon, 21 Mar 2016 13:24:37 -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 u2LKOSTI004906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 13:24:28 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.193]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 13:24:28 -0700 From: Roger Marshall To: Emergency Context Resolution with Internet Technologies Discussion List Thread-Topic: New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRXIVIw4c4Fnkyf0qyrArNgq0z3p9kpb5g Date: Mon, 21 Mar 2016 20:24:27 +0000 Message-ID: References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> In-Reply-To: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 21 Mar 2016 13:27:33 -0700 Cc: Marc Linsner , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 20:24:45 -0000 RUNSSVQgV0c6DQoNClRoZSBjaGFpcnMgaGF2ZSByZXZpZXdlZCB0aGUgdGhyZWFkIGNvbmNlcm5p bmcgcHJvY2Vzc2luZyBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTA1IGFuZCBkcmFmdC1pZXRmLWVj cml0LWNhci1jcmFzaC0wNSBhcyB3ZWxsIGFzIHRoZSBtb3N0IHJlY2VudCBsaWFpc29uIHJlY2Vp dmVkIGZyb20gM0dQUCBvbiAxLzMxLzIwMTYgYW5kIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3Jz LiAgR2l2ZW4gdGhhdCAzR1BQIGlzIG5vdCBzY2hlZHVsZWQgdG8gZmluaXNoIHRoZWlyIHdvcmsg dW50aWwgSnVuZSAyMDE3LCB3ZSB3aWxsIGNvbnRpbnVlIHByb2dyZXNzaW5nIHRoZXNlIGRyYWZ0 cyB0byBJRVRGIGxhc3QgY2FsbCBhcyBzY2hlZHVsZWQuIFdlIGFsc28gcmVtaW5kIHRoZSB3b3Jr aW5nIGdyb3VwIHRoYXQgdGhlIElFVEYgcHJvY2VzcyBhbGxvd3MgY2hhbmdlcyB0byBSRkMgcHVi bGljYXRpb25zLCBlLmcuLCBpc3N1YW5jZSBvZiBiaXMgUkZDcyBpbiB0aGUgZXZlbnQgdGhhdCBj aGFuZ2VzIGluIHRlY2hub2xvZ3kgcmVzdWx0IGluIHRoZSBuZWVkIHRvIG1ha2Ugc3VjaCBhIGNo YW5nZS4gIFN1Y2ggZG9jdW1lbnRzIHdvdWxkIGJlIGluIHNjb3BlIG9mIHRoZSBjdXJyZW50IEVD UklUIGNoYXJ0ZXIsIHNob3VsZCB0aGUgbmVlZCBhcmlzZS4gDQoNCldlIHdpbGwgc2VuZCBhIHJl cGx5IGxpYWlzb24gc3RhdGVtZW50IHRvIDNHUFAgdG8gaW5mb3JtIHRoZW0gb2YgdGhlIHN0YXR1 cyBvZiB0aGUgZG9jdW1lbnRzIGFmdGVyIHdlIHBvc3QgdGhlIHByb3Bvc2VkIGxpYWlzb24gdGV4 dCB0byB0aGUgbGlzdCwgd2hpY2ggd2lsbCBoYXBwZW4gc2hvcnRseS4NCg0KDQpSb2dlciBNYXJz aGFsbCAocm9nZXIubWFyc2hhbGxAY29tdGVjaHRlbC5jb20pICAmDQpNYXJjIExpbnNuZXIgKG1s aW5zbmVyQGNpc2NvLmNvbSkNCkVjcml0IGNoYWlycw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRv OmxzbXRAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDMxLCAyMDE2IDQ6MTMgUE0N ClRvOiBSb2dlciBNYXJzaGFsbDsgTWFyYyBMaW5zbmVyDQpDYzogQmFycnkgTGVpYmE7IE1hcmMg TGluc25lcjsgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hu b2xvZ2llcyBEaXNjdXNzaW9uIExpc3Q7IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tOyAzR1BQ TGlhaXNvbkBldHNpLm9yZzsgUm9nZXIgTWFyc2hhbGw7IEFsaXNzYSBDb29wZXI7IEJlbiBDYW1w YmVsbA0KU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24g TkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KDQpUaXRsZTogUmVzcG9uc2UgdG8gTFMgb24g TkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIFN1Ym1pc3Npb24gRGF0ZTogMjAxNi0wMS0zMSBV Ukwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xNDUyLw0KDQpGcm9tOiAiU3VzYW5uYSBLb29pc3RyYSIgPDNHUFBMaWFpc29uQGV0c2ku b3JnPg0KVG86IE1hcmMgTGluc25lciA8bWFyYy5saW5zbmVyQGNpc2NvLmNvbT4sIFJvZ2VyIE1h cnNoYWxsIDxybWFyc2hhbGxAdGVsZWNvbXN5cy5jb20+DQpDYzogQmFycnkgTGVpYmEgPGJhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnPixNYXJjIExpbnNuZXIgPG1hcmMubGluc25lckBjaXNjby5jb20+ LEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPixBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29v cGVydy5pbj4sUm9nZXIgTWFyc2hhbGwgPHJtYXJzaGFsbEB0ZWxlY29tc3lzLmNvbT4sRW1lcmdl bmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNz aW9uIExpc3QgPGVjcml0QGlldGYub3JnPiwgUmVzcG9uc2UgQ29udGFjdHM6IGdlb3JnLm1heWVy Lmh1YXdlaUBnbXguY29tLCAzR1BQTGlhaXNvbkBldHNpLm9yZyBUZWNobmljYWwgQ29udGFjdHM6 IA0KUHVycG9zZTogSW4gcmVzcG9uc2UNCg0KUmVmZXJlbmNlZCBsaWFpc29uOiBMaWFpc29uIFN0 YXRlbWVudCBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUgKGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDEyLykNCg0KQm9keTogMS4gT3ZlcmFsbCBkZXNjcmlwdGlv bg0KM0dQUCBUU0cgQ1QgV0cxIHdvdWxkIGxpa2UgdG8gdGhhbmsgSUVURiBFY3JpdCBXRyBmb3Ig dGhlIExTIChDMS0xNTI2NDQpIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVS4NCjNHUFAg VFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIGluZm9ybSBJRVRGIEVjcml0IFdHIHRoYXQgM0dQUCBU U0cgQ1QgV0cxIHdpbGwgd29yayBvbiBzdGFnZS0zIGZvciBlQ2FsbCBpbiBJTVMgaW4gUmVsZWFz ZSAxNCAoZW5kaW5nIGluIEp1bmUgMjAxNyksIHN1YmplY3QgdG8gM0dQUCBUU0cgU0EgV0cyIGNv bXBsZXRpb24gb2YgdGhlIG5vcm1hdGl2ZSBzdGFnZS0yIHdvcmsgYW5kIGFwcHJvdmFsIG9mIGEg M0dQUCBUU0cgQ1Qgd29yayBpdGVtLg0KM0dQUCBUU0cgQ1QgV0cxIHN0YWdlLTMgd29yayBtaWdo dCByZXN1bHQgaW4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGRldmlhdGluZyBvciBjb25mbGljdGlu ZyB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgSUVURiBkcmFmdC1pZXRmLWVjcml0LWVjYWxs LCBhbmQgdGh1cyBtaWdodCBpbXBhY3QgSUVURiB3b3JrLiANCg0KMi4gQWN0aW9ucw0KVG8gSUVU RiBFY3JpdCBXRw0KQUNUSU9OOiAzR1BQIFRTRyBDVCBXRzEgcmVzcGVjdGZ1bGx5IGFza3MgSUVU RiBFY3JpdCBXRyB0byB0YWtlIHRoZSBhYm92ZSBpbnRvIGNvbnNpZGVyYXRpb24uDQoNCjMuIERh dGVzIG9mIG5leHQgVFNHIENUIFdHMSBtZWV0aW5ncw0KVFNHIENUIFdHMSBNZWV0aW5nIDk2CTE1 LTE5IEZlYnJ1YXJ5IDIwMTYJSmVqdSBJc2xhbmQsIEtvcmVhDQpUU0cgQ1QgV0cxIE1lZXRpbmcg OTcJMTEtMTUgQXByaWwgMjAxNglManVibGphbmEsIFNsb3ZlbmlhDQoNCg0KQXR0YWNobWVudHM6 DQoNCiAgICBSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0y MDE2LTAxLTMxLTNncHAtdHNnY3QtY3QxLWVjcml0LXJlc3BvbnNlLXRvLWxzLW9uLW5nLWVjYWxs LXN1cHBvcnQtZm9yLXRoZS1ldS1hdHRhY2htZW50LTEucGRmDQoNCg0KTk9USUNFIFRPIFJFQ0lQ SUVOVDogVGhpcyBlbWFpbCwgaW5jbHVkaW5nIGF0dGFjaG1lbnRzLCBtYXkgY29udGFpbiBpbmZv cm1hdGlvbiB3aGljaCBpcyBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBhdHRvcm5leS1jbGll bnQgcHJpdmlsZWdlZCBhbmQvb3IgY29udHJvbGxlZCB1bmRlciBVLlMuIGV4cG9ydCBsYXdzIGFu ZCByZWd1bGF0aW9ucyBhbmQgbWF5IGJlIHJlc3RyaWN0ZWQgZnJvbSBkaXNjbG9zdXJlIGJ5IGFw cGxpY2FibGUgU3RhdGUgYW5kIEZlZGVyYWwgbGF3LiBOb3RoaW5nIGluIHRoaXMgZW1haWwgc2hh bGwgY3JlYXRlIGFueSBsZWdhbCBiaW5kaW5nIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBwYXJ0aWVz IHVubGVzcyBleHByZXNzbHkgc3RhdGVkIGhlcmVpbiBhbmQgcHJvdmlkZWQgYnkgYW4gYXV0aG9y aXplZCByZXByZXNlbnRhdGl2ZSBvZiBDb210ZWNoIFRlbGVjb21tdW5pY2F0aW9ucyBDb3JwLiBv ciBpdHMgc3Vic2lkaWFyaWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgbWVzc2FnZSwgYmUgYWR2aXNlZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24sIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmV0dXJuIGVtYWlsIGFuZCBwZXJtYW5lbnRs eSBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgZW1haWwgYW5kIGFueSBhdHRhY2hl ZCBkb2N1bWVudGF0aW9uIGZyb20gYW55IGNvbXB1dGVyIG9yIG90aGVyIG1lZGlhLg0K From nobody Mon Mar 21 14:36: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 473F012DBB8 for ; Mon, 21 Mar 2016 14:36: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, 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 aKWEqEvNz6jZ for ; Mon, 21 Mar 2016 14:36:50 -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 0F6C612DC15 for ; Mon, 21 Mar 2016 14:35:24 -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 u2LLZGqr004285 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 14:35:16 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.193]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 14:35:15 -0700 From: Roger Marshall To: Emergency Context Resolution with Internet Technologies Discussion List Thread-Topic: New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRXIVIw4c4Fnkyf0qyrArNgq0z3p9kpb5ggAARIlA= Date: Mon, 21 Mar 2016 21:35:15 +0000 Message-ID: References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Marc Linsner , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 21:36:53 -0000 UHJvcG9zZWQgTGlhaXNvbiByZXNwb25zZToNCg0KVGhlIElFVEYgRUNSSVQgd29ya2luZyBncm91 cCB3b3VsZCBsaWtlIHRvIHRoYW5rIDNHUFAgVFNHIENUIFdHMSBmb3IgdGhlaXIgcmVzcG9uc2Us IFREb2MgQzEtMTYwNzY0LCByZWZlcmVuY2luZyBMUyAoQzEtMTUyNjQ0KSBvbiB0aGUgdG9waWMg b2YgTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVLiAgDQoNClRoZSBFQ1JJVCB3b3JraW5nIGdy b3VwIGRpc2N1c3NlZCB5b3VyIGxpYWlzb24gYXMgaXQgYXBwbGllcyB0byB0aGUgSUVURiBkcmFm dC1pZXRmLWVjcml0LWVjYWxsIGRvY3VtZW50IGFuZCByZWFjaGVkIHRoZSBmb2xsb3dpbmcgY29u Y2x1c2lvbnM6ICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90IHNjaGVkdWxlZCB0byBmaW5pc2ggdGhl aXIgc3RhZ2UtMyB3b3JrIGZvciBlQ2FsbCBpbiBJTVMgdW50aWwgSnVuZSAyMDE3LCBhcyBwYXJ0 IG9mIFJlbGVhc2UgMTQsIHdlIHdpbGwgY29udGludWUgcHJvZ3Jlc3NpbmcgdGhlc2UgZHJhZnRz IHRvIElFVEYgbGFzdCBjYWxsIGFzIGN1cnJlbnRseSBzY2hlZHVsZWQuDQoNCldlIGFsc28gYWNr bm93bGVkZ2UgdGhhdCBkdXJpbmcgM0dQUCdzIGRldmVsb3BtZW50IHBoYXNlLCBzb21lIGRpZmZl cmVuY2VzIG1heSBvY2N1ciBiZXR3ZWVuIHRoYXQgd2hpY2ggaXMgb3V0bGluZWQgd2l0aGluIHRo ZSBleGlzdGluZyBkcmFmdC1pZXRmLWVjcml0LWVjYWxsIGFuZCB0aGF0IHdoaWNoIGVtZXJnZXMg ZnJvbSB0aGUgM0dQUCB3b3JrLiBUaGUgSUVURiBwcm9jZXNzIGFsbG93cyBmb3IgUkZDcyB0byBi ZSByZXZpc2VkIGluIHRoZSBldmVudCBvZiBjaGFuZ2VzIGluIHRlY2hub2xvZ3kuDQoNCldlJ2xs IGNvbGxlY3Qgd2cgbWVtYmVyIGNvbW1lbnRzIG92ZXIgdGhlIG5leHQgZmV3IGRheXMgYW5kIHdp bGwgdGhlbiBtb3ZlIHRvIHNlbmQgb3V0IHRoZSBvZmZpY2lhbCByZXNwb25zZSB0byAzR1BQLg0K DQoNClJvZ2VyIE1hcnNoYWxsDQpSb2dlci5tYXJzaGFsbEBjb210ZWNodGVsLmNvbQ0KTWFyYyBM aW5zbmVyDQptbGluc25lckBjaXNjby5jb20NCkVDUklUIENoYWlycw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2dlciBNYXJzaGFsbCANClNlbnQ6IE1vbmRheSwgTWFy Y2ggMjEsIDIwMTYgMToyNCBQTQ0KVG86IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0 aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0DQpDYzogTWFyYyBMaW5zbmVy OyBBbGlzc2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwNClN1YmplY3Q6IFJFOiBOZXcgTGlhaXNvbiBT dGF0ZW1lbnQsICJSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUi DQoNCkVDUklUIFdHOg0KDQpUaGUgY2hhaXJzIGhhdmUgcmV2aWV3ZWQgdGhlIHRocmVhZCBjb25j ZXJuaW5nIHByb2Nlc3NpbmcgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0wNSBhbmQgZHJhZnQtaWV0 Zi1lY3JpdC1jYXItY3Jhc2gtMDUgYXMgd2VsbCBhcyB0aGUgbW9zdCByZWNlbnQgbGlhaXNvbiBy ZWNlaXZlZCBmcm9tIDNHUFAgb24gMS8zMS8yMDE2IGFuZCBkaXNjdXNzZWQgd2l0aCB0aGUgYXV0 aG9ycy4gIEdpdmVuIHRoYXQgM0dQUCBpcyBub3Qgc2NoZWR1bGVkIHRvIGZpbmlzaCB0aGVpciB3 b3JrIHVudGlsIEp1bmUgMjAxNywgd2Ugd2lsbCBjb250aW51ZSBwcm9ncmVzc2luZyB0aGVzZSBk cmFmdHMgdG8gSUVURiBsYXN0IGNhbGwgYXMgc2NoZWR1bGVkLiBXZSBhbHNvIHJlbWluZCB0aGUg d29ya2luZyBncm91cCB0aGF0IHRoZSBJRVRGIHByb2Nlc3MgYWxsb3dzIGNoYW5nZXMgdG8gUkZD IHB1YmxpY2F0aW9ucywgZS5nLiwgaXNzdWFuY2Ugb2YgYmlzIFJGQ3MgaW4gdGhlIGV2ZW50IHRo YXQgY2hhbmdlcyBpbiB0ZWNobm9sb2d5IHJlc3VsdCBpbiB0aGUgbmVlZCB0byBtYWtlIHN1Y2gg YSBjaGFuZ2UuICBTdWNoIGRvY3VtZW50cyB3b3VsZCBiZSBpbiBzY29wZSBvZiB0aGUgY3VycmVu dCBFQ1JJVCBjaGFydGVyLCBzaG91bGQgdGhlIG5lZWQgYXJpc2UuIA0KDQpXZSB3aWxsIHNlbmQg YSByZXBseSBsaWFpc29uIHN0YXRlbWVudCB0byAzR1BQIHRvIGluZm9ybSB0aGVtIG9mIHRoZSBz dGF0dXMgb2YgdGhlIGRvY3VtZW50cyBhZnRlciB3ZSBwb3N0IHRoZSBwcm9wb3NlZCBsaWFpc29u IHRleHQgdG8gdGhlIGxpc3QsIHdoaWNoIHdpbGwgaGFwcGVuIHNob3J0bHkuDQoNCg0KUm9nZXIg TWFyc2hhbGwgKHJvZ2VyLm1hcnNoYWxsQGNvbXRlY2h0ZWwuY29tKSAgJg0KTWFyYyBMaW5zbmVy IChtbGluc25lckBjaXNjby5jb20pDQpFY3JpdCBjaGFpcnMNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBMaWFpc29uIFN0YXRlbWVudCBNYW5hZ2VtZW50IFRvb2wgW21h aWx0bzpsc210QGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgSmFudWFyeSAzMSwgMjAxNiA0OjEz IFBNDQpUbzogUm9nZXIgTWFyc2hhbGw7IE1hcmMgTGluc25lcg0KQ2M6IEJhcnJ5IExlaWJhOyBN YXJjIExpbnNuZXI7IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBU ZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0OyBnZW9yZy5tYXllci5odWF3ZWlAZ214LmNvbTsg M0dQUExpYWlzb25AZXRzaS5vcmc7IFJvZ2VyIE1hcnNoYWxsOyBBbGlzc2EgQ29vcGVyOyBCZW4g Q2FtcGJlbGwNClN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIlJlc3BvbnNlIHRvIExT IG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSINCg0KVGl0bGU6IFJlc3BvbnNlIHRvIExT IG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSBTdWJtaXNzaW9uIERhdGU6IDIwMTYtMDEt MzEgVVJMIG9mIHRoZSBJRVRGIFdlYiBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2xpYWlzb24vMTQ1Mi8NCg0KRnJvbTogIlN1c2FubmEgS29vaXN0cmEiIDwzR1BQTGlhaXNvbkBl dHNpLm9yZz4NClRvOiBNYXJjIExpbnNuZXIgPG1hcmMubGluc25lckBjaXNjby5jb20+LCBSb2dl ciBNYXJzaGFsbCA8cm1hcnNoYWxsQHRlbGVjb21zeXMuY29tPg0KQ2M6IEJhcnJ5IExlaWJhIDxi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4sTWFyYyBMaW5zbmVyIDxtYXJjLmxpbnNuZXJAY2lzY28u Y29tPixCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4sQWxpc3NhIENvb3BlciA8YWxpc3Nh QGNvb3BlcncuaW4+LFJvZ2VyIE1hcnNoYWxsIDxybWFyc2hhbGxAdGVsZWNvbXN5cy5jb20+LEVt ZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgRGlz Y3Vzc2lvbiBMaXN0IDxlY3JpdEBpZXRmLm9yZz4sIFJlc3BvbnNlIENvbnRhY3RzOiBnZW9yZy5t YXllci5odWF3ZWlAZ214LmNvbSwgM0dQUExpYWlzb25AZXRzaS5vcmcgVGVjaG5pY2FsIENvbnRh Y3RzOiANClB1cnBvc2U6IEluIHJlc3BvbnNlDQoNClJlZmVyZW5jZWQgbGlhaXNvbjogTGlhaXNv biBTdGF0ZW1lbnQgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQxMi8pDQoNCkJvZHk6IDEuIE92ZXJhbGwgZGVzY3Jp cHRpb24NCjNHUFAgVFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIHRoYW5rIElFVEYgRWNyaXQgV0cg Zm9yIHRoZSBMUyAoQzEtMTUyNjQ0KSBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUuDQoz R1BQIFRTRyBDVCBXRzEgd291bGQgbGlrZSB0byBpbmZvcm0gSUVURiBFY3JpdCBXRyB0aGF0IDNH UFAgVFNHIENUIFdHMSB3aWxsIHdvcmsgb24gc3RhZ2UtMyBmb3IgZUNhbGwgaW4gSU1TIGluIFJl bGVhc2UgMTQgKGVuZGluZyBpbiBKdW5lIDIwMTcpLCBzdWJqZWN0IHRvIDNHUFAgVFNHIFNBIFdH MiBjb21wbGV0aW9uIG9mIHRoZSBub3JtYXRpdmUgc3RhZ2UtMiB3b3JrIGFuZCBhcHByb3ZhbCBv ZiBhIDNHUFAgVFNHIENUIHdvcmsgaXRlbS4NCjNHUFAgVFNHIENUIFdHMSBzdGFnZS0zIHdvcmsg bWlnaHQgcmVzdWx0IGluIHByb3RvY29sIHJlcXVpcmVtZW50cyBkZXZpYXRpbmcgb3IgY29uZmxp Y3Rpbmcgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIElFVEYgZHJhZnQtaWV0Zi1lY3JpdC1l Y2FsbCwgYW5kIHRodXMgbWlnaHQgaW1wYWN0IElFVEYgd29yay4gDQoNCjIuIEFjdGlvbnMNClRv IElFVEYgRWNyaXQgV0cNCkFDVElPTjogM0dQUCBUU0cgQ1QgV0cxIHJlc3BlY3RmdWxseSBhc2tz IElFVEYgRWNyaXQgV0cgdG8gdGFrZSB0aGUgYWJvdmUgaW50byBjb25zaWRlcmF0aW9uLg0KDQoz LiBEYXRlcyBvZiBuZXh0IFRTRyBDVCBXRzEgbWVldGluZ3MNClRTRyBDVCBXRzEgTWVldGluZyA5 NgkxNS0xOSBGZWJydWFyeSAyMDE2CUplanUgSXNsYW5kLCBLb3JlYQ0KVFNHIENUIFdHMSBNZWV0 aW5nIDk3CTExLTE1IEFwcmlsIDIwMTYJTGp1YmxqYW5hLCBTbG92ZW5pYQ0KDQoNCkF0dGFjaG1l bnRzOg0KDQogICAgUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVV DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlz b24tMjAxNi0wMS0zMS0zZ3BwLXRzZ2N0LWN0MS1lY3JpdC1yZXNwb25zZS10by1scy1vbi1uZy1l Y2FsbC1zdXBwb3J0LWZvci10aGUtZXUtYXR0YWNobWVudC0xLnBkZg0KDQoNCk5PVElDRSBUTyBS RUNJUElFTlQ6IFRoaXMgZW1haWwsIGluY2x1ZGluZyBhdHRhY2htZW50cywgbWF5IGNvbnRhaW4g aW5mb3JtYXRpb24gd2hpY2ggaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgYXR0b3JuZXkt Y2xpZW50IHByaXZpbGVnZWQgYW5kL29yIGNvbnRyb2xsZWQgdW5kZXIgVS5TLiBleHBvcnQgbGF3 cyBhbmQgcmVndWxhdGlvbnMgYW5kIG1heSBiZSByZXN0cmljdGVkIGZyb20gZGlzY2xvc3VyZSBi eSBhcHBsaWNhYmxlIFN0YXRlIGFuZCBGZWRlcmFsIGxhdy4gTm90aGluZyBpbiB0aGlzIGVtYWls IHNoYWxsIGNyZWF0ZSBhbnkgbGVnYWwgYmluZGluZyBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgcGFy dGllcyB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBoZXJlaW4gYW5kIHByb3ZpZGVkIGJ5IGFuIGF1 dGhvcml6ZWQgcmVwcmVzZW50YXRpdmUgb2YgQ29tdGVjaCBUZWxlY29tbXVuaWNhdGlvbnMgQ29y cC4gb3IgaXRzIHN1YnNpZGlhcmllcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBvZiB0aGlzIG1lc3NhZ2UsIGJlIGFkdmlzZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlbWFpbCBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsIGFuZCBhbnkgYXR0 YWNoZWQgZG9jdW1lbnRhdGlvbiBmcm9tIGFueSBjb21wdXRlciBvciBvdGhlciBtZWRpYS4NCg== From nobody Mon Mar 21 15:26:10 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 4D7FB12D0AD; Mon, 21 Mar 2016 15:26:09 -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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321222609.12259.64062.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:26:09 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-02.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: Mon, 21 Mar 2016 22:26:09 -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 : A LoST extension to return complete and similar location info Authors : Roger Marshall Jeff Martin Brian Rosen Filename : draft-ietf-ecrit-similar-location-02.txt Pages : 16 Date : 2016-03-21 Abstract: This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as a compilation of CAtype xml elements within the existing LoST findServiceResponse message structure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-similar-location-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-02 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 Mar 21 16:19: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 C9DAC12D161 for ; Mon, 21 Mar 2016 16:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ooml8a3i6tX for ; Mon, 21 Mar 2016 16:19:44 -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 BA3EB12D166 for ; Mon, 21 Mar 2016 16:19:44 -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 u2LNJeVr008611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 16:19:40 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.193]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 16:19:40 -0700 From: Roger Marshall To: Emergency Context Resolution with Internet Technologies Discussion List Thread-Topic: IETF95 ECRIT draft agenda posted Thread-Index: AdGDyB+hJWcyj4LUQDi3pvn5YZGV9g== Date: Mon, 21 Mar 2016 23:19:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39840D82SEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Cc: "Ben Campbell \(ben@nostrum.com\)" Subject: [Ecrit] IETF95 ECRIT draft agenda posted X-BeenThere: ecrit@ietf.org 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, 21 Mar 2016 23:19:47 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39840D82SEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT WG: Please take a look at and comment on the draft agenda. Anything to add or = subtract, or time allotment questions, please let the chairs know. https://www.ietf.org/proceedings/95/agenda/agenda-95-ecrit Emergency Context Resolution with Internet Technologies WG ECRIT Agenda - 1000-1230 Wednesday Morning Session I, April 6, 2016 IETF95= Buenos Aires Meeting Room: Quebracho A 10 min * Agenda Bashing, Draft Status Update (Chairs) 20 min * Data-Only Emergency Calls https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea-11/ 20 min * Validation of Locations Around a Planned Change https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-changes-03/ 20 min * A LoST extension to return complete and similar location info https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location-02/ 10 min * Discussion Roger Marshall Marc Linsner ECRIT Chairs NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and/or = controlled under U.S. export laws and regulations and may be restricted fro= m disclosure by applicable State and Federal law. Nothing in this email sha= ll create any legal binding agreement between the parties unless expressly = stated herein and provided by an authorized representative of Comtech Telec= ommunications Corp. or its subsidiaries. If you are not the intended recipi= ent of this message, be advised that any dissemination, distribution, or us= e of the contents of this message is strictly prohibited. If you received t= his message in error, please notify us immediately by return email and perm= anently delete all copies of the original email and any attached documentat= ion from any computer or other media. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39840D82SEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ECRIT WG:

 

Please take a look at and comment on the draft agend= a.  Anything to add or subtract, or time allotment questions, please l= et the chairs know.

https://www.ietf.org/proceedings/95/agenda/agenda-95-ecr= it

 

 

Emergency Context Resolution with Internet Technologies WG=

 

ECRIT Agenda - 1000-1230  Wednesday Morning Session I= , April 6, 2016 IETF95 Buenos Aires

Meeting Room: Quebracho A    

 

10 min * Agenda Bashing, Draft Status Update (Chairs)=

 

20 min * Data-Only Emergency Calls

https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-onl= y-ea-11/

 

20 min * Validation of Locations Around a Planned Change

https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-pl= anned-changes-03/

 

20 min * A LoST extension to return complete and similar l= ocation info

https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-= location-02/

 

10 min * Discussion

 

 

Roger Marshall

Marc Linsner

ECRIT Chairs

=0A

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

=0A=0A=0A --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39840D82SEAEXMB2telecom_-- From nobody Mon Mar 21 16:36:25 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 70F8A12D1AC for ; Mon, 21 Mar 2016 16:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321233624.10858.98065.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:36:24 -0700 From: IETF Secretariat Archived-At: Subject: [Ecrit] Milestones changed for ecrit WG 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: Mon, 21 Mar 2016 23:36:24 -0000 Deleted milestone "Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP". Changed milestone "Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC", set due date to March 2016 from October 2014, resolved as "Done". Changed milestone "Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC", set due date to March 2016 from October 2014. Changed milestone "Submit ‘Internet Protocol-based In-Vehicle Emergency Calls‘ to the IESG for consideration as an Informational RFC", set due date to March 2016 from March 2015. Changed milestone "Submit ‘Next-Generation Pan-European eCall‘ to the IESG for consideration as an Informational RFC", set due date to March 2016 from March 2015. Changed milestone "Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC", set due date to March 2016 from March 2015. Changed milestone "Submit 'A Routing Request Extension for the HELD Protocol' to the IESG for consideration as a Standards Track RFC", set due date to March 2016 from September 2015. URL: https://datatracker.ietf.org/wg/ecrit/charter/ From nobody Mon Mar 21 17:06: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 A870112D1BF for ; Mon, 21 Mar 2016 17:06:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 spHmiyetpVjA for ; Mon, 21 Mar 2016 17:06:04 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ACD2312D17F for ; Mon, 21 Mar 2016 17:06:04 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 21 Mar 2016 17:06:03 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <56F04C03.4010105@gmx.net> References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> <56F04C03.4010105@gmx.net> X-Mailer: Eudora for Mac OS X Date: Mon, 21 Mar 2016 17:05:59 -0700 To: Hannes Tschofenig , Dan Banks , James Winterbottom , 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 00:06:06 -0000 So, I think we have three remaining open questions, which are: Should we go with -38 as it is (new namespace and schema normative) or (1) Revert namespace to original name? (2) Revert schema to informative? (3) Do we add to the schema "x-" and "vnd-" tokens as well as IANA tokens? At 8:31 PM +0100 3/21/16, Hannes Tschofenig wrote: > Hi Dan, > > the situation looks a bit tricky. > > It seems that accepting the errata wasn't quite the right thing since it > changes an XML schema without defining a new namespace and without > registering the new schema. > > In some sense, we could be equally "relaxed" and just change their > schema again (without changing the namespace). > > I believe it ultimately boils down to the question what the value of the > XML schema actually is. > > I see a couple of different usages: > > a) If someone uses the XML schema to generate code then anything other > than defining our own, corrected XML schema will lead to problems > > b) If the XML schema is only used by an implementer to validate instance > documents than defining our own, corrected XML schema will also be needed. > > c) If the XML schema is, however, only used as a different way of > reading the document content then changing the schema within the text > (as we had done up to version -37) is fine. > > I personally think that most developers don't do (a) and (b) and that's > why most of the XML schemas in technical specifications are actually > broken (not only in the IETF but also elsewhere). The "most developers" > is important here since we have found developers, such as Philip, who > actually produce code based on the schema (which is why he found problems). > > However, by making these types of "fixes" we are obviously not going to > improve the situation. It is also the question what the IESG and the > area directors think about this situation. In some sense it is not only > about the use of XML schemas but the issue is a bit more broadly related > to the use of formal languages in the IETF in general. There are many > other places where we messed things up, such as with ABNF. > > Ultimately, it fear it will boil down to a different question, namely: > What does it mean if the VCard schema in our spec is different from the > original VCard schema in terms of re-use with existing software. > > Ciao > Hannes > > > On 03/21/2016 05:20 PM, Dan Banks wrote: >> I'm not entirely sure this is the right way to go. >> >> First, if the values can only come from the registry, that still >> excludes the x-name values (which seems to me to be nearly as big of >> an omission as leaving out the iana-token values). >> >> Second, is changing the namespace really necessary? Perhaps I don't >> understand the errata process correctly, but James' argument that the >> RFC 6351 schema error requires it does not seem persuasive to me in >> light of the existing errata already being verified status (as >> opposed to held for update). That suggests to me that any RFC 6351 >> implementation should take this errata into account. >> >> Changing the namespace also brings new complications: the xCards will >> not be interoperable with an RFC 6351 implementation (even one that >> considers the errata), and the Appendix A schema would have to be >> normative. This essentially redefines the entire xCard schema with >> an XML schema when the previous version was a Relax NG schema. This >> doesn't seem like a good idea to me. >> >> Dan Banks >> >> -----Original Message----- From: Hannes Tschofenig >> [mailto:hannes.tschofenig@gmx.net] Sent: Sunday, March 20, 2016 9:09 >> AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew >> Newton; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data Draft >> (again) >> >> Hi Randy, Hi James, >> >> the proposal makes sense to me an I have been working on an update to > > reflect these changes. >> >> Here is the link to the work in progress document: >> >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-38.txt >> >> Ciao Hannes >> >> On 03/19/2016 12:20 AM, Randall Gellens wrote: >>> Thanks for listing the steps, James. >>> >>> Hannes, does this sound like the plan to you? >>> >>> Brian, do you concur? >>> >>> Thanks everyone. >>> >>> At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >>> >>>> So, just make sure I am clear on what the plan is: 1) Remove the >>>> enumeration for the schema so all values now come from the >>>> registry only 2) Add main number to the registry 3) Change the >>>> namespace 4) Update all examples to use the new namespace 5) >>>> register the namespace and schema with IANA >>>> >>>> Cheers James >>>> >>>> >>>> >>>>> On 19 Mar 2016, at 8:51 am, Randall Gellens >>>>> wrote: >>>>> >>>>> I'm OK with changing the namespace if we need to. >>>>> >>>>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>>>> >>>>>> I think that the general approach is okay, I remain >>>>>> unconvinced that we don't need a new namespace however, >>>>>> because the schema in RFC 6351 is normative and it has an >>>>>> error and our solution requires the error be corrected. >>>>>> >>>>>> Cheers James >>>>>> >>>>>> >>>>>> >>>>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens >>>>>>> wrote: >>>>>>> >>>>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>>>> >>>>>>>> I am not very familiar with the process around updating >>>>>>>> documents, but to me this suggests: - we should not need >>>>>>>> to do an update to RFC 6351, - we should fix the >>>>>>>> informative schema in the additional data document to >>>>>>>> take into account the verified errata (there are >>>>>>>> several), - we should seek review of "main-number" as an >>>>>>>> addition to the registry, and update the additional data >>>>>>>> draft to formally make that addition. >>>>>>> >>>>>>> This sounds reasonable to me. We also won't need to change >>>>>>> the namespace. >>>>>>> >>>>>>> -- Randall Gellens Opinions are personal; facts are >>>>>>> suspect; I speak for myself only -------------- Randomly >>>>>>> selected tag: --------------- A list is only as strong as >>>>>>> its weakest link. --Donald Knuth >>>>> >>>>> >>>>> -- Randall Gellens Opinions are personal; facts are suspect; >>>>> I speak for myself only -------------- Randomly selected tag: >>>>> --------------- 640K ought to be enough for anybody. --Bill >>>>> Gates, 1981 >>> >>> >> > > > > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > Attachment converted: TiLand:signature 1702.asc ( / ) (0331F6EF) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Military justice is to justice what military music is to music. From nobody Mon Mar 21 20:26: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 0DC3D12D646 for ; Mon, 21 Mar 2016 20:26:34 -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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 IoH_WI5Uh-m1 for ; Mon, 21 Mar 2016 20:26:31 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3E812D109 for ; Mon, 21 Mar 2016 20:26:31 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 21 Mar 2016 20:26:30 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 21 Mar 2016 20:26:28 -0700 To: Roger Marshall , Emergency Context Resolution with Internet Technologies Discussion List 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: Ben Campbell , Marc Linsner Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 03:26:34 -0000 Hi Roger, One suggested very minor tweak in the wording: change "is not scheduled to" to "may not". At 9:35 PM +0000 3/21/16, Roger Marshall wrote: > Proposed Liaison response: > > The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 > for their response, TDoc C1-160764, referencing LS (C1-152644) on > the topic of NG eCall support for the EU. > > The ECRIT working group discussed your liaison as it applies to the > IETF draft-ietf-ecrit-ecall document and reached the following > conclusions: Given that 3GPP is not scheduled to finish their > stage-3 work for eCall in IMS until June 2017, as part of Release > 14, we will continue progressing these drafts to IETF last call as > currently scheduled. > > We also acknowledge that during 3GPP's development phase, some > differences may occur between that which is outlined within the > existing draft-ietf-ecrit-ecall and that which emerges from the > 3GPP work. The IETF process allows for RFCs to be revised in the > event of changes in technology. > > We'll collect wg member comments over the next few days and will > then move to send out the official response to 3GPP. > > > Roger Marshall > Roger.marshall@comtechtel.com > Marc Linsner > mlinsner@cisco.com > ECRIT Chairs > > > -----Original Message----- > From: Roger Marshall > Sent: Monday, March 21, 2016 1:24 PM > To: Emergency Context Resolution with Internet Technologies Discussion List > Cc: Marc Linsner; Alissa Cooper; Ben Campbell > Subject: RE: New Liaison Statement, "Response to LS on NG eCall > support for the EU" > > ECRIT WG: > > The chairs have reviewed the thread concerning processing > draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well > as the most recent liaison received from 3GPP on 1/31/2016 and > discussed with the authors. Given that 3GPP is not scheduled to > finish their work until June 2017, we will continue progressing > these drafts to IETF last call as scheduled. We also remind the > working group that the IETF process allows changes to RFC > publications, e.g., issuance of bis RFCs in the event that changes > in technology result in the need to make such a change. Such > documents would be in scope of the current ECRIT charter, should > the need arise. > > We will send a reply liaison statement to 3GPP to inform them of > the status of the documents after we post the proposed liaison text > to the list, which will happen shortly. > > > Roger Marshall (roger.marshall@comtechtel.com) & > Marc Linsner (mlinsner@cisco.com) > Ecrit chairs > > > > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > Sent: Sunday, January 31, 2016 4:13 PM > To: Roger Marshall; Marc Linsner > Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with > Internet Technologies Discussion List; georg.mayer.huawei@gmx.com; > 3GPPLiaison@etsi.org; Roger Marshall; Alissa Cooper; Ben Campbell > Subject: New Liaison Statement, "Response to LS on NG eCall support > for the EU" > > Title: Response to LS on NG eCall support for the EU Submission > Date: 2016-01-31 URL of the IETF Web page: > https://datatracker.ietf.org/liaison/1452/ > > From: "Susanna Kooistra" <3GPPLiaison@etsi.org> > To: Marc Linsner , Roger Marshall > > Cc: Barry Leiba ,Marc Linsner > ,Ben Campbell ,Alissa > Cooper ,Roger Marshall > ,Emergency Context Resolution with > Internet Technologies Discussion List , Response > Contacts: georg.mayer.huawei@gmx.com, 3GPPLiaison@etsi.org > Technical Contacts: > Purpose: In response > > Referenced liaison: Liaison Statement on NG eCall support for the > EU (https://datatracker.ietf.org/liaison/1412/) > > Body: 1. Overall description > 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS > (C1-152644) on NG eCall support for the EU. > 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG CT > WG1 will work on stage-3 for eCall in IMS in Release 14 (ending in > June 2017), subject to 3GPP TSG SA WG2 completion of the normative > stage-2 work and approval of a 3GPP TSG CT work item. > 3GPP TSG CT WG1 stage-3 work might result in protocol requirements > deviating or conflicting with the current version of IETF > draft-ietf-ecrit-ecall, and thus might impact IETF work. > > 2. Actions > To IETF Ecrit WG > ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take the > above into consideration. > > 3. Dates of next TSG CT WG1 meetings > TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea > TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia > > > Attachments: > > Response to LS on NG eCall support for the EU > > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp-tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.pdf > > > NOTICE TO RECIPIENT: This email, including attachments, may contain > information which is confidential, proprietary, attorney-client > privileged and/or controlled under U.S. export laws and regulations > and may be restricted from disclosure by applicable State and > Federal law. Nothing in this email shall create any legal binding > agreement between the parties unless expressly stated herein and > provided by an authorized representative of Comtech > Telecommunications Corp. or its subsidiaries. If you are not the > intended recipient of this message, be advised that any > dissemination, distribution, or use of the contents of this message > is strictly prohibited. If you received this message in error, > please notify us immediately by return email and permanently delete > all copies of the original email and any attached documentation > from any computer or other media. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The men sat sipping their tea in silence. After a while the klutz said, "Life is like a bowl of sour cream." "Like a bowl of sour cream?" asked the other. "Why?" "How should I know? What am I, a philosopher?" From nobody Tue Mar 22 01:46: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 090DE12D7FB for ; Tue, 22 Mar 2016 01:46: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 PP3-jp2ZCHSV for ; Tue, 22 Mar 2016 01:46:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D511712D7EC for ; Tue, 22 Mar 2016 01:46:19 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-58-56f10659c323 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 74.45.22880.95601F65; Tue, 22 Mar 2016 09:46:18 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.201]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 22 Mar 2016 09:45:23 +0100 From: Ivo Sedlacek To: Randall Gellens , Roger Marshall , "Emergency Context Resolution with Internet Technologies Discussion List" Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRg7nLe8dcjY6zo0iz9xnDGcDJmJ9kvQYAgABnENA= Date: Tue, 22 Mar 2016 08:45:23 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011635B032@ESESSMB301.ericsson.se> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7vW4U28cwg3c/OC3md55mt2hc9JTV YsOpbywW3593MVos/PWLxYHVY8rvjawel7a0snssWfKTyWPWzicsHlvvPGYJYI3isklJzcks Sy3St0vgyvh96SRzwUrbijerVzE3MP407GLk5JAQMJE41NrHCGGLSVy4t56ti5GLQ0jgMKPE 1v7JUM4SRolDV1uYQKrYBPQkJm45wgqSEBHYzyixcvYyNpAEs4CnxI0zp1m6GDk4hAViJXq/ OIOERQTiJJp/fGSHsK0kFn3+xghSwiKgKvFsrhZImFfAV+LO212sELs2MUq8WzQLbCQn0HX7 /reB2YwCshJX//QyQqwSl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0pcnb6cCaJeR2LB7k9Q Z2pLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfdyFgvtSgzubg4 P08vL7VkEyMw+g5u+a27g3H1a8dDjAIcjEo8vAZbP4QJsSaWFVfmHmKU4GBWEuFd+hUoxJuS WFmVWpQfX1Sak1p8iFGag0VJnJft0+UwIYH0xJLU7NTUgtQimCwTB6dUA+O6L4bLd7M8vPh3 P/87bg7+qyZbUzZ/Wbla+Un9jgn7i2+Vlx42+6AqVGI6e/fOGLV7IilmjGEc0o7m5395pXsZ rpfdOKfCP1laqsnh1e9aZZNJxbw1/6YUWbDFrY4OCPqq8miniVnRel+xjZ5OccKxD1M9jzMm 6pd92a/ZK//0UsP2t89tLJVYijMSDbWYi4oTARYuBYC6AgAA Archived-At: Cc: Ben Campbell , Marc Linsner Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 08:46:23 -0000 Hello, "Given that 3GPP is not scheduled to finish their stage-3 work for eCall in= IMS until June 2017, as part of Release 14" is based on obsolete informati= on. Be aware that 3GPP CT approved a work item on "CT aspects of evolution to a= nd interworking with eCall in IMS" (WID: http://www.3gpp.org/ftp/tsg_ct/TSG= _CT/TSGC_71_Goteborg/Docs/CP-160053.zip). This includes CT1 work. This work item is scheduled to be completed in September 2016 - see section= 10 of the WID. June 2017 is the final end of 3GPP Release 14, however some of the work ite= ms will be finalized long before that. Kind regards Ivo Sedlacek -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: Tuesday, March 22, 2016 4:26 AM To: Roger Marshall; Emergency Context Resolution with Internet Technologies= Discussion List Cc: Ben Campbell; Marc Linsner Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall sup= port for the EU" Hi Roger, One suggested very minor tweak in the wording: change "is not scheduled to"= to "may not". At 9:35 PM +0000 3/21/16, Roger Marshall wrote: > Proposed Liaison response: > > The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 for=20 > their response, TDoc C1-160764, referencing LS (C1-152644) on the=20 > topic of NG eCall support for the EU. > > The ECRIT working group discussed your liaison as it applies to the=20 > IETF draft-ietf-ecrit-ecall document and reached the following > conclusions: Given that 3GPP is not scheduled to finish their > stage-3 work for eCall in IMS until June 2017, as part of Release 14,=20 > we will continue progressing these drafts to IETF last call as=20 > currently scheduled. > > We also acknowledge that during 3GPP's development phase, some=20 > differences may occur between that which is outlined within the=20 > existing draft-ietf-ecrit-ecall and that which emerges from the 3GPP=20 > work. The IETF process allows for RFCs to be revised in the event of=20 > changes in technology. > > We'll collect wg member comments over the next few days and will then=20 > move to send out the official response to 3GPP. > > > Roger Marshall > Roger.marshall@comtechtel.com > Marc Linsner > mlinsner@cisco.com > ECRIT Chairs > > > -----Original Message----- > From: Roger Marshall > Sent: Monday, March 21, 2016 1:24 PM > To: Emergency Context Resolution with Internet Technologies=20 > Discussion List > Cc: Marc Linsner; Alissa Cooper; Ben Campbell > Subject: RE: New Liaison Statement, "Response to LS on NG eCall=20 > support for the EU" > > ECRIT WG: > > The chairs have reviewed the thread concerning processing > draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well as=20 > the most recent liaison received from 3GPP on 1/31/2016 and discussed=20 > with the authors. Given that 3GPP is not scheduled to finish their=20 > work until June 2017, we will continue progressing these drafts to=20 > IETF last call as scheduled. We also remind the working group that the=20 > IETF process allows changes to RFC publications, e.g., issuance of bis=20 > RFCs in the event that changes in technology result in the need to=20 > make such a change. Such documents would be in scope of the current=20 > ECRIT charter, should the need arise. > > We will send a reply liaison statement to 3GPP to inform them of the=20 > status of the documents after we post the proposed liaison text to the=20 > list, which will happen shortly. > > > Roger Marshall (roger.marshall@comtechtel.com) & Marc Linsner=20 > (mlinsner@cisco.com) Ecrit chairs > > > > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > Sent: Sunday, January 31, 2016 4:13 PM > To: Roger Marshall; Marc Linsner > Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with=20 > Internet Technologies Discussion List; georg.mayer.huawei@gmx.com;=20 > 3GPPLiaison@etsi.org; Roger Marshall; Alissa Cooper; Ben Campbell > Subject: New Liaison Statement, "Response to LS on NG eCall support=20 > for the EU" > > Title: Response to LS on NG eCall support for the EU Submission > Date: 2016-01-31 URL of the IETF Web page:=20 > https://datatracker.ietf.org/liaison/1452/ > > From: "Susanna Kooistra" <3GPPLiaison@etsi.org> > To: Marc Linsner , Roger Marshall=20 > > Cc: Barry Leiba ,Marc Linsner=20 > ,Ben Campbell ,Alissa Cooper=20 > ,Roger Marshall=20 > ,Emergency Context Resolution with Internet=20 > Technologies Discussion List , Response > Contacts: georg.mayer.huawei@gmx.com, 3GPPLiaison@etsi.org Technical=20 > Contacts: > Purpose: In response > > Referenced liaison: Liaison Statement on NG eCall support for the EU=20 > (https://datatracker.ietf.org/liaison/1412/) > > Body: 1. Overall description > 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS > (C1-152644) on NG eCall support for the EU. > 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG CT > WG1 will work on stage-3 for eCall in IMS in Release 14 (ending in=20 > June 2017), subject to 3GPP TSG SA WG2 completion of the normative > stage-2 work and approval of a 3GPP TSG CT work item. > 3GPP TSG CT WG1 stage-3 work might result in protocol requirements=20 > deviating or conflicting with the current version of IETF=20 > draft-ietf-ecrit-ecall, and thus might impact IETF work. > > 2. Actions > To IETF Ecrit WG > ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take the=20 > above into consideration. > > 3. Dates of next TSG CT WG1 meetings > TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea > TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia > > > Attachments: > > Response to LS on NG eCall support for the EU >=20 > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp- > tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachme > nt-1.pdf > > > NOTICE TO RECIPIENT: This email, including attachments, may contain=20 > information which is confidential, proprietary, attorney-client=20 > privileged and/or controlled under U.S. export laws and regulations=20 > and may be restricted from disclosure by applicable State and Federal=20 > law. Nothing in this email shall create any legal binding agreement=20 > between the parties unless expressly stated herein and provided by an=20 > authorized representative of Comtech Telecommunications Corp. or its=20 > subsidiaries. If you are not the intended recipient of this message,=20 > be advised that any dissemination, distribution, or use of the=20 > contents of this message is strictly prohibited. If you received this=20 > message in error, please notify us immediately by return email and=20 > permanently delete all copies of the original email and any attached=20 > documentation from any computer or other media. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The men sat sipping t= heir tea in silence. After a while the klutz said, "Life is like a bowl of= sour cream." "Like a bowl of sour cream?" asked the other. "Why?" "How should I know? What am I, a philosopher?" _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Mar 22 11:21: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 E7D3C12D55D for ; Tue, 22 Mar 2016 11:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 aplXlIIxWUis for ; Tue, 22 Mar 2016 11:21:44 -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 1A99B12D0EC for ; Tue, 22 Mar 2016 11:21:44 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.11/8.16.0.11) with SMTP id u2MIHRb9003835; Tue, 22 Mar 2016 14:21:35 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 21uah684f6-17 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Mar 2016 14:21:33 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.230]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 22 Mar 2016 14:16:42 -0400 From: "Rosen, Brian" To: Roger Marshall Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRhGb70Rb+PtmEC06hszQ+d6ZMuA== Date: Tue, 22 Mar 2016 18:16:41 +0000 Message-ID: <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.154.7.39] Content-Type: text/plain; charset="utf-8" Content-ID: <9EC579FC50F01448A22D895921968288@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-22_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 18:21:50 -0000 Q2FuIEkgc3VnZ2VzdCBhIHJld29yZCBvZiB0aGUgM3JkIHBhcmFncmFwaC4NCg0K4oCcSWYgM0dQ UCBmaW5kcyBpdCBuZWNlc3NhcnkgdG8gaW50cm9kdWNlIGFuIGluY29tcGF0aWJpbGl0eSBiZXR3 ZWVuIHRoaXMgZG9jdW1lbnQsIGFzIGZpbmFsbHkgcHVibGlzaGVkLCBhbmQgaXRzIHdvcmssIHdl IHJlcXVlc3QgdGhhdCB5b3UgaW5mb3JtIHVzIG9mIHN1Y2ggYW4gaXNzdWUgc28gdGhhdCB3ZSBj YW4gZXZhbHVhdGUgaXRzIGVmZmVjdCBvbiBvdXIgZG9jdW1lbnQgYW5kIGNvbnNpZGVyIGFueSBy ZXZpc2lvbnMgdGhhdCBtYXkgYmUgbmVlZGVkLCBmb2xsb3dpbmcgbm9ybWFsIElFVEYgcHJvY2Vz c2VzLuKAnQ0KDQpCcmlhbg0KDQo+IE9uIE1hciAyMSwgMjAxNiwgYXQgNTozNSBQTSwgUm9nZXIg TWFyc2hhbGwgPFJvZ2VyLk1hcnNoYWxsQGNvbXRlY2h0ZWwuY29tPiB3cm90ZToNCj4gDQo+IFBy b3Bvc2VkIExpYWlzb24gcmVzcG9uc2U6DQo+IA0KPiBUaGUgSUVURiBFQ1JJVCB3b3JraW5nIGdy b3VwIHdvdWxkIGxpa2UgdG8gdGhhbmsgM0dQUCBUU0cgQ1QgV0cxIGZvciB0aGVpciByZXNwb25z ZSwgVERvYyBDMS0xNjA3NjQsIHJlZmVyZW5jaW5nIExTIChDMS0xNTI2NDQpIG9uIHRoZSB0b3Bp YyBvZiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUuICANCj4gDQo+IFRoZSBFQ1JJVCB3b3Jr aW5nIGdyb3VwIGRpc2N1c3NlZCB5b3VyIGxpYWlzb24gYXMgaXQgYXBwbGllcyB0byB0aGUgSUVU RiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsIGRvY3VtZW50IGFuZCByZWFjaGVkIHRoZSBmb2xsb3dp bmcgY29uY2x1c2lvbnM6ICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90IHNjaGVkdWxlZCB0byBmaW5p c2ggdGhlaXIgc3RhZ2UtMyB3b3JrIGZvciBlQ2FsbCBpbiBJTVMgdW50aWwgSnVuZSAyMDE3LCBh cyBwYXJ0IG9mIFJlbGVhc2UgMTQsIHdlIHdpbGwgY29udGludWUgcHJvZ3Jlc3NpbmcgdGhlc2Ug ZHJhZnRzIHRvIElFVEYgbGFzdCBjYWxsIGFzIGN1cnJlbnRseSBzY2hlZHVsZWQuDQo+IA0KPiBX ZSBhbHNvIGFja25vd2xlZGdlIHRoYXQgZHVyaW5nIDNHUFAncyBkZXZlbG9wbWVudCBwaGFzZSwg c29tZSBkaWZmZXJlbmNlcyBtYXkgb2NjdXIgYmV0d2VlbiB0aGF0IHdoaWNoIGlzIG91dGxpbmVk IHdpdGhpbiB0aGUgZXhpc3RpbmcgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCBhbmQgdGhhdCB3aGlj aCBlbWVyZ2VzIGZyb20gdGhlIDNHUFAgd29yay4gVGhlIElFVEYgcHJvY2VzcyBhbGxvd3MgZm9y IFJGQ3MgdG8gYmUgcmV2aXNlZCBpbiB0aGUgZXZlbnQgb2YgY2hhbmdlcyBpbiB0ZWNobm9sb2d5 Lg0KPiANCj4gV2UnbGwgY29sbGVjdCB3ZyBtZW1iZXIgY29tbWVudHMgb3ZlciB0aGUgbmV4dCBm ZXcgZGF5cyBhbmQgd2lsbCB0aGVuIG1vdmUgdG8gc2VuZCBvdXQgdGhlIG9mZmljaWFsIHJlc3Bv bnNlIHRvIDNHUFAuDQo+IA0KPiANCj4gUm9nZXIgTWFyc2hhbGwNCj4gUm9nZXIubWFyc2hhbGxA Y29tdGVjaHRlbC5jb20NCj4gTWFyYyBMaW5zbmVyDQo+IG1saW5zbmVyQGNpc2NvLmNvbQ0KPiBF Q1JJVCBDaGFpcnMNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBSb2dlciBNYXJzaGFsbCANCj4gU2VudDogTW9uZGF5LCBNYXJjaCAyMSwgMjAxNiAxOjI0IFBN DQo+IFRvOiBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5v bG9naWVzIERpc2N1c3Npb24gTGlzdA0KPiBDYzogTWFyYyBMaW5zbmVyOyBBbGlzc2EgQ29vcGVy OyBCZW4gQ2FtcGJlbGwNCj4gU3ViamVjdDogUkU6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIlJl c3BvbnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSINCj4gDQo+IEVDUklU IFdHOg0KPiANCj4gVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSB0aHJlYWQgY29uY2Vybmlu ZyBwcm9jZXNzaW5nIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMDUgYW5kIGRyYWZ0LWlldGYtZWNy aXQtY2FyLWNyYXNoLTA1IGFzIHdlbGwgYXMgdGhlIG1vc3QgcmVjZW50IGxpYWlzb24gcmVjZWl2 ZWQgZnJvbSAzR1BQIG9uIDEvMzEvMjAxNiBhbmQgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhvcnMu ICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90IHNjaGVkdWxlZCB0byBmaW5pc2ggdGhlaXIgd29yayB1 bnRpbCBKdW5lIDIwMTcsIHdlIHdpbGwgY29udGludWUgcHJvZ3Jlc3NpbmcgdGhlc2UgZHJhZnRz IHRvIElFVEYgbGFzdCBjYWxsIGFzIHNjaGVkdWxlZC4gV2UgYWxzbyByZW1pbmQgdGhlIHdvcmtp bmcgZ3JvdXAgdGhhdCB0aGUgSUVURiBwcm9jZXNzIGFsbG93cyBjaGFuZ2VzIHRvIFJGQyBwdWJs aWNhdGlvbnMsIGUuZy4sIGlzc3VhbmNlIG9mIGJpcyBSRkNzIGluIHRoZSBldmVudCB0aGF0IGNo YW5nZXMgaW4gdGVjaG5vbG9neSByZXN1bHQgaW4gdGhlIG5lZWQgdG8gbWFrZSBzdWNoIGEgY2hh bmdlLiAgU3VjaCBkb2N1bWVudHMgd291bGQgYmUgaW4gc2NvcGUgb2YgdGhlIGN1cnJlbnQgRUNS SVQgY2hhcnRlciwgc2hvdWxkIHRoZSBuZWVkIGFyaXNlLiANCj4gDQo+IFdlIHdpbGwgc2VuZCBh IHJlcGx5IGxpYWlzb24gc3RhdGVtZW50IHRvIDNHUFAgdG8gaW5mb3JtIHRoZW0gb2YgdGhlIHN0 YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGFmdGVyIHdlIHBvc3QgdGhlIHByb3Bvc2VkIGxpYWlzb24g dGV4dCB0byB0aGUgbGlzdCwgd2hpY2ggd2lsbCBoYXBwZW4gc2hvcnRseS4NCj4gDQo+IA0KPiBS b2dlciBNYXJzaGFsbCAocm9nZXIubWFyc2hhbGxAY29tdGVjaHRlbC5jb20pICAmDQo+IE1hcmMg TGluc25lciAobWxpbnNuZXJAY2lzY28uY29tKQ0KPiBFY3JpdCBjaGFpcnMNCj4gDQo+IA0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGlhaXNvbiBTdGF0ZW1lbnQg TWFuYWdlbWVudCBUb29sIFttYWlsdG86bHNtdEBpZXRmLm9yZ10gDQo+IFNlbnQ6IFN1bmRheSwg SmFudWFyeSAzMSwgMjAxNiA0OjEzIFBNDQo+IFRvOiBSb2dlciBNYXJzaGFsbDsgTWFyYyBMaW5z bmVyDQo+IENjOiBCYXJyeSBMZWliYTsgTWFyYyBMaW5zbmVyOyBFbWVyZ2VuY3kgQ29udGV4dCBS ZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24gTGlzdDsgZ2Vv cmcubWF5ZXIuaHVhd2VpQGdteC5jb207IDNHUFBMaWFpc29uQGV0c2kub3JnOyBSb2dlciBNYXJz aGFsbDsgQWxpc3NhIENvb3BlcjsgQmVuIENhbXBiZWxsDQo+IFN1YmplY3Q6IE5ldyBMaWFpc29u IFN0YXRlbWVudCwgIlJlc3BvbnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBF VSINCj4gDQo+IFRpdGxlOiBSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0 aGUgRVUgU3VibWlzc2lvbiBEYXRlOiAyMDE2LTAxLTMxIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFn ZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTIvDQo+IA0KPiBGcm9t OiAiU3VzYW5uYSBLb29pc3RyYSIgPDNHUFBMaWFpc29uQGV0c2kub3JnPg0KPiBUbzogTWFyYyBM aW5zbmVyIDxtYXJjLmxpbnNuZXJAY2lzY28uY29tPiwgUm9nZXIgTWFyc2hhbGwgPHJtYXJzaGFs bEB0ZWxlY29tc3lzLmNvbT4NCj4gQ2M6IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZz4sTWFyYyBMaW5zbmVyIDxtYXJjLmxpbnNuZXJAY2lzY28uY29tPixCZW4gQ2FtcGJlbGwg PGJlbkBub3N0cnVtLmNvbT4sQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+LFJvZ2Vy IE1hcnNoYWxsIDxybWFyc2hhbGxAdGVsZWNvbXN5cy5jb20+LEVtZXJnZW5jeSBDb250ZXh0IFJl c29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0IDxlY3Jp dEBpZXRmLm9yZz4sIFJlc3BvbnNlIENvbnRhY3RzOiBnZW9yZy5tYXllci5odWF3ZWlAZ214LmNv bSwgM0dQUExpYWlzb25AZXRzaS5vcmcgVGVjaG5pY2FsIENvbnRhY3RzOiANCj4gUHVycG9zZTog SW4gcmVzcG9uc2UNCj4gDQo+IFJlZmVyZW5jZWQgbGlhaXNvbjogTGlhaXNvbiBTdGF0ZW1lbnQg b24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIChodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2xpYWlzb24vMTQxMi8pDQo+IA0KPiBCb2R5OiAxLiBPdmVyYWxsIGRlc2NyaXB0aW9uDQo+ IDNHUFAgVFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIHRoYW5rIElFVEYgRWNyaXQgV0cgZm9yIHRo ZSBMUyAoQzEtMTUyNjQ0KSBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUuDQo+IDNHUFAg VFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIGluZm9ybSBJRVRGIEVjcml0IFdHIHRoYXQgM0dQUCBU U0cgQ1QgV0cxIHdpbGwgd29yayBvbiBzdGFnZS0zIGZvciBlQ2FsbCBpbiBJTVMgaW4gUmVsZWFz ZSAxNCAoZW5kaW5nIGluIEp1bmUgMjAxNyksIHN1YmplY3QgdG8gM0dQUCBUU0cgU0EgV0cyIGNv bXBsZXRpb24gb2YgdGhlIG5vcm1hdGl2ZSBzdGFnZS0yIHdvcmsgYW5kIGFwcHJvdmFsIG9mIGEg M0dQUCBUU0cgQ1Qgd29yayBpdGVtLg0KPiAzR1BQIFRTRyBDVCBXRzEgc3RhZ2UtMyB3b3JrIG1p Z2h0IHJlc3VsdCBpbiBwcm90b2NvbCByZXF1aXJlbWVudHMgZGV2aWF0aW5nIG9yIGNvbmZsaWN0 aW5nIHdpdGggdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBJRVRGIGRyYWZ0LWlldGYtZWNyaXQtZWNh bGwsIGFuZCB0aHVzIG1pZ2h0IGltcGFjdCBJRVRGIHdvcmsuIA0KPiANCj4gMi4gQWN0aW9ucw0K PiBUbyBJRVRGIEVjcml0IFdHDQo+IEFDVElPTjogM0dQUCBUU0cgQ1QgV0cxIHJlc3BlY3RmdWxs eSBhc2tzIElFVEYgRWNyaXQgV0cgdG8gdGFrZSB0aGUgYWJvdmUgaW50byBjb25zaWRlcmF0aW9u Lg0KPiANCj4gMy4gRGF0ZXMgb2YgbmV4dCBUU0cgQ1QgV0cxIG1lZXRpbmdzDQo+IFRTRyBDVCBX RzEgTWVldGluZyA5NgkxNS0xOSBGZWJydWFyeSAyMDE2CUplanUgSXNsYW5kLCBLb3JlYQ0KPiBU U0cgQ1QgV0cxIE1lZXRpbmcgOTcJMTEtMTUgQXByaWwgMjAxNglManVibGphbmEsIFNsb3Zlbmlh DQo+IA0KPiANCj4gQXR0YWNobWVudHM6DQo+IA0KPiAgICBSZXNwb25zZSB0byBMUyBvbiBORyBl Q2FsbCBzdXBwb3J0IGZvciB0aGUgRVUNCj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0 L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNi0wMS0zMS0zZ3BwLXRzZ2N0LWN0MS1lY3Jp dC1yZXNwb25zZS10by1scy1vbi1uZy1lY2FsbC1zdXBwb3J0LWZvci10aGUtZXUtYXR0YWNobWVu dC0xLnBkZg0KPiANCj4gDQo+IE5PVElDRSBUTyBSRUNJUElFTlQ6IFRoaXMgZW1haWwsIGluY2x1 ZGluZyBhdHRhY2htZW50cywgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gd2hpY2ggaXMgY29uZmlk ZW50aWFsLCBwcm9wcmlldGFyeSwgYXR0b3JuZXktY2xpZW50IHByaXZpbGVnZWQgYW5kL29yIGNv bnRyb2xsZWQgdW5kZXIgVS5TLiBleHBvcnQgbGF3cyBhbmQgcmVndWxhdGlvbnMgYW5kIG1heSBi ZSByZXN0cmljdGVkIGZyb20gZGlzY2xvc3VyZSBieSBhcHBsaWNhYmxlIFN0YXRlIGFuZCBGZWRl cmFsIGxhdy4gTm90aGluZyBpbiB0aGlzIGVtYWlsIHNoYWxsIGNyZWF0ZSBhbnkgbGVnYWwgYmlu ZGluZyBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgcGFydGllcyB1bmxlc3MgZXhwcmVzc2x5IHN0YXRl ZCBoZXJlaW4gYW5kIHByb3ZpZGVkIGJ5IGFuIGF1dGhvcml6ZWQgcmVwcmVzZW50YXRpdmUgb2Yg Q29tdGVjaCBUZWxlY29tbXVuaWNhdGlvbnMgQ29ycC4gb3IgaXRzIHN1YnNpZGlhcmllcy4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIG1lc3NhZ2UsIGJlIGFk dmlzZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciB1c2Ugb2YgdGhl IGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0 ZWx5IGJ5IHJldHVybiBlbWFpbCBhbmQgcGVybWFuZW50bHkgZGVsZXRlIGFsbCBjb3BpZXMgb2Yg dGhlIG9yaWdpbmFsIGVtYWlsIGFuZCBhbnkgYXR0YWNoZWQgZG9jdW1lbnRhdGlvbiBmcm9tIGFu eSBjb21wdXRlciBvciBvdGhlciBtZWRpYS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0K From nobody Tue Mar 22 12:41: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 5858B12D861 for ; Tue, 22 Mar 2016 12:41:18 -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, FREEMAIL_FROM=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=gmail.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 lXYvdWRL7scv for ; Tue, 22 Mar 2016 12:41:15 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 A40B312D88D for ; Tue, 22 Mar 2016 12:41:15 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id n5so323656536pfn.2 for ; Tue, 22 Mar 2016 12:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T+EEOMMKhc5pR0D5lxkKh9fVO1V2eq2y7acVN6XuxgM=; b=Nd1sCr0/td3wmlfvl93AN62hBWj/8TAN7JjqOdR4AbuSYrZUNFsbprIBqUUWNYbbpg ntwY38CIsG9LkdH1DNWZZ+Hg4Ck8fVhBNwgFjXScLvdUmnaGEdAkRMxlZvZ7S2Fw7z9T MqaADcqQoT2lDpxifLbAbwfL46FN4NE+LpX6XydTN5KfFblDLSA48c2154MJ6FhU4wM/ WfMuwoK3H9hHFBYB4WC1xajjepkqoqxEMmA3MYl4rVKicEt2m+Ivu+ZyP3LaCuU5NAFu IJuUS/HIAyxhFtI5KEBK51f3PhLtw+YB4aQNDvbKDVEzjl1NDBp0N3oVfRCsn+JNVc7O /gtg== 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=T+EEOMMKhc5pR0D5lxkKh9fVO1V2eq2y7acVN6XuxgM=; b=EpNnOUtH1siA4cbiLSUyone5Kc17bPn0QuxW7xk5JQmu0fbPPtwcbxpPkcnp5SY7vE cK8YUrFtzyVHBAPtranpi7wOYOG0M6MEfs5SChQjKhPERb9p33euL7sU3iiDQ7IQUGnb AJAfivorXs/2o/R6/0TmmimIBQf8mnO6rr8CCVIgLcrks0TiF6j4FwAVsyks5w4KJslV uIF3wCtRKkBUFZw5qe7chl+4YIpxT4DJxZfnh8HYiQFLsbZD4UmP+2d5g2UTleaN5944 AUpvhK2E4yMAmfSJT789LjLzoCYhPSJxI08wEcZZAFAvedFec3qH699eDSXvnfVK1O8I S7+A== X-Gm-Message-State: AD7BkJK/kCi8QY1ttrDwcsg8rpoNbIaLXeS/GVpQZVA+QFjGsfpyWcCoHuwT+r0Boy8POg== X-Received: by 10.98.18.71 with SMTP id a68mr56686146pfj.41.1458675675203; Tue, 22 Mar 2016 12:41:15 -0700 (PDT) Received: from [192.168.1.4] (203-158-52-225.dyn.iinet.net.au. [203.158.52.225]) by smtp.gmail.com with ESMTPSA id p74sm50190196pfa.11.2016.03.22.12.41.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 12:41:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> Date: Wed, 23 Mar 2016 06:41:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 19:41:18 -0000 That sounds a little provocative to me. > On 23 Mar 2016, at 5:16 am, Rosen, Brian = wrote: >=20 > Can I suggest a reword of the 3rd paragraph. >=20 > =E2=80=9CIf 3GPP finds it necessary to introduce an incompatibility = between this document, as finally published, and its work, we request = that you inform us of such an issue so that we can evaluate its effect = on our document and consider any revisions that may be needed, following = normal IETF processes.=E2=80=9D >=20 > Brian >=20 >> On Mar 21, 2016, at 5:35 PM, Roger Marshall = wrote: >>=20 >> Proposed Liaison response: >>=20 >> The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 for = their response, TDoc C1-160764, referencing LS (C1-152644) on the topic = of NG eCall support for the EU. =20 >>=20 >> The ECRIT working group discussed your liaison as it applies to the = IETF draft-ietf-ecrit-ecall document and reached the following = conclusions: Given that 3GPP is not scheduled to finish their stage-3 = work for eCall in IMS until June 2017, as part of Release 14, we will = continue progressing these drafts to IETF last call as currently = scheduled. >>=20 >> We also acknowledge that during 3GPP's development phase, some = differences may occur between that which is outlined within the existing = draft-ietf-ecrit-ecall and that which emerges from the 3GPP work. The = IETF process allows for RFCs to be revised in the event of changes in = technology. >>=20 >> We'll collect wg member comments over the next few days and will then = move to send out the official response to 3GPP. >>=20 >>=20 >> Roger Marshall >> Roger.marshall@comtechtel.com >> Marc Linsner >> mlinsner@cisco.com >> ECRIT Chairs >>=20 >>=20 >> -----Original Message----- >> From: Roger Marshall=20 >> Sent: Monday, March 21, 2016 1:24 PM >> To: Emergency Context Resolution with Internet Technologies = Discussion List >> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >> Subject: RE: New Liaison Statement, "Response to LS on NG eCall = support for the EU" >>=20 >> ECRIT WG: >>=20 >> The chairs have reviewed the thread concerning processing = draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well as = the most recent liaison received from 3GPP on 1/31/2016 and discussed = with the authors. Given that 3GPP is not scheduled to finish their work = until June 2017, we will continue progressing these drafts to IETF last = call as scheduled. We also remind the working group that the IETF = process allows changes to RFC publications, e.g., issuance of bis RFCs = in the event that changes in technology result in the need to make such = a change. Such documents would be in scope of the current ECRIT = charter, should the need arise.=20 >>=20 >> We will send a reply liaison statement to 3GPP to inform them of the = status of the documents after we post the proposed liaison text to the = list, which will happen shortly. >>=20 >>=20 >> Roger Marshall (roger.marshall@comtechtel.com) & >> Marc Linsner (mlinsner@cisco.com) >> Ecrit chairs >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 >> Sent: Sunday, January 31, 2016 4:13 PM >> To: Roger Marshall; Marc Linsner >> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with = Internet Technologies Discussion List; georg.mayer.huawei@gmx.com; = 3GPPLiaison@etsi.org; Roger Marshall; Alissa Cooper; Ben Campbell >> Subject: New Liaison Statement, "Response to LS on NG eCall support = for the EU" >>=20 >> Title: Response to LS on NG eCall support for the EU Submission Date: = 2016-01-31 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1452/ >>=20 >> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >> To: Marc Linsner , Roger Marshall = >> Cc: Barry Leiba ,Marc Linsner = ,Ben Campbell ,Alissa Cooper = ,Roger Marshall ,Emergency = Context Resolution with Internet Technologies Discussion List = , Response Contacts: georg.mayer.huawei@gmx.com, = 3GPPLiaison@etsi.org Technical Contacts:=20 >> Purpose: In response >>=20 >> Referenced liaison: Liaison Statement on NG eCall support for the EU = (https://datatracker.ietf.org/liaison/1412/) >>=20 >> Body: 1. Overall description >> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS = (C1-152644) on NG eCall support for the EU. >> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG CT = WG1 will work on stage-3 for eCall in IMS in Release 14 (ending in June = 2017), subject to 3GPP TSG SA WG2 completion of the normative stage-2 = work and approval of a 3GPP TSG CT work item. >> 3GPP TSG CT WG1 stage-3 work might result in protocol requirements = deviating or conflicting with the current version of IETF = draft-ietf-ecrit-ecall, and thus might impact IETF work.=20 >>=20 >> 2. Actions >> To IETF Ecrit WG >> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take the = above into consideration. >>=20 >> 3. Dates of next TSG CT WG1 meetings >> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, = Korea >> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, = Slovenia >>=20 >>=20 >> Attachments: >>=20 >> Response to LS on NG eCall support for the EU >> = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp-tsgc= t-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.pdf= >>=20 >>=20 >> NOTICE TO RECIPIENT: This email, including attachments, may contain = information which is confidential, proprietary, attorney-client = privileged and/or controlled under U.S. export laws and regulations and = may be restricted from disclosure by applicable State and Federal law. = Nothing in this email shall create any legal binding agreement between = the parties unless expressly stated herein and provided by an 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 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Mar 22 14:37: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 D367112DA43 for ; Tue, 22 Mar 2016 14:37: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: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Eu5ysj8zGpbX for ; Tue, 22 Mar 2016 14:37:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4CE12DA38 for ; Tue, 22 Mar 2016 14:37:25 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 22 Mar 2016 14:37:23 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Mar 2016 14:37:21 -0700 To: James Winterbottom , "Rosen, Brian" 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: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 21:37:30 -0000 I think James has a point, and Brian's suggested change isn't needed. At 6:41 AM +1100 3/23/16, James Winterbottom wrote: > That sounds a little provocative to me. > > >> On 23 Mar 2016, at 5:16 am, Rosen, Brian wrote: >> >> Can I suggest a reword of the 3rd paragraph. >> >> "If 3GPP finds it necessary to introduce an incompatibility >> between this document, as finally published, and its work, we >> request that you inform us of such an issue so that we can >> evaluate its effect on our document and consider any revisions >> that may be needed, following normal IETF processes." >> >> Brian >> >>> On Mar 21, 2016, at 5:35 PM, Roger Marshall >>> wrote: >>> >>> Proposed Liaison response: >>> >>> The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 >>> for their response, TDoc C1-160764, referencing LS (C1-152644) on >>> the topic of NG eCall support for the EU. >>> >>> The ECRIT working group discussed your liaison as it applies to >>> the IETF draft-ietf-ecrit-ecall document and reached the >>> following conclusions: Given that 3GPP is not scheduled to >>> finish their stage-3 work for eCall in IMS until June 2017, as >>> part of Release 14, we will continue progressing these drafts to >>> IETF last call as currently scheduled. >>> >>> We also acknowledge that during 3GPP's development phase, some >>> differences may occur between that which is outlined within the >>> existing draft-ietf-ecrit-ecall and that which emerges from the >>> 3GPP work. The IETF process allows for RFCs to be revised in the >>> event of changes in technology. >>> >>> We'll collect wg member comments over the next few days and will >>> then move to send out the official response to 3GPP. >>> >>> >>> Roger Marshall >>> Roger.marshall@comtechtel.com >>> Marc Linsner >>> mlinsner@cisco.com >>> ECRIT Chairs >>> >>> >>> -----Original Message----- >>> From: Roger Marshall >>> Sent: Monday, March 21, 2016 1:24 PM >>> To: Emergency Context Resolution with Internet Technologies Discussion List >>> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >>> Subject: RE: New Liaison Statement, "Response to LS on NG eCall >>> support for the EU" >>> >>> ECRIT WG: >>> >>> The chairs have reviewed the thread concerning processing >>> draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as >>> well as the most recent liaison received from 3GPP on 1/31/2016 >>> and discussed with the authors. Given that 3GPP is not scheduled >>> to finish their work until June 2017, we will continue >>> progressing these drafts to IETF last call as scheduled. We also >>> remind the working group that the IETF process allows changes to >>> RFC publications, e.g., issuance of bis RFCs in the event that >>> changes in technology result in the need to make such a change. >>> Such documents would be in scope of the current ECRIT charter, >>> should the need arise. >>> >>> We will send a reply liaison statement to 3GPP to inform them of >>> the status of the documents after we post the proposed liaison >>> text to the list, which will happen shortly. >>> >>> >>> Roger Marshall (roger.marshall@comtechtel.com) & >>> Marc Linsner (mlinsner@cisco.com) >>> Ecrit chairs >>> >>> >>> >>> -----Original Message----- >>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>> Sent: Sunday, January 31, 2016 4:13 PM >>> To: Roger Marshall; Marc Linsner >>> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with >>> Internet Technologies Discussion List; >>> georg.mayer.huawei@gmx.com; 3GPPLiaison@etsi.org; Roger Marshall; >>> Alissa Cooper; Ben Campbell >>> Subject: New Liaison Statement, "Response to LS on NG eCall >>> support for the EU" >>> >>> Title: Response to LS on NG eCall support for the EU Submission >>> Date: 2016-01-31 URL of the IETF Web page: >>> https://datatracker.ietf.org/liaison/1452/ > >> >>> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >>> To: Marc Linsner , Roger Marshall >>> >>> Cc: Barry Leiba ,Marc Linsner >>> ,Ben Campbell ,Alissa >>> Cooper ,Roger Marshall >>> ,Emergency Context Resolution with >>> Internet Technologies Discussion List , Response >>> Contacts: georg.mayer.huawei@gmx.com, 3GPPLiaison@etsi.org >>> Technical Contacts: >>> Purpose: In response >>> >>> Referenced liaison: Liaison Statement on NG eCall support for the >>> EU (https://datatracker.ietf.org/liaison/1412/) >>> >>> Body: 1. Overall description >>> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS >>> (C1-152644) on NG eCall support for the EU. >>> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG >>> CT WG1 will work on stage-3 for eCall in IMS in Release 14 >>> (ending in June 2017), subject to 3GPP TSG SA WG2 completion of >>> the normative stage-2 work and approval of a 3GPP TSG CT work >>> item. >>> 3GPP TSG CT WG1 stage-3 work might result in protocol >>> requirements deviating or conflicting with the current version of >>> IETF draft-ietf-ecrit-ecall, and thus might impact IETF work. >>> >>> 2. Actions >>> To IETF Ecrit WG >>> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take >>> the above into consideration. >>> >>> 3. Dates of next TSG CT WG1 meetings >>> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea >>> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia >>> >>> >>> Attachments: >>> >>> Response to LS on NG eCall support for the EU >>> >>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp-tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.pdf >>> >>> >>> 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In the United States the majority undertakes to supply a multitude of ready-made opinions for the use of individuals, who are thus relieved from the necessity of forming opinions of their own --Alexis de Tocqueville From nobody Tue Mar 22 15:22: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 CFFD212DAB3 for ; Tue, 22 Mar 2016 15:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Ol2YLLREDnB8 for ; Tue, 22 Mar 2016 15:22:08 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 98FD712DAB1 for ; Tue, 22 Mar 2016 15:22:08 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2MMDMuw028396; Tue, 22 Mar 2016 18:22:05 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 21s2vr24mn-3 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Mar 2016 18:22:05 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.230]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 22 Mar 2016 18:12:37 -0400 From: "Rosen, Brian" To: Randall Gellens Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRhIfwxaa/Hznw6U+KeHP0z9Hccg== Date: Tue, 22 Mar 2016 22:12:36 +0000 Message-ID: References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.154.7.40] Content-Type: text/plain; charset="utf-8" Content-ID: <982872FD3773CE4FBBA6488CF25C324E@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-22_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 22:22:11 -0000 VGhlIHByb2JsZW0gSSBoYXZlIHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IGl0IHNheXMg dG8gM0dQUCDigJxjaGFuZ2UgYWxsIHlvdSB3YW50LCB3ZeKAmWxsIGNoYW5nZSBvdXJzIHRvIG1h dGNo4oCdLiAgSSB3YW50IHRoYXQgdG8gYmUg4oCcd2Ugd2VudCBhaGVhZCwgcGxlYXNlIHRyeSB0 byB1c2UgaXTigJ0uDQoNCj4gT24gTWFyIDIyLCAyMDE2LCBhdCA1OjM3IFBNLCBSYW5kYWxsIEdl bGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IHdyb3RlOg0KPiANCj4gSSB0aGluayBK YW1lcyBoYXMgYSBwb2ludCwgYW5kIEJyaWFuJ3Mgc3VnZ2VzdGVkIGNoYW5nZSBpc24ndCBuZWVk ZWQuDQo+IA0KPiBBdCA2OjQxIEFNICsxMTAwIDMvMjMvMTYsIEphbWVzIFdpbnRlcmJvdHRvbSB3 cm90ZToNCj4gDQo+PiBUaGF0IHNvdW5kcyBhIGxpdHRsZSBwcm92b2NhdGl2ZSB0byBtZS4NCj4+ IA0KPj4gDQo+Pj4gT24gMjMgTWFyIDIwMTYsIGF0IDU6MTYgYW0sIFJvc2VuLCBCcmlhbiA8QnJp YW4uUm9zZW5AbmV1c3Rhci5iaXo+IHdyb3RlOg0KPj4+IA0KPj4+IENhbiBJIHN1Z2dlc3QgYSBy ZXdvcmQgb2YgdGhlIDNyZCBwYXJhZ3JhcGguDQo+Pj4gDQo+Pj4gIklmIDNHUFAgZmluZHMgaXQg bmVjZXNzYXJ5IHRvIGludHJvZHVjZSBhbiBpbmNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGlzIGRv Y3VtZW50LCBhcyBmaW5hbGx5IHB1Ymxpc2hlZCwgYW5kIGl0cyB3b3JrLCB3ZSByZXF1ZXN0IHRo YXQgeW91IGluZm9ybSB1cyBvZiBzdWNoIGFuIGlzc3VlIHNvIHRoYXQgd2UgY2FuIGV2YWx1YXRl IGl0cyBlZmZlY3Qgb24gb3VyIGRvY3VtZW50IGFuZCBjb25zaWRlciBhbnkgcmV2aXNpb25zIHRo YXQgbWF5IGJlIG5lZWRlZCwgZm9sbG93aW5nIG5vcm1hbCBJRVRGIHByb2Nlc3Nlcy4iDQo+Pj4g DQo+Pj4gQnJpYW4NCj4+PiANCj4+Pj4gT24gTWFyIDIxLCAyMDE2LCBhdCA1OjM1IFBNLCBSb2dl ciBNYXJzaGFsbCA8Um9nZXIuTWFyc2hhbGxAY29tdGVjaHRlbC5jb20+IHdyb3RlOg0KPj4+PiAN Cj4+Pj4gUHJvcG9zZWQgTGlhaXNvbiByZXNwb25zZToNCj4+Pj4gDQo+Pj4+IFRoZSBJRVRGIEVD UklUIHdvcmtpbmcgZ3JvdXAgd291bGQgbGlrZSB0byB0aGFuayAzR1BQIFRTRyBDVCBXRzEgZm9y IHRoZWlyIHJlc3BvbnNlLCBURG9jIEMxLTE2MDc2NCwgcmVmZXJlbmNpbmcgTFMgKEMxLTE1MjY0 NCkgb24gdGhlIHRvcGljIG9mIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVS4gDQo+Pj4+IFRo ZSBFQ1JJVCB3b3JraW5nIGdyb3VwIGRpc2N1c3NlZCB5b3VyIGxpYWlzb24gYXMgaXQgYXBwbGll cyB0byB0aGUgSUVURiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsIGRvY3VtZW50IGFuZCByZWFjaGVk IHRoZSBmb2xsb3dpbmcgY29uY2x1c2lvbnM6ICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90IHNjaGVk dWxlZCB0byBmaW5pc2ggdGhlaXIgc3RhZ2UtMyB3b3JrIGZvciBlQ2FsbCBpbiBJTVMgdW50aWwg SnVuZSAyMDE3LCBhcyBwYXJ0IG9mIFJlbGVhc2UgMTQsIHdlIHdpbGwgY29udGludWUgcHJvZ3Jl c3NpbmcgdGhlc2UgZHJhZnRzIHRvIElFVEYgbGFzdCBjYWxsIGFzIGN1cnJlbnRseSBzY2hlZHVs ZWQuDQo+Pj4+IA0KPj4+PiBXZSBhbHNvIGFja25vd2xlZGdlIHRoYXQgZHVyaW5nIDNHUFAncyBk ZXZlbG9wbWVudCBwaGFzZSwgc29tZSBkaWZmZXJlbmNlcyBtYXkgb2NjdXIgYmV0d2VlbiB0aGF0 IHdoaWNoIGlzIG91dGxpbmVkIHdpdGhpbiB0aGUgZXhpc3RpbmcgZHJhZnQtaWV0Zi1lY3JpdC1l Y2FsbCBhbmQgdGhhdCB3aGljaCBlbWVyZ2VzIGZyb20gdGhlIDNHUFAgd29yay4gVGhlIElFVEYg cHJvY2VzcyBhbGxvd3MgZm9yIFJGQ3MgdG8gYmUgcmV2aXNlZCBpbiB0aGUgZXZlbnQgb2YgY2hh bmdlcyBpbiB0ZWNobm9sb2d5Lg0KPj4+PiANCj4+Pj4gV2UnbGwgY29sbGVjdCB3ZyBtZW1iZXIg Y29tbWVudHMgb3ZlciB0aGUgbmV4dCBmZXcgZGF5cyBhbmQgd2lsbCB0aGVuIG1vdmUgdG8gc2Vu ZCBvdXQgdGhlIG9mZmljaWFsIHJlc3BvbnNlIHRvIDNHUFAuDQo+Pj4+IA0KPj4+PiANCj4+Pj4g Um9nZXIgTWFyc2hhbGwNCj4+Pj4gUm9nZXIubWFyc2hhbGxAY29tdGVjaHRlbC5jb20NCj4+Pj4g TWFyYyBMaW5zbmVyDQo+Pj4+IG1saW5zbmVyQGNpc2NvLmNvbQ0KPj4+PiBFQ1JJVCBDaGFpcnMN Cj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9t OiBSb2dlciBNYXJzaGFsbA0KPj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDIxLCAyMDE2IDE6MjQg UE0NCj4+Pj4gVG86IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBU ZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0DQo+Pj4+IENjOiBNYXJjIExpbnNuZXI7IEFsaXNz YSBDb29wZXI7IEJlbiBDYW1wYmVsbA0KPj4+PiBTdWJqZWN0OiBSRTogTmV3IExpYWlzb24gU3Rh dGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0K Pj4+PiANCj4+Pj4gRUNSSVQgV0c6DQo+Pj4+IA0KPj4+PiBUaGUgY2hhaXJzIGhhdmUgcmV2aWV3 ZWQgdGhlIHRocmVhZCBjb25jZXJuaW5nIHByb2Nlc3NpbmcgZHJhZnQtaWV0Zi1lY3JpdC1lY2Fs bC0wNSBhbmQgZHJhZnQtaWV0Zi1lY3JpdC1jYXItY3Jhc2gtMDUgYXMgd2VsbCBhcyB0aGUgbW9z dCByZWNlbnQgbGlhaXNvbiByZWNlaXZlZCBmcm9tIDNHUFAgb24gMS8zMS8yMDE2IGFuZCBkaXNj dXNzZWQgd2l0aCB0aGUgYXV0aG9ycy4gIEdpdmVuIHRoYXQgM0dQUCBpcyBub3Qgc2NoZWR1bGVk IHRvIGZpbmlzaCB0aGVpciB3b3JrIHVudGlsIEp1bmUgMjAxNywgd2Ugd2lsbCBjb250aW51ZSBw cm9ncmVzc2luZyB0aGVzZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwgYXMgc2NoZWR1bGVkLiBX ZSBhbHNvIHJlbWluZCB0aGUgd29ya2luZyBncm91cCB0aGF0IHRoZSBJRVRGIHByb2Nlc3MgYWxs b3dzIGNoYW5nZXMgdG8gUkZDIHB1YmxpY2F0aW9ucywgZS5nLiwgaXNzdWFuY2Ugb2YgYmlzIFJG Q3MgaW4gdGhlIGV2ZW50IHRoYXQgY2hhbmdlcyBpbiB0ZWNobm9sb2d5IHJlc3VsdCBpbiB0aGUg bmVlZCB0byBtYWtlIHN1Y2ggYSBjaGFuZ2UuIFN1Y2ggZG9jdW1lbnRzIHdvdWxkIGJlIGluIHNj b3BlIG9mIHRoZSBjdXJyZW50IEVDUklUIGNoYXJ0ZXIsIHNob3VsZCB0aGUgbmVlZCBhcmlzZS4N Cj4+Pj4gDQo+Pj4+IFdlIHdpbGwgc2VuZCBhIHJlcGx5IGxpYWlzb24gc3RhdGVtZW50IHRvIDNH UFAgdG8gaW5mb3JtIHRoZW0gb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGFmdGVyIHdl IHBvc3QgdGhlIHByb3Bvc2VkIGxpYWlzb24gdGV4dCB0byB0aGUgbGlzdCwgd2hpY2ggd2lsbCBo YXBwZW4gc2hvcnRseS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBSb2dlciBNYXJzaGFsbCAocm9nZXIu bWFyc2hhbGxAY29tdGVjaHRlbC5jb20pICAmDQo+Pj4+IE1hcmMgTGluc25lciAobWxpbnNuZXJA Y2lzY28uY29tKQ0KPj4+PiBFY3JpdCBjaGFpcnMNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogTGlhaXNvbiBTdGF0ZW1lbnQg TWFuYWdlbWVudCBUb29sIFttYWlsdG86bHNtdEBpZXRmLm9yZ10NCj4+Pj4gU2VudDogU3VuZGF5 LCBKYW51YXJ5IDMxLCAyMDE2IDQ6MTMgUE0NCj4+Pj4gVG86IFJvZ2VyIE1hcnNoYWxsOyBNYXJj IExpbnNuZXINCj4+Pj4gQ2M6IEJhcnJ5IExlaWJhOyBNYXJjIExpbnNuZXI7IEVtZXJnZW5jeSBD b250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBM aXN0OyBnZW9yZy5tYXllci5odWF3ZWlAZ214LmNvbTsgM0dQUExpYWlzb25AZXRzaS5vcmc7IFJv Z2VyIE1hcnNoYWxsOyBBbGlzc2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwNCj4+Pj4gU3ViamVjdDog TmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9y dCBmb3IgdGhlIEVVIg0KPj4+PiANCj4+Pj4gVGl0bGU6IFJlc3BvbnNlIHRvIExTIG9uIE5HIGVD YWxsIHN1cHBvcnQgZm9yIHRoZSBFVSBTdWJtaXNzaW9uIERhdGU6IDIwMTYtMDEtMzEgVVJMIG9m IHRoZSBJRVRGIFdlYiBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24v MTQ1Mi8NCj4+Pj4gDQo+Pj4+IEZyb206ICJTdXNhbm5hIEtvb2lzdHJhIiA8M0dQUExpYWlzb25A ZXRzaS5vcmc+DQo+Pj4+IFRvOiBNYXJjIExpbnNuZXIgPG1hcmMubGluc25lckBjaXNjby5jb20+ LCBSb2dlciBNYXJzaGFsbCA8cm1hcnNoYWxsQHRlbGVjb21zeXMuY29tPg0KPj4+PiBDYzogQmFy cnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPixNYXJjIExpbnNuZXIgPG1hcmMubGlu c25lckBjaXNjby5jb20+LEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPixBbGlzc2EgQ29v cGVyIDxhbGlzc2FAY29vcGVydy5pbj4sUm9nZXIgTWFyc2hhbGwgPHJtYXJzaGFsbEB0ZWxlY29t c3lzLmNvbT4sRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hu b2xvZ2llcyBEaXNjdXNzaW9uIExpc3QgPGVjcml0QGlldGYub3JnPiwgUmVzcG9uc2UgQ29udGFj dHM6IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tLCAzR1BQTGlhaXNvbkBldHNpLm9yZyBUZWNo bmljYWwgQ29udGFjdHM6DQo+Pj4+IFB1cnBvc2U6IEluIHJlc3BvbnNlDQo+Pj4+IA0KPj4+PiBS ZWZlcmVuY2VkIGxpYWlzb246IExpYWlzb24gU3RhdGVtZW50IG9uIE5HIGVDYWxsIHN1cHBvcnQg Zm9yIHRoZSBFVSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0MTIvKQ0K Pj4+PiANCj4+Pj4gQm9keTogMS4gT3ZlcmFsbCBkZXNjcmlwdGlvbg0KPj4+PiAzR1BQIFRTRyBD VCBXRzEgd291bGQgbGlrZSB0byB0aGFuayBJRVRGIEVjcml0IFdHIGZvciB0aGUgTFMgKEMxLTE1 MjY0NCkgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVLg0KPj4+PiAzR1BQIFRTRyBDVCBX RzEgd291bGQgbGlrZSB0byBpbmZvcm0gSUVURiBFY3JpdCBXRyB0aGF0IDNHUFAgVFNHIENUIFdH MSB3aWxsIHdvcmsgb24gc3RhZ2UtMyBmb3IgZUNhbGwgaW4gSU1TIGluIFJlbGVhc2UgMTQgKGVu ZGluZyBpbiBKdW5lIDIwMTcpLCBzdWJqZWN0IHRvIDNHUFAgVFNHIFNBIFdHMiBjb21wbGV0aW9u IG9mIHRoZSBub3JtYXRpdmUgc3RhZ2UtMiB3b3JrIGFuZCBhcHByb3ZhbCBvZiBhIDNHUFAgVFNH IENUIHdvcmsgaXRlbS4NCj4+Pj4gM0dQUCBUU0cgQ1QgV0cxIHN0YWdlLTMgd29yayBtaWdodCBy ZXN1bHQgaW4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGRldmlhdGluZyBvciBjb25mbGljdGluZyB3 aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgSUVURiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLCBh bmQgdGh1cyBtaWdodCBpbXBhY3QgSUVURiB3b3JrLg0KPj4+PiANCj4+Pj4gMi4gQWN0aW9ucw0K Pj4+PiBUbyBJRVRGIEVjcml0IFdHDQo+Pj4+IEFDVElPTjogM0dQUCBUU0cgQ1QgV0cxIHJlc3Bl Y3RmdWxseSBhc2tzIElFVEYgRWNyaXQgV0cgdG8gdGFrZSB0aGUgYWJvdmUgaW50byBjb25zaWRl cmF0aW9uLg0KPj4+PiANCj4+Pj4gMy4gRGF0ZXMgb2YgbmV4dCBUU0cgQ1QgV0cxIG1lZXRpbmdz DQo+Pj4+IFRTRyBDVCBXRzEgTWVldGluZyA5NgkxNS0xOSBGZWJydWFyeSAyMDE2CUplanUgSXNs YW5kLCBLb3JlYQ0KPj4+PiBUU0cgQ1QgV0cxIE1lZXRpbmcgOTcJMTEtMTUgQXByaWwgMjAxNglM anVibGphbmEsIFNsb3ZlbmlhDQo+Pj4+IA0KPj4+PiANCj4+Pj4gQXR0YWNobWVudHM6DQo+Pj4+ IA0KPj4+PiAgUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29u LTIwMTYtMDEtMzEtM2dwcC10c2djdC1jdDEtZWNyaXQtcmVzcG9uc2UtdG8tbHMtb24tbmctZWNh bGwtc3VwcG9ydC1mb3ItdGhlLWV1LWF0dGFjaG1lbnQtMS5wZGYNCj4+Pj4gDQo+Pj4+IA0KPj4+ PiBOT1RJQ0UgVE8gUkVDSVBJRU5UOiBUaGlzIGVtYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMs IG1heSBjb250YWluIGluZm9ybWF0aW9uIHdoaWNoIGlzIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRh cnksIGF0dG9ybmV5LWNsaWVudCBwcml2aWxlZ2VkIGFuZC9vciBjb250cm9sbGVkIHVuZGVyIFUu Uy4gZXhwb3J0IGxhd3MgYW5kIHJlZ3VsYXRpb25zIGFuZCBtYXkgYmUgcmVzdHJpY3RlZCBmcm9t IGRpc2Nsb3N1cmUgYnkgYXBwbGljYWJsZSBTdGF0ZSBhbmQgRmVkZXJhbCBsYXcuIE5vdGhpbmcg aW4gdGhpcyBlbWFpbCBzaGFsbCBjcmVhdGUgYW55IGxlZ2FsIGJpbmRpbmcgYWdyZWVtZW50IGJl dHdlZW4gdGhlIHBhcnRpZXMgdW5sZXNzIGV4cHJlc3NseSBzdGF0ZWQgaGVyZWluIGFuZCBwcm92 aWRlZCBieSBhbiBhdXRob3JpemVkIHJlcHJlc2VudGF0aXZlIG9mIENvbXRlY2ggVGVsZWNvbW11 bmljYXRpb25zIENvcnAuIG9yIGl0cyBzdWJzaWRpYXJpZXMuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlLCBiZSBhZHZpc2VkIHRoYXQgYW55IGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz IG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgbWVz c2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXR1cm4gZW1h aWwgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBlbWFp bCBhbmQgYW55IGF0dGFjaGVkIGRvY3VtZW50YXRpb24gZnJvbSBhbnkgY29tcHV0ZXIgb3Igb3Ro ZXIgbWVkaWEuDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4gDQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBFY3Jp dCBtYWlsaW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4gRWNy aXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy aXQNCj4gDQo+IA0KPiAtLSANCj4gUmFuZGFsbCBHZWxsZW5zDQo+IE9waW5pb25zIGFyZSBwZXJz b25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5DQo+ IC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+ IEluIHRoZSBVbml0ZWQgU3RhdGVzIHRoZSBtYWpvcml0eSB1bmRlcnRha2VzIHRvIHN1cHBseSBh IG11bHRpdHVkZSBvZg0KPiByZWFkeS1tYWRlIG9waW5pb25zIGZvciB0aGUgdXNlIG9mIGluZGl2 aWR1YWxzLCB3aG8gYXJlIHRodXMgcmVsaWV2ZWQNCj4gZnJvbSB0aGUgbmVjZXNzaXR5IG9mIGZv cm1pbmcgb3BpbmlvbnMgb2YgdGhlaXIgb3duDQo+ICAgIC0tQWxleGlzIGRlIFRvY3F1ZXZpbGxl DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo= From nobody Tue Mar 22 15:38: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 1C11012DADB for ; Tue, 22 Mar 2016 15:38:12 -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, FREEMAIL_FROM=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=gmail.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 gG1EhIhYYPQr for ; Tue, 22 Mar 2016 15:38:09 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 5AB2112D0B6 for ; Tue, 22 Mar 2016 15:38:09 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n5so328787929pfn.2 for ; Tue, 22 Mar 2016 15:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=AROgPpsiXMDwh0/4ZxzB88LWHKx4e5xNLkQOLp+5I/Y=; b=jHc/zZg28X8oHOS/vOozQJedWjEvMquoKzCKHQer+S1GACD0MH5rWm5HpN5TJpQjOY XPjj/zU4oZ3EIgAwYE30lgF8rsZGWJTVt302Oz6fpP/dD64Dbdl5OqwTic+L5trv4fo8 +IHLCbfnWo2FW/m4KEYfs/WGdyJkDr0r2/3wMOMPyTow3d3Vk4C8ONCJvDciaJiV50Xi I+mjKPPD1WYMhPRv6OFlXbowiuRBCJMHjAHu9anvmIDFaY3m+WQwkki67xClgOrNwjq6 dfqC/Nwoeb+px8BrffgLpn4f2EN1YT/aghn85jzw/7j/PoK6ftJPL7yL14777WmUr6yX heWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=AROgPpsiXMDwh0/4ZxzB88LWHKx4e5xNLkQOLp+5I/Y=; b=E8mqhZfwHlUBtHT25tWNpAr4HY/78K23v0pOdKJVyrW5pdNdDLVwkKuQIUfK41tAVC FhFP33WPPKGAhJuklVtCzRz/Vf3PRH7DLyM5ogHijO+ZEbM1GRRiOWrnR5lR5eC8nt+w 4dPQ1jmqcIQu0VCu9fga98S5adWC1xIKPekfiBdMjZv5H319Um9FX2o5GIp/ZmaB+SXe c/jWfyBI4kNQ/MXxStT1oYmWtShgkmYpqd+b5wTgjripf/Xo/TRkmhNul4P1eqH1py4Y auEWPYrAf0JHP21o2GsuSk8iEoYVmFfUprXlymL0pdV/k9aH64v4ziL8iSBdKo4rW+O9 DNaQ== X-Gm-Message-State: AD7BkJKYIvemGzn4vGPeXkxFhCi4r8yZXSg/XkntBYQFh5mlZ30Cm1cNeIdzG6SPsb3O3w== X-Received: by 10.66.141.134 with SMTP id ro6mr40386909pab.111.1458686288795; Tue, 22 Mar 2016 15:38:08 -0700 (PDT) Received: from [10.173.107.58] ([1.129.74.52]) by smtp.gmail.com with ESMTPSA id r65sm50644549pfa.27.2016.03.22.15.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 15:38:07 -0700 (PDT) References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Wed, 23 Mar 2016 09:38:03 +1100 To: "Rosen, Brian" Archived-At: Cc: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 22:38:12 -0000 You don't think that that is a little rich when we asked them for their opin= ion they said please wait and we say no, we are going ahead anyway? It seems to me that we should be prepared to adapt. Sent from my iPhone > On 23 Mar 2016, at 9:12 am, "Rosen, Brian" wrote= : >=20 > The problem I have with the current text is that it says to 3GPP =E2=80=9C= change all you want, we=E2=80=99ll change ours to match=E2=80=9D. I want th= at to be =E2=80=9Cwe went ahead, please try to use it=E2=80=9D. >=20 >> On Mar 22, 2016, at 5:37 PM, Randall Gellens w= rote: >>=20 >> I think James has a point, and Brian's suggested change isn't needed. >>=20 >> At 6:41 AM +1100 3/23/16, James Winterbottom wrote: >>=20 >>> That sounds a little provocative to me. >>>=20 >>>=20 >>>> On 23 Mar 2016, at 5:16 am, Rosen, Brian wrot= e: >>>>=20 >>>> Can I suggest a reword of the 3rd paragraph. >>>>=20 >>>> "If 3GPP finds it necessary to introduce an incompatibility between thi= s document, as finally published, and its work, we request that you inform u= s of such an issue so that we can evaluate its effect on our document and co= nsider any revisions that may be needed, following normal IETF processes." >>>>=20 >>>> Brian >>>>=20 >>>>> On Mar 21, 2016, at 5:35 PM, Roger Marshall wrote: >>>>>=20 >>>>> Proposed Liaison response: >>>>>=20 >>>>> The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 for t= heir response, TDoc C1-160764, referencing LS (C1-152644) on the topic of NG= eCall support for the EU.=20 >>>>> The ECRIT working group discussed your liaison as it applies to the IE= TF draft-ietf-ecrit-ecall document and reached the following conclusions: G= iven that 3GPP is not scheduled to finish their stage-3 work for eCall in IM= S until June 2017, as part of Release 14, we will continue progressing these= drafts to IETF last call as currently scheduled. >>>>>=20 >>>>> We also acknowledge that during 3GPP's development phase, some differe= nces may occur between that which is outlined within the existing draft-ietf= -ecrit-ecall and that which emerges from the 3GPP work. The IETF process all= ows for RFCs to be revised in the event of changes in technology. >>>>>=20 >>>>> We'll collect wg member comments over the next few days and will then m= ove to send out the official response to 3GPP. >>>>>=20 >>>>>=20 >>>>> Roger Marshall >>>>> Roger.marshall@comtechtel.com >>>>> Marc Linsner >>>>> mlinsner@cisco.com >>>>> ECRIT Chairs >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Roger Marshall >>>>> Sent: Monday, March 21, 2016 1:24 PM >>>>> To: Emergency Context Resolution with Internet Technologies Discussion= List >>>>> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >>>>> Subject: RE: New Liaison Statement, "Response to LS on NG eCall suppor= t for the EU" >>>>>=20 >>>>> ECRIT WG: >>>>>=20 >>>>> The chairs have reviewed the thread concerning processing draft-ietf-e= crit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well as the most recent l= iaison received from 3GPP on 1/31/2016 and discussed with the authors. Give= n that 3GPP is not scheduled to finish their work until June 2017, we will c= ontinue progressing these drafts to IETF last call as scheduled. We also rem= ind the working group that the IETF process allows changes to RFC publicatio= ns, e.g., issuance of bis RFCs in the event that changes in technology resul= t in the need to make such a change. Such documents would be in scope of the= current ECRIT charter, should the need arise. >>>>>=20 >>>>> We will send a reply liaison statement to 3GPP to inform them of the s= tatus of the documents after we post the proposed liaison text to the list, w= hich will happen shortly. >>>>>=20 >>>>>=20 >>>>> Roger Marshall (roger.marshall@comtechtel.com) & >>>>> Marc Linsner (mlinsner@cisco.com) >>>>> Ecrit chairs >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>>> Sent: Sunday, January 31, 2016 4:13 PM >>>>> To: Roger Marshall; Marc Linsner >>>>> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with Inter= net Technologies Discussion List; georg.mayer.huawei@gmx.com; 3GPPLiaison@et= si.org; Roger Marshall; Alissa Cooper; Ben Campbell >>>>> Subject: New Liaison Statement, "Response to LS on NG eCall support fo= r the EU" >>>>>=20 >>>>> Title: Response to LS on NG eCall support for the EU Submission Date: 2= 016-01-31 URL of the IETF Web page: https://datatracker.ietf.org/liaison/145= 2/ >>>>>=20 >>>>> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >>>>> To: Marc Linsner , Roger Marshall >>>>> Cc: Barry Leiba ,Marc Linsner ,Ben Campbell ,Alissa Cooper ,R= oger Marshall ,Emergency Context Resolution with I= nternet Technologies Discussion List , Response Contacts: ge= org.mayer.huawei@gmx.com, 3GPPLiaison@etsi.org Technical Contacts: >>>>> Purpose: In response >>>>>=20 >>>>> Referenced liaison: Liaison Statement on NG eCall support for the EU (= https://datatracker.ietf.org/liaison/1412/) >>>>>=20 >>>>> Body: 1. Overall description >>>>> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS (C1-15264= 4) on NG eCall support for the EU. >>>>> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG CT WG= 1 will work on stage-3 for eCall in IMS in Release 14 (ending in June 2017),= subject to 3GPP TSG SA WG2 completion of the normative stage-2 work and app= roval of a 3GPP TSG CT work item. >>>>> 3GPP TSG CT WG1 stage-3 work might result in protocol requirements dev= iating or conflicting with the current version of IETF draft-ietf-ecrit-ecal= l, and thus might impact IETF work. >>>>>=20 >>>>> 2. Actions >>>>> To IETF Ecrit WG >>>>> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take the ab= ove into consideration. >>>>>=20 >>>>> 3. Dates of next TSG CT WG1 meetings >>>>> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea >>>>> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia >>>>>=20 >>>>>=20 >>>>> Attachments: >>>>>=20 >>>>> Response to LS on NG eCall support for the EU >>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp-= tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.p= df >>>>>=20 >>>>>=20 >>>>> NOTICE TO RECIPIENT: This email, including attachments, may contain in= formation which is confidential, proprietary, attorney-client privileged and= /or 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 sh= all create any legal binding agreement between the parties unless expressly s= tated herein and provided by an authorized representative of Comtech Telecom= munications 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 m= essage in error, please notify us immediately by return email and permanentl= y delete all copies of the original email and any attached documentation fro= m any computer or other media. >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> --=20 >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> In the United States the majority undertakes to supply a multitude of >> ready-made opinions for the use of individuals, who are thus relieved >> from the necessity of forming opinions of their own >> --Alexis de Tocqueville >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Tue Mar 22 16:27:17 2016 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87E312D0DE for ; Tue, 22 Mar 2016 16:27:15 -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.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 vilJQS0keUIH for ; Tue, 22 Mar 2016 16:27:13 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4112D096 for ; Tue, 22 Mar 2016 16:27:13 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 22 Mar 2016 16:27:12 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Mar 2016 16:27:09 -0700 To: "Rosen, Brian" 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: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 22 Mar 2016 23:27:16 -0000 I think it's best to not try and convey such messages in liaison statements. There are people active in both SDOs who know what is going on. It would be pointless and counter-productive to stir up a political battle. At 10:12 PM +0000 3/22/16, Brian Rosen wrote: > The problem I have with the current text is that it says to 3GPP > "change all you want, we'll change ours to match". I want that to > be "we went ahead, please try to use it". > >> On Mar 22, 2016, at 5:37 PM, Randall Gellens >> wrote: >> >> I think James has a point, and Brian's suggested change isn't needed. >> >> At 6:41 AM +1100 3/23/16, James Winterbottom wrote: >> >>> That sounds a little provocative to me. >>> >>> >>>> On 23 Mar 2016, at 5:16 am, Rosen, Brian wrote: >>>> >>>> Can I suggest a reword of the 3rd paragraph. >>>> >>>> "If 3GPP finds it necessary to introduce an incompatibility >>>> between this document, as finally published, and its work, we >>>> request that you inform us of such an issue so that we can >>>> evaluate its effect on our document and consider any revisions >>>> that may be needed, following normal IETF processes." >>>> >>>> Brian >>>> >>>>> On Mar 21, 2016, at 5:35 PM, Roger Marshall >>>>> wrote: >>>>> >>>>> Proposed Liaison response: >>>>> >>>>> The IETF ECRIT working group would like to thank 3GPP TSG CT >>>>> WG1 for their response, TDoc C1-160764, referencing LS >>>>> (C1-152644) on the topic of NG eCall support for the EU. >>>>> The ECRIT working group discussed your liaison as it applies to >>>>> the IETF draft-ietf-ecrit-ecall document and reached the >>>>> following conclusions: Given that 3GPP is not scheduled to >>>>> finish their stage-3 work for eCall in IMS until June 2017, as >>>>> part of Release 14, we will continue progressing these drafts >>>>> to IETF last call as currently scheduled. >>>>> >>>>> We also acknowledge that during 3GPP's development phase, some >>>>> differences may occur between that which is outlined within the >>>>> existing draft-ietf-ecrit-ecall and that which emerges from the >>>>> 3GPP work. The IETF process allows for RFCs to be revised in >>>>> the event of changes in technology. >>>>> >>>>> We'll collect wg member comments over the next few days and >>>>> will then move to send out the official response to 3GPP. >>>>> >>>>> >>>>> Roger Marshall >>>>> Roger.marshall@comtechtel.com >>>>> Marc Linsner >>>>> mlinsner@cisco.com >>>>> ECRIT Chairs >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Roger Marshall >>>>> Sent: Monday, March 21, 2016 1:24 PM >>>>> To: Emergency Context Resolution with Internet Technologies >>>>> Discussion List >>>>> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >>>>> Subject: RE: New Liaison Statement, "Response to LS on NG eCall >>>>> support for the EU" >>>>> >>>>> ECRIT WG: >>>>> >>>>> The chairs have reviewed the thread concerning processing >>>>> draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as >>>>> well as the most recent liaison received from 3GPP on 1/31/2016 >>>>> and discussed with the authors. Given that 3GPP is not >>>>> scheduled to finish their work until June 2017, we will >>>>> continue progressing these drafts to IETF last call as >>>>> scheduled. We also remind the working group that the IETF >>>>> process allows changes to RFC publications, e.g., issuance of >>>>> bis RFCs in the event that changes in technology result in the >>>>> need to make such a change. Such documents would be in scope of >>>>> the current ECRIT charter, should the need arise. >>>>> >>>>> We will send a reply liaison statement to 3GPP to inform them >>>>> of the status of the documents after we post the proposed >>>>> liaison text to the list, which will happen shortly. >>>>> >>>>> >>>>> Roger Marshall (roger.marshall@comtechtel.com) & > >>>> Marc Linsner (mlinsner@cisco.com) >>>>> Ecrit chairs >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>>> Sent: Sunday, January 31, 2016 4:13 PM >>>>> To: Roger Marshall; Marc Linsner >>>>> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution >>>>> with Internet Technologies Discussion List; >>>>> georg.mayer.huawei@gmx.com; 3GPPLiaison@etsi.org; Roger >>>>> Marshall; Alissa Cooper; Ben Campbell >>>>> Subject: New Liaison Statement, "Response to LS on NG eCall >>>>> support for the EU" >>>>> >>>>> Title: Response to LS on NG eCall support for the EU Submission >>>>> Date: 2016-01-31 URL of the IETF Web page: >>>>> https://datatracker.ietf.org/liaison/1452/ >>>>> >>>>> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >>>>> To: Marc Linsner , Roger Marshall >>>>> >>>>> Cc: Barry Leiba ,Marc Linsner >>>>> ,Ben Campbell ,Alissa >>>>> Cooper ,Roger Marshall >>>>> ,Emergency Context Resolution with >>>>> Internet Technologies Discussion List , >>>>> Response Contacts: georg.mayer.huawei@gmx.com, >>>>> 3GPPLiaison@etsi.org Technical Contacts: >>>>> Purpose: In response >>>>> >>>>> Referenced liaison: Liaison Statement on NG eCall support for >>>>> the EU (https://datatracker.ietf.org/liaison/1412/) >>>>> >>>>> Body: 1. Overall description >>>>> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS >>>>> (C1-152644) on NG eCall support for the EU. >>>>> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP >>>>> TSG CT WG1 will work on stage-3 for eCall in IMS in Release 14 >>>>> (ending in June 2017), subject to 3GPP TSG SA WG2 completion of >>>>> the normative stage-2 work and approval of a 3GPP TSG CT work >>>>> item. >>>>> 3GPP TSG CT WG1 stage-3 work might result in protocol >>>>> requirements deviating or conflicting with the current version >>>>> of IETF draft-ietf-ecrit-ecall, and thus might impact IETF work. >>>>> >>>>> 2. Actions >>>>> To IETF Ecrit WG >>>>> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take >>>>> the above into consideration. >>>>> >>>>> 3. Dates of next TSG CT WG1 meetings >>>>> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea >>>>> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia >>>>> >>>>> >>>>> Attachments: >>>>> >>>>> Response to LS on NG eCall support for the EU >>>>> >>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp-tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.pdf >>>>> >>>>> >>>>> 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 >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> In the United States the majority undertakes to supply a multitude of >> ready-made opinions for the use of individuals, who are thus relieved > > from the necessity of forming opinions of their own >> --Alexis de Tocqueville >> >> _______________________________________________ >> 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 ignorance of how to use new knowledge stockpiles exponentially. --Marshall McLuhan From nobody Tue Mar 22 17:39: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 28D5E12D183 for ; Tue, 22 Mar 2016 17:39:25 -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, FREEMAIL_FROM=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=gmail.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 a2RIbi-1WuHA for ; Tue, 22 Mar 2016 17:39:22 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 37C1712D5B1 for ; Tue, 22 Mar 2016 17:39:22 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 4so876198pfd.0 for ; Tue, 22 Mar 2016 17:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=1D66eKto18zyvLZWcs3epUbNgy0ncmLfDsHE7K7OE3w=; b=Svx8l/s22jgrne3t4fUUoP05zDbM2oGSKsIzHpKwiToGLLvv8IzELvQi8Rv49m5/6j ymMJh1m35xO4mysh8k/BmVzuen2vCQnKnWx4MqKvQNAKBIm0gCbUvJuBGFx3zpWx5M0C Mt/mlv91lSkxKDU8woox2YMwtD9vtvprXl1YEmgxcFFpB4j8D8M1Odih44bT61puQ0JW k7pzcS+1aOevpPQIgaqFDzRxAjYb795FPSZwSOljNTB9a04i9umQhrL9DPiBYRW82Xrm YSgroxC+aMTKHBH1+pQaIzYWUsIlUEei83dL8FqnVJXJOSExgbbToC/V1frggNDWKZwz liEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1D66eKto18zyvLZWcs3epUbNgy0ncmLfDsHE7K7OE3w=; b=LzaAoeTjqMmBX3+hznDwOKAEcQzFwU2ecp6Ar3BAIVlfC7zGN036/DNYg+xjlUB63h +nSXbkmAb1/FmQeqyAE2bJ/XZb8ezsCtumdPzdiloV6Vb6B9mDIkJjVT3XZZfyaAiIG+ M+JPcFZLyVtofAM8TXVFaTfiQSabziiITiIl7YtOnuqMqtXFu5qjczaPh5prC0pkqRo0 aaX15fsZTbaABKICAuersVbM60ppByKyt0TlPX4Fk8AVnox9OUPZ4Afq0Hq4F+QE8EhE QZTxj3TzxjMsW84tkM2uyQOGnwvY63ZipBtW0nWRwrKRoD/rxPnSw2lA231K9Wui7Csx aJ0w== X-Gm-Message-State: AD7BkJJd51uCX45IlMOSxYNVQw1ZriJNrd+Zo7JUeQ7zY6wB+jlBMFKF+1Pdwe+rhVkENw== X-Received: by 10.66.102.37 with SMTP id fl5mr106571pab.32.1458693561705; Tue, 22 Mar 2016 17:39:21 -0700 (PDT) Received: from [10.173.107.58] ([1.129.74.240]) by smtp.gmail.com with ESMTPSA id s64sm50929695pfi.77.2016.03.22.17.39.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 17:39:19 -0700 (PDT) References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6A2536DC-A795-47A6-B03E-3AB5318C0563@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Wed, 23 Mar 2016 11:39:13 +1100 To: Randall Gellens Archived-At: Cc: "Rosen, Brian" , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 23 Mar 2016 00:39:25 -0000 I agree Sent from my iPhone > On 23 Mar 2016, at 10:27 am, Randall Gellens w= rote: >=20 > I think it's best to not try and convey such messages in liaison statement= s. There are people active in both SDOs who know what is going on. It woul= d be pointless and counter-productive to stir up a political battle. >=20 > At 10:12 PM +0000 3/22/16, Brian Rosen wrote: >=20 >> The problem I have with the current text is that it says to 3GPP "change a= ll you want, we'll change ours to match". I want that to be "we went ahead,= please try to use it". >>=20 >>> On Mar 22, 2016, at 5:37 PM, Randall Gellens = wrote: >>>=20 >>> I think James has a point, and Brian's suggested change isn't needed. >>>=20 >>> At 6:41 AM +1100 3/23/16, James Winterbottom wrote: >>>=20 >>>> That sounds a little provocative to me. >>>>=20 >>>>=20 >>>>> On 23 Mar 2016, at 5:16 am, Rosen, Brian wro= te: >>>>>=20 >>>>> Can I suggest a reword of the 3rd paragraph. >>>>>=20 >>>>> "If 3GPP finds it necessary to introduce an incompatibility between th= is document, as finally published, and its work, we request that you inform u= s of such an issue so that we can evaluate its effect on our document and co= nsider any revisions that may be needed, following normal IETF processes." >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Mar 21, 2016, at 5:35 PM, Roger Marshall wrote: >>>>>>=20 >>>>>> Proposed Liaison response: >>>>>>=20 >>>>>> The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 for t= heir response, TDoc C1-160764, referencing LS (C1-152644) on the topic of NG= eCall support for the EU. >>>>>> The ECRIT working group discussed your liaison as it applies to the I= ETF draft-ietf-ecrit-ecall document and reached the following conclusions: G= iven that 3GPP is not scheduled to finish their stage-3 work for eCall in IM= S until June 2017, as part of Release 14, we will continue progressing these= drafts to IETF last call as currently scheduled. >>>>>>=20 >>>>>> We also acknowledge that during 3GPP's development phase, some differ= ences may occur between that which is outlined within the existing draft-iet= f-ecrit-ecall and that which emerges from the 3GPP work. The IETF process al= lows for RFCs to be revised in the event of changes in technology. >>>>>>=20 >>>>>> We'll collect wg member comments over the next few days and will then= move to send out the official response to 3GPP. >>>>>>=20 >>>>>>=20 >>>>>> Roger Marshall >>>>>> Roger.marshall@comtechtel.com >>>>>> Marc Linsner >>>>>> mlinsner@cisco.com >>>>>> ECRIT Chairs >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Roger Marshall >>>>>> Sent: Monday, March 21, 2016 1:24 PM >>>>>> To: Emergency Context Resolution with Internet Technologies Discussio= n List >>>>>> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >>>>>> Subject: RE: New Liaison Statement, "Response to LS on NG eCall suppo= rt for the EU" >>>>>>=20 >>>>>> ECRIT WG: >>>>>>=20 >>>>>> The chairs have reviewed the thread concerning processing draft-ietf-= ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well as the most recent l= iaison received from 3GPP on 1/31/2016 and discussed with the authors. Give= n that 3GPP is not scheduled to finish their work until June 2017, we will c= ontinue progressing these drafts to IETF last call as scheduled. We also rem= ind the working group that the IETF process allows changes to RFC publicatio= ns, e.g., issuance of bis RFCs in the event that changes in technology resul= t in the need to make such a change. Such documents would be in scope of the= current ECRIT charter, should the need arise. >>>>>>=20 >>>>>> We will send a reply liaison statement to 3GPP to inform them of the s= tatus of the documents after we post the proposed liaison text to the list, w= hich will happen shortly. >>>>>>=20 >>>>>>=20 >>>>>> Roger Marshall (roger.marshall@comtechtel.com) & >> >>>> Marc Linsner (mlinsner@cisco.com) >>>>>> Ecrit chairs >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>>>> Sent: Sunday, January 31, 2016 4:13 PM >>>>>> To: Roger Marshall; Marc Linsner >>>>>> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with Inte= rnet Technologies Discussion List; georg.mayer.huawei@gmx.com; 3GPPLiaison@e= tsi.org; Roger Marshall; Alissa Cooper; Ben Campbell >>>>>> Subject: New Liaison Statement, "Response to LS on NG eCall support f= or the EU" >>>>>>=20 >>>>>> Title: Response to LS on NG eCall support for the EU Submission Date:= 2016-01-31 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1= 452/ >>>>>>=20 >>>>>> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >>>>>> To: Marc Linsner , Roger Marshall >>>>>> Cc: Barry Leiba ,Marc Linsner ,Ben Campbell ,Alissa Cooper ,= Roger Marshall ,Emergency Context Resolution with I= nternet Technologies Discussion List , Response Contacts: ge= org.mayer.huawei@gmx.com, 3GPPLiaison@etsi.org Technical Contacts: >>>>>> Purpose: In response >>>>>>=20 >>>>>> Referenced liaison: Liaison Statement on NG eCall support for the EU (= https://datatracker.ietf.org/liaison/1412/) >>>>>>=20 >>>>>> Body: 1. Overall description >>>>>> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS (C1-1526= 44) on NG eCall support for the EU. >>>>>> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG CT W= G1 will work on stage-3 for eCall in IMS in Release 14 (ending in June 2017)= , subject to 3GPP TSG SA WG2 completion of the normative stage-2 work and ap= proval of a 3GPP TSG CT work item. >>>>>> 3GPP TSG CT WG1 stage-3 work might result in protocol requirements de= viating or conflicting with the current version of IETF draft-ietf-ecrit-eca= ll, and thus might impact IETF work. >>>>>>=20 >>>>>> 2. Actions >>>>>> To IETF Ecrit WG >>>>>> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take the a= bove into consideration. >>>>>>=20 >>>>>> 3. Dates of next TSG CT WG1 meetings >>>>>> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, Korea >>>>>> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, Slovenia >>>>>>=20 >>>>>>=20 >>>>>> Attachments: >>>>>>=20 >>>>>> Response to LS on NG eCall support for the EU >>>>>> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3gpp= -tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-attachment-1.= pdf >>>>>>=20 >>>>>>=20 >>>>>> NOTICE TO RECIPIENT: This email, including attachments, may contain i= nformation which is confidential, proprietary, attorney-client privileged an= d/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 s= hall 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 recipie= nt of this message, be advised that any dissemination, distribution, or use o= f the contents of this message is strictly prohibited. If you received this m= essage in error, please notify us immediately by return email and permanentl= y delete all copies of the original email and any attached documentation fro= m any computer or other media. >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>> In the United States the majority undertakes to supply a multitude of >>> ready-made opinions for the use of individuals, who are thus relieved >> > from the necessity of forming opinions of their own >>> --Alexis de Tocqueville >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The ignorance of how to use new knowledge stockpiles exponentially. > --Marshall McLuhan From nobody Wed Mar 23 02:07: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 3C44C12DB89 for ; Wed, 23 Mar 2016 02:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9IjIVaTI96T8 for ; Wed, 23 Mar 2016 02:07:46 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0493E12DB90 for ; Wed, 23 Mar 2016 02:07:44 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-f0-56f25cdf672b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.DD.23401.FDC52F65; Wed, 23 Mar 2016 10:07:43 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.201]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 10:07:42 +0100 From: Ivo Sedlacek To: James Winterbottom , Randall Gellens Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRhJJhZcycb8DUB0eLEdfJ/r4PM59mHu+AgACb6XA= Date: Wed, 23 Mar 2016 09:07:41 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011635D09C@ESESSMB301.ericsson.se> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> <6A2536DC-A795-47A6-B03E-3AB5318C0563@gmail.com> In-Reply-To: <6A2536DC-A795-47A6-B03E-3AB5318C0563@gmail.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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7me79mE9hBu97pSzubfrJYjG/8zS7 xbSTl5ktGhc9ZbXYcOobi8X3512MDmweU35vZPXYOesuu8eSJT+ZPHY0PGf2mLXzCYvH1juP WQLYorhsUlJzMstSi/TtErgyFp7ez1bwLrti0dvHzA2MPZldjJwcEgImErua9zND2GISF+6t Z+ti5OIQEjjMKPF+9gIoZwmjxIJZB1lBqtgE9CQmbjkCZosIpEms/NrNClLELHCVUeLwi32M IAlhgTiJ3bv/MEMUxUs8aJsJZVtJPP3fygZiswioSjze2s4EYvMK+Eqc/bkULC4ksIZZ4sL8 QBCbU8BWYtXJJywgNqOArMTVP71g85kFxCVuPZnPBHG2gMSSPeehXhCVePn4HyuErShxdfpy oBoOoHpNifW79CFaFSWmdD9kh1grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFhfn phsZ6aUWZSYXF+fn6eWllmxiBMbjwS2/rXYwHnzueIhRgINRiYe34NzHMCHWxLLiytxDjBIc zEoivPOiP4UJ8aYkVlalFuXHF5XmpBYfYpTmYFES52X7dDlMSCA9sSQ1OzW1ILUIJsvEwSnV wMgWsmDe8jtyr2fVHU16Ei4WuE7KNts0KbhrJ0fDgzuzm74wP/t+IG7dwgX+aRP2vsjS89VV XZryO/Gxxz+pLevlrr18Or3+lBRLU/pC9gKWhCMfd4jzHbvT5nO+8r/EzeNB55wVJiaHKp1Q MWIpMT35dQnTIfdFGt/NYm7b/tI01/uczNqqtlGJpTgj0VCLuag4EQAHqM9TwwIAAA== Archived-At: Cc: "Rosen, Brian" , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 23 Mar 2016 09:07:58 -0000 SGVsbG8sDQoNCkNvdWxkIEVDUklUIHdhaXQgd2l0aCBXR0xDIHVudGlsIFNlcHRlbWJlciAyMDE2 IHdoZW4gM0dQUCBDVDEgd29yayBpcyBzdXBwb3NlZCB0byBiZSBjb21wbGV0ZWQ/IFRoYXQncyBv bmx5IDYgbW9udGhzIGF3YXkuDQoNCk1vcmVvdmVyLCAzR1BQIGFyY2hpdGVjdHVyZSB3b3JrIGlz IHNjaGVkdWxlZCB0byBjb21wbGV0ZSBpbiBKdW5lIDIwMTYgYWNjb3JkaW5nIHRvIHN0YWdlLTIg V0lEIGh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL3RzZ19zYS9UU0dfU0EvVFNHU183MC9Eb2NzL1NQ LTE1MDYyMy56aXAgKFNBIzcyIHRha2VzIHBsYWNlIGluIGJldHdlZW4gMjAxNuKAkTA24oCRMTUg YW5kIDIwMTbigJEwNuKAkTE3IGFjY29yZGluZyB0byBodHRwOi8vd3d3LjNncHAub3JnL0R5bmFS ZXBvcnQvTWVldGluZ3MtU1AuaHRtKSBhbmQgbW9zdCBvZiB0aGUgaW1wYWN0cyBvbiB0ZWNobmlj YWwgc29sdXRpb24gb2YgZUNhbGwgc2hvdWxkIGJlIGtub3duIGF0IHRoYXQgdGltZS4NCg0KR2l2 ZW4gdGhhdCB0aGUgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCBpcyBzdXBwb3NlZCB0byBjb3ZlciAz R1BQIHJlcXVpcmVtZW50cywgLi4uLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFY3JpdCBbbWFpbHRvOmVjcml0LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW1lcyBXaW50ZXJib3R0b20NClNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMjMsIDIwMTYgMTozOSBBTQ0KVG86IFJhbmRhbGwgR2VsbGVucw0KQ2M6 IFJvc2VuLCBCcmlhbjsgTWFyYyBMaW5zbmVyOyBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9u IHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24gTGlzdDsgQmVuIENhbXBiZWxs DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJSZXNwb25zZSB0 byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUiDQoNCkkgYWdyZWUNCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQo+IE9uIDIzIE1hciAyMDE2LCBhdCAxMDoyNyBhbSwgUmFuZGFsbCBH ZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPiB3cm90ZToNCj4gDQo+IEkgdGhpbmsg aXQncyBiZXN0IHRvIG5vdCB0cnkgYW5kIGNvbnZleSBzdWNoIG1lc3NhZ2VzIGluIGxpYWlzb24g c3RhdGVtZW50cy4gIFRoZXJlIGFyZSBwZW9wbGUgYWN0aXZlIGluIGJvdGggU0RPcyB3aG8ga25v dyB3aGF0IGlzIGdvaW5nIG9uLiAgSXQgd291bGQgYmUgcG9pbnRsZXNzIGFuZCBjb3VudGVyLXBy b2R1Y3RpdmUgdG8gc3RpciB1cCBhIHBvbGl0aWNhbCBiYXR0bGUuDQo+IA0KPiBBdCAxMDoxMiBQ TSArMDAwMCAzLzIyLzE2LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4gDQo+PiBUaGUgcHJvYmxlbSBJ IGhhdmUgd2l0aCB0aGUgY3VycmVudCB0ZXh0IGlzIHRoYXQgaXQgc2F5cyB0byAzR1BQICJjaGFu Z2UgYWxsIHlvdSB3YW50LCB3ZSdsbCBjaGFuZ2Ugb3VycyB0byBtYXRjaCIuICBJIHdhbnQgdGhh dCB0byBiZSAid2Ugd2VudCBhaGVhZCwgcGxlYXNlIHRyeSB0byB1c2UgaXQiLg0KPj4gDQo+Pj4g T24gTWFyIDIyLCAyMDE2LCBhdCA1OjM3IFBNLCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFu ZHkucGVuc2l2ZS5vcmc+IHdyb3RlOg0KPj4+IA0KPj4+IEkgdGhpbmsgSmFtZXMgaGFzIGEgcG9p bnQsIGFuZCBCcmlhbidzIHN1Z2dlc3RlZCBjaGFuZ2UgaXNuJ3QgbmVlZGVkLg0KPj4+IA0KPj4+ IEF0IDY6NDEgQU0gKzExMDAgMy8yMy8xNiwgSmFtZXMgV2ludGVyYm90dG9tIHdyb3RlOg0KPj4+ IA0KPj4+PiBUaGF0IHNvdW5kcyBhIGxpdHRsZSBwcm92b2NhdGl2ZSB0byBtZS4NCj4+Pj4gDQo+ Pj4+IA0KPj4+Pj4gT24gMjMgTWFyIDIwMTYsIGF0IDU6MTYgYW0sIFJvc2VuLCBCcmlhbiA8QnJp YW4uUm9zZW5AbmV1c3Rhci5iaXo+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBDYW4gSSBzdWdnZXN0 IGEgcmV3b3JkIG9mIHRoZSAzcmQgcGFyYWdyYXBoLg0KPj4+Pj4gDQo+Pj4+PiAiSWYgM0dQUCBm aW5kcyBpdCBuZWNlc3NhcnkgdG8gaW50cm9kdWNlIGFuIGluY29tcGF0aWJpbGl0eSBiZXR3ZWVu IHRoaXMgZG9jdW1lbnQsIGFzIGZpbmFsbHkgcHVibGlzaGVkLCBhbmQgaXRzIHdvcmssIHdlIHJl cXVlc3QgdGhhdCB5b3UgaW5mb3JtIHVzIG9mIHN1Y2ggYW4gaXNzdWUgc28gdGhhdCB3ZSBjYW4g ZXZhbHVhdGUgaXRzIGVmZmVjdCBvbiBvdXIgZG9jdW1lbnQgYW5kIGNvbnNpZGVyIGFueSByZXZp c2lvbnMgdGhhdCBtYXkgYmUgbmVlZGVkLCBmb2xsb3dpbmcgbm9ybWFsIElFVEYgcHJvY2Vzc2Vz LiINCj4+Pj4+IA0KPj4+Pj4gQnJpYW4NCj4+Pj4+IA0KPj4+Pj4+IE9uIE1hciAyMSwgMjAxNiwg YXQgNTozNSBQTSwgUm9nZXIgTWFyc2hhbGwgPFJvZ2VyLk1hcnNoYWxsQGNvbXRlY2h0ZWwuY29t PiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBQcm9wb3NlZCBMaWFpc29uIHJlc3BvbnNlOg0KPj4+ Pj4+IA0KPj4+Pj4+IFRoZSBJRVRGIEVDUklUIHdvcmtpbmcgZ3JvdXAgd291bGQgbGlrZSB0byB0 aGFuayAzR1BQIFRTRyBDVCBXRzEgZm9yIHRoZWlyIHJlc3BvbnNlLCBURG9jIEMxLTE2MDc2NCwg cmVmZXJlbmNpbmcgTFMgKEMxLTE1MjY0NCkgb24gdGhlIHRvcGljIG9mIE5HIGVDYWxsIHN1cHBv cnQgZm9yIHRoZSBFVS4NCj4+Pj4+PiBUaGUgRUNSSVQgd29ya2luZyBncm91cCBkaXNjdXNzZWQg eW91ciBsaWFpc29uIGFzIGl0IGFwcGxpZXMgdG8gdGhlIElFVEYgZHJhZnQtaWV0Zi1lY3JpdC1l Y2FsbCBkb2N1bWVudCBhbmQgcmVhY2hlZCB0aGUgZm9sbG93aW5nIGNvbmNsdXNpb25zOiAgR2l2 ZW4gdGhhdCAzR1BQIGlzIG5vdCBzY2hlZHVsZWQgdG8gZmluaXNoIHRoZWlyIHN0YWdlLTMgd29y ayBmb3IgZUNhbGwgaW4gSU1TIHVudGlsIEp1bmUgMjAxNywgYXMgcGFydCBvZiBSZWxlYXNlIDE0 LCB3ZSB3aWxsIGNvbnRpbnVlIHByb2dyZXNzaW5nIHRoZXNlIGRyYWZ0cyB0byBJRVRGIGxhc3Qg Y2FsbCBhcyBjdXJyZW50bHkgc2NoZWR1bGVkLg0KPj4+Pj4+IA0KPj4+Pj4+IFdlIGFsc28gYWNr bm93bGVkZ2UgdGhhdCBkdXJpbmcgM0dQUCdzIGRldmVsb3BtZW50IHBoYXNlLCBzb21lIGRpZmZl cmVuY2VzIG1heSBvY2N1ciBiZXR3ZWVuIHRoYXQgd2hpY2ggaXMgb3V0bGluZWQgd2l0aGluIHRo ZSBleGlzdGluZyBkcmFmdC1pZXRmLWVjcml0LWVjYWxsIGFuZCB0aGF0IHdoaWNoIGVtZXJnZXMg ZnJvbSB0aGUgM0dQUCB3b3JrLiBUaGUgSUVURiBwcm9jZXNzIGFsbG93cyBmb3IgUkZDcyB0byBi ZSByZXZpc2VkIGluIHRoZSBldmVudCBvZiBjaGFuZ2VzIGluIHRlY2hub2xvZ3kuDQo+Pj4+Pj4g DQo+Pj4+Pj4gV2UnbGwgY29sbGVjdCB3ZyBtZW1iZXIgY29tbWVudHMgb3ZlciB0aGUgbmV4dCBm ZXcgZGF5cyBhbmQgd2lsbCB0aGVuIG1vdmUgdG8gc2VuZCBvdXQgdGhlIG9mZmljaWFsIHJlc3Bv bnNlIHRvIDNHUFAuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUm9nZXIgTWFyc2hhbGwNCj4+ Pj4+PiBSb2dlci5tYXJzaGFsbEBjb210ZWNodGVsLmNvbQ0KPj4+Pj4+IE1hcmMgTGluc25lcg0K Pj4+Pj4+IG1saW5zbmVyQGNpc2NvLmNvbQ0KPj4+Pj4+IEVDUklUIENoYWlycw0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTog Um9nZXIgTWFyc2hhbGwNCj4+Pj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDIxLCAyMDE2IDE6MjQg UE0NCj4+Pj4+PiBUbzogRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0 IFRlY2hub2xvZ2llcyANCj4+Pj4+PiBEaXNjdXNzaW9uIExpc3QNCj4+Pj4+PiBDYzogTWFyYyBM aW5zbmVyOyBBbGlzc2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwNCj4+Pj4+PiBTdWJqZWN0OiBSRTog TmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9y dCBmb3IgdGhlIEVVIg0KPj4+Pj4+IA0KPj4+Pj4+IEVDUklUIFdHOg0KPj4+Pj4+IA0KPj4+Pj4+ IFRoZSBjaGFpcnMgaGF2ZSByZXZpZXdlZCB0aGUgdGhyZWFkIGNvbmNlcm5pbmcgcHJvY2Vzc2lu ZyBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTA1IGFuZCBkcmFmdC1pZXRmLWVjcml0LWNhci1jcmFz aC0wNSBhcyB3ZWxsIGFzIHRoZSBtb3N0IHJlY2VudCBsaWFpc29uIHJlY2VpdmVkIGZyb20gM0dQ UCBvbiAxLzMxLzIwMTYgYW5kIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3JzLiAgR2l2ZW4gdGhh dCAzR1BQIGlzIG5vdCBzY2hlZHVsZWQgdG8gZmluaXNoIHRoZWlyIHdvcmsgdW50aWwgSnVuZSAy MDE3LCB3ZSB3aWxsIGNvbnRpbnVlIHByb2dyZXNzaW5nIHRoZXNlIGRyYWZ0cyB0byBJRVRGIGxh c3QgY2FsbCBhcyBzY2hlZHVsZWQuIFdlIGFsc28gcmVtaW5kIHRoZSB3b3JraW5nIGdyb3VwIHRo YXQgdGhlIElFVEYgcHJvY2VzcyBhbGxvd3MgY2hhbmdlcyB0byBSRkMgcHVibGljYXRpb25zLCBl LmcuLCBpc3N1YW5jZSBvZiBiaXMgUkZDcyBpbiB0aGUgZXZlbnQgdGhhdCBjaGFuZ2VzIGluIHRl Y2hub2xvZ3kgcmVzdWx0IGluIHRoZSBuZWVkIHRvIG1ha2Ugc3VjaCBhIGNoYW5nZS4gU3VjaCBk b2N1bWVudHMgd291bGQgYmUgaW4gc2NvcGUgb2YgdGhlIGN1cnJlbnQgRUNSSVQgY2hhcnRlciwg c2hvdWxkIHRoZSBuZWVkIGFyaXNlLg0KPj4+Pj4+IA0KPj4+Pj4+IFdlIHdpbGwgc2VuZCBhIHJl cGx5IGxpYWlzb24gc3RhdGVtZW50IHRvIDNHUFAgdG8gaW5mb3JtIHRoZW0gb2YgdGhlIHN0YXR1 cyBvZiB0aGUgZG9jdW1lbnRzIGFmdGVyIHdlIHBvc3QgdGhlIHByb3Bvc2VkIGxpYWlzb24gdGV4 dCB0byB0aGUgbGlzdCwgd2hpY2ggd2lsbCBoYXBwZW4gc2hvcnRseS4NCj4+Pj4+PiANCj4+Pj4+ PiANCj4+Pj4+PiBSb2dlciBNYXJzaGFsbCAocm9nZXIubWFyc2hhbGxAY29tdGVjaHRlbC5jb20p ICAmDQo+PiAgPj4+PiBNYXJjIExpbnNuZXIgKG1saW5zbmVyQGNpc2NvLmNvbSkNCj4+Pj4+PiBF Y3JpdCBjaGFpcnMNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1l bnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddDQo+Pj4+Pj4gU2VudDogU3VuZGF5LCBKYW51 YXJ5IDMxLCAyMDE2IDQ6MTMgUE0NCj4+Pj4+PiBUbzogUm9nZXIgTWFyc2hhbGw7IE1hcmMgTGlu c25lcg0KPj4+Pj4+IENjOiBCYXJyeSBMZWliYTsgTWFyYyBMaW5zbmVyOyBFbWVyZ2VuY3kgQ29u dGV4dCBSZXNvbHV0aW9uIHdpdGggDQo+Pj4+Pj4gSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1 c3Npb24gTGlzdDsgDQo+Pj4+Pj4gZ2VvcmcubWF5ZXIuaHVhd2VpQGdteC5jb207IDNHUFBMaWFp c29uQGV0c2kub3JnOyBSb2dlciBNYXJzaGFsbDsgDQo+Pj4+Pj4gQWxpc3NhIENvb3BlcjsgQmVu IENhbXBiZWxsDQo+Pj4+Pj4gU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9u c2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KPj4+Pj4+IA0KPj4+Pj4+ IFRpdGxlOiBSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUgU3Vi bWlzc2lvbiANCj4+Pj4+PiBEYXRlOiAyMDE2LTAxLTMxIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFn ZTogDQo+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTIvDQo+ Pj4+Pj4gDQo+Pj4+Pj4gRnJvbTogIlN1c2FubmEgS29vaXN0cmEiIDwzR1BQTGlhaXNvbkBldHNp Lm9yZz4NCj4+Pj4+PiBUbzogTWFyYyBMaW5zbmVyIDxtYXJjLmxpbnNuZXJAY2lzY28uY29tPiwg Um9nZXIgTWFyc2hhbGwgDQo+Pj4+Pj4gPHJtYXJzaGFsbEB0ZWxlY29tc3lzLmNvbT4NCj4+Pj4+ PiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPixNYXJjIExpbnNuZXIg PG1hcmMubGluc25lckBjaXNjby5jb20+LEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPixB bGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sUm9nZXIgTWFyc2hhbGwgPHJtYXJzaGFs bEB0ZWxlY29tc3lzLmNvbT4sRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVy bmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3QgPGVjcml0QGlldGYub3JnPiwgUmVzcG9u c2UgQ29udGFjdHM6IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tLCAzR1BQTGlhaXNvbkBldHNp Lm9yZyBUZWNobmljYWwgQ29udGFjdHM6DQo+Pj4+Pj4gUHVycG9zZTogSW4gcmVzcG9uc2UNCj4+ Pj4+PiANCj4+Pj4+PiBSZWZlcmVuY2VkIGxpYWlzb246IExpYWlzb24gU3RhdGVtZW50IG9uIE5H IGVDYWxsIHN1cHBvcnQgZm9yIHRoZSANCj4+Pj4+PiBFVSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9saWFpc29uLzE0MTIvKQ0KPj4+Pj4+IA0KPj4+Pj4+IEJvZHk6IDEuIE92ZXJhbGwg ZGVzY3JpcHRpb24NCj4+Pj4+PiAzR1BQIFRTRyBDVCBXRzEgd291bGQgbGlrZSB0byB0aGFuayBJ RVRGIEVjcml0IFdHIGZvciB0aGUgTFMgKEMxLTE1MjY0NCkgb24gTkcgZUNhbGwgc3VwcG9ydCBm b3IgdGhlIEVVLg0KPj4+Pj4+IDNHUFAgVFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIGluZm9ybSBJ RVRGIEVjcml0IFdHIHRoYXQgM0dQUCBUU0cgQ1QgV0cxIHdpbGwgd29yayBvbiBzdGFnZS0zIGZv ciBlQ2FsbCBpbiBJTVMgaW4gUmVsZWFzZSAxNCAoZW5kaW5nIGluIEp1bmUgMjAxNyksIHN1Ympl Y3QgdG8gM0dQUCBUU0cgU0EgV0cyIGNvbXBsZXRpb24gb2YgdGhlIG5vcm1hdGl2ZSBzdGFnZS0y IHdvcmsgYW5kIGFwcHJvdmFsIG9mIGEgM0dQUCBUU0cgQ1Qgd29yayBpdGVtLg0KPj4+Pj4+IDNH UFAgVFNHIENUIFdHMSBzdGFnZS0zIHdvcmsgbWlnaHQgcmVzdWx0IGluIHByb3RvY29sIHJlcXVp cmVtZW50cyBkZXZpYXRpbmcgb3IgY29uZmxpY3Rpbmcgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9u IG9mIElFVEYgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCwgYW5kIHRodXMgbWlnaHQgaW1wYWN0IElF VEYgd29yay4NCj4+Pj4+PiANCj4+Pj4+PiAyLiBBY3Rpb25zDQo+Pj4+Pj4gVG8gSUVURiBFY3Jp dCBXRw0KPj4+Pj4+IEFDVElPTjogM0dQUCBUU0cgQ1QgV0cxIHJlc3BlY3RmdWxseSBhc2tzIElF VEYgRWNyaXQgV0cgdG8gdGFrZSB0aGUgYWJvdmUgaW50byBjb25zaWRlcmF0aW9uLg0KPj4+Pj4+ IA0KPj4+Pj4+IDMuIERhdGVzIG9mIG5leHQgVFNHIENUIFdHMSBtZWV0aW5ncw0KPj4+Pj4+IFRT RyBDVCBXRzEgTWVldGluZyA5NiAgICAxNS0xOSBGZWJydWFyeSAyMDE2ICAgIEplanUgSXNsYW5k LCBLb3JlYQ0KPj4+Pj4+IFRTRyBDVCBXRzEgTWVldGluZyA5NyAgICAxMS0xNSBBcHJpbCAyMDE2 ICAgIExqdWJsamFuYSwgU2xvdmVuaWENCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBBdHRhY2ht ZW50czoNCj4+Pj4+PiANCj4+Pj4+PiAgUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9y dCBmb3IgdGhlIEVVIA0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVu dHMvTElBSVNPTi9saWFpc29uLTIwMTYtMDEtMzEtDQo+Pj4+Pj4gM2dwcC10c2djdC1jdDEtZWNy aXQtcmVzcG9uc2UtdG8tbHMtb24tbmctZWNhbGwtc3VwcG9ydC1mb3ItdGhlLWUNCj4+Pj4+PiB1 LWF0dGFjaG1lbnQtMS5wZGYNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBOT1RJQ0UgVE8gUkVD SVBJRU5UOiBUaGlzIGVtYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIG1heSBjb250YWluIGlu Zm9ybWF0aW9uIHdoaWNoIGlzIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRhcnksIGF0dG9ybmV5LWNs aWVudCBwcml2aWxlZ2VkIGFuZC9vciBjb250cm9sbGVkIHVuZGVyIFUuUy4gZXhwb3J0IGxhd3Mg YW5kIHJlZ3VsYXRpb25zIGFuZCBtYXkgYmUgcmVzdHJpY3RlZCBmcm9tIGRpc2Nsb3N1cmUgYnkg YXBwbGljYWJsZSBTdGF0ZSBhbmQgRmVkZXJhbCBsYXcuIE5vdGhpbmcgaW4gdGhpcyBlbWFpbCBz aGFsbCBjcmVhdGUgYW55IGxlZ2FsIGJpbmRpbmcgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBhcnRp ZXMgdW5sZXNzIGV4cHJlc3NseSBzdGF0ZWQgaGVyZWluIGFuZCBwcm92aWRlZCBieSBhbiBhdXRo b3JpemVkIHJlcHJlc2VudGF0aXZlIG9mIENvbXRlY2ggVGVsZWNvbW11bmljYXRpb25zIENvcnAu IG9yIGl0cyBzdWJzaWRpYXJpZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBtZXNzYWdlLCBiZSBhZHZpc2VkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiwgb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXR1cm4gZW1haWwgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBlbWFpbCBhbmQgYW55IGF0dGFj aGVkIGRvY3VtZW50YXRpb24gZnJvbSBhbnkgY29tcHV0ZXIgb3Igb3RoZXIgbWVkaWEuDQo+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+IA0KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IEVjcml0 IG1haWxpbmcgbGlzdA0KPj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEVjcml0IG1haWxpbmcgbGlz dA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiBSYW5kYWxsIEdlbGxlbnMN Cj4+PiBPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNw ZWFrIGZvciBteXNlbGYgb25seQ0KPj4+IC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVk IHRhZzogLS0tLS0tLS0tLS0tLS0tIEluIHRoZSBVbml0ZWQgDQo+Pj4gU3RhdGVzIHRoZSBtYWpv cml0eSB1bmRlcnRha2VzIHRvIHN1cHBseSBhIG11bHRpdHVkZSBvZiByZWFkeS1tYWRlIA0KPj4+ IG9waW5pb25zIGZvciB0aGUgdXNlIG9mIGluZGl2aWR1YWxzLCB3aG8gYXJlIHRodXMgcmVsaWV2 ZWQNCj4+ICA+IGZyb20gdGhlIG5lY2Vzc2l0eSBvZiBmb3JtaW5nIG9waW5pb25zIG9mIHRoZWly IG93bg0KPj4+ICAgIC0tQWxleGlzIGRlIFRvY3F1ZXZpbGxlDQo+Pj4gDQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBFY3JpdCBtYWlsaW5n IGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gDQo+IA0KPiAtLQ0KPiBSYW5kYWxsIEdlbGxlbnMNCj4gT3Bp bmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3Ig bXlzZWxmIG9ubHkNCj4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0t LS0tLS0tLS0tLS0gVGhlIGlnbm9yYW5jZSBvZiANCj4gaG93IHRvIHVzZSBuZXcga25vd2xlZGdl IHN0b2NrcGlsZXMgZXhwb25lbnRpYWxseS4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tTWFyc2hhbGwgTWNMdWhhbg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3Jp dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From nobody Wed Mar 23 02:09: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 D6AB512DB98 for ; Wed, 23 Mar 2016 02:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 EMhka8X-Y3lQ for ; Wed, 23 Mar 2016 02:09:01 -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 5327312DB77 for ; Wed, 23 Mar 2016 02:08:46 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 84B2FECC4C0CF for ; Wed, 23 Mar 2016 09:08:42 +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 u2N98idV032533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Mar 2016 09:08:44 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2N98is7012424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Mar 2016 10:08:44 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 23 Mar 2016 10:08:44 +0100 From: "Drage, Keith (Nokia - GB)" To: Emergency Context Resolution with Internet Technologies Discussion List Thread-Topic: draft-ietf-ecrit-ecall-07 Thread-Index: AdGEk+Vc+sNTdvJIT+qv7STjGEz7/g== Date: Wed, 23 Mar 2016 09:08:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB0D00@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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: [Ecrit] draft-ietf-ecrit-ecall-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 09:09:03 -0000 >From my knowledge of the 3GPP work so far (essentially the stage 1 service = requirements) I would note at least some things with this draft: 1) The service URN is meant to identify the resource that is required by th= e requesting user. In a 3GPP environment that resource will be an entity th= at supports both some data means of transmission (I can guess it will somet= imes be a body but that discussion has not reached that point yet), but wil= l also be required to support an in-band form of the existing CS supported = MSD. This is for interoperability and migration purposes. Any URN that does= not identify support of both resources cannot be used in a 3GPP environmen= t. 2) Roaming is important in 3GPP. Some countries do not support ecall (and t= herefore do not provided dedicated ecall PSAPs). The proposed URNs will the= refore, by virtue of stripping unrecognized subtypes, end up on the normal = PSAPs. That could be OK if there is a voice media included. However there i= s a data only case in ecall which will not be directly usable by a standard= PSAP - it will essentially be a silent emergency call. Note that the attit= ude of regulatory authorities to calls they cannot handle varies from count= ry to country (some countries might even prosecute the generator of such ca= lls). Mechanisms may need to be in place to prevent such ecalls when in reg= ulatory regimes where ecall is not supported. 3) The 3GPP requirements for test calls are not yet clear (at least to me).= What is clear is that if they are treated as normal calls then they will n= ot "MNOs can treat a vehicle call in the "test" service URN in a way that t= ests as much functionality as desired" because much of the network equipmen= t will not be the same. Further for a roaming user, the test call may not e= ven succeed. Further it is not yet clear (to me) whether all 3GPP ecall equ= ipment and network providers will support non-emergency calls from an ecall= device. Given that resolving these will be different from any published IETF docume= nt based on the current draft and may well cause deployment problems in som= e regulatory areas if the current IETF document is implemented, my proposal= is simple... Regards Keith Drage From nobody Wed Mar 23 02:09: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 46AA012DB81 for ; Wed, 23 Mar 2016 02:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 7lJzH_9pTUCB for ; Wed, 23 Mar 2016 02:09:29 -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 86EC712DB9C for ; Wed, 23 Mar 2016 02:09:11 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B2C363D059658; Wed, 23 Mar 2016 09:09:05 +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 u2N997Da032622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2016 09:09:07 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 u2N996bd012664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Mar 2016 10:09:07 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 23 Mar 2016 10:09:01 +0100 From: "Drage, Keith (Nokia - GB)" To: "EXT Rosen, Brian" , Randall Gellens Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRg7nP6xl9dijRD0q6VsNh0ZrXH59ltb+AgAAXmQCAACB4gIAACdkAgAAppHA= Date: Wed, 23 Mar 2016 09:09:01 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB0D08@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 23 Mar 2016 09:09:32 -0000 UGVyc29uYWxseSBJIGZpbmQgdGhlIGVudGlyZSBMUyB0aGF0IHlvdSB3YW50IGluZGljYXRpbmcg dGhhdCB0aGUgSUVURiBkcmFmdCBDQU5OT1QgYmUgdXNlZCBpbiBhIDNHUFAgZW52aXJvbm1lbnQu DQoNCkkgYWxzbyBmaW5kIHRoZSBkcmFmdCByZXNwb25zZSBpbmRpY2F0aW5nIGEgZGVjaXNpb24g bWFkZSBieSB0aGUgV0cgY2hhaXJzIGFuZCBBZHMgdGhhdCBicmVha3MgdGhlIHNwaXJpdCBvZiBS RkMgMzExMy4NCg0KSSB0aGVyZWZvcmUgb2JqZWN0IHRvIHRoZSBwb3NpdGlvbiBhZG9wdGVkIGJ5 IHRoZSBBZHMgYW5kIFdHIGNoYWlycy4NCg0KUmVnYXJkcw0KDQpLZWl0aA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRVhUIFJvc2VuLCBCcmlhbg0KU2VudDogMjIgTWFyY2ggMjAxNiAy MjoxMw0KVG86IFJhbmRhbGwgR2VsbGVucw0KQ2M6IEJlbiBDYW1wYmVsbDsgTWFyYyBMaW5zbmVy OyBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVz IERpc2N1c3Npb24gTGlzdA0KU3ViamVjdDogUmU6IFtFY3JpdF0gTmV3IExpYWlzb24gU3RhdGVt ZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KDQpU aGUgcHJvYmxlbSBJIGhhdmUgd2l0aCB0aGUgY3VycmVudCB0ZXh0IGlzIHRoYXQgaXQgc2F5cyB0 byAzR1BQIOKAnGNoYW5nZSBhbGwgeW91IHdhbnQsIHdl4oCZbGwgY2hhbmdlIG91cnMgdG8gbWF0 Y2jigJ0uICBJIHdhbnQgdGhhdCB0byBiZSDigJx3ZSB3ZW50IGFoZWFkLCBwbGVhc2UgdHJ5IHRv IHVzZSBpdOKAnS4NCg0KPiBPbiBNYXIgMjIsIDIwMTYsIGF0IDU6MzcgUE0sIFJhbmRhbGwgR2Vs bGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4gd3JvdGU6DQo+IA0KPiBJIHRoaW5rIEph bWVzIGhhcyBhIHBvaW50LCBhbmQgQnJpYW4ncyBzdWdnZXN0ZWQgY2hhbmdlIGlzbid0IG5lZWRl ZC4NCj4gDQo+IEF0IDY6NDEgQU0gKzExMDAgMy8yMy8xNiwgSmFtZXMgV2ludGVyYm90dG9tIHdy b3RlOg0KPiANCj4+IFRoYXQgc291bmRzIGEgbGl0dGxlIHByb3ZvY2F0aXZlIHRvIG1lLg0KPj4g DQo+PiANCj4+PiBPbiAyMyBNYXIgMjAxNiwgYXQgNToxNiBhbSwgUm9zZW4sIEJyaWFuIDxCcmlh bi5Sb3NlbkBuZXVzdGFyLmJpej4gd3JvdGU6DQo+Pj4gDQo+Pj4gQ2FuIEkgc3VnZ2VzdCBhIHJl d29yZCBvZiB0aGUgM3JkIHBhcmFncmFwaC4NCj4+PiANCj4+PiAiSWYgM0dQUCBmaW5kcyBpdCBu ZWNlc3NhcnkgdG8gaW50cm9kdWNlIGFuIGluY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoaXMgZG9j dW1lbnQsIGFzIGZpbmFsbHkgcHVibGlzaGVkLCBhbmQgaXRzIHdvcmssIHdlIHJlcXVlc3QgdGhh dCB5b3UgaW5mb3JtIHVzIG9mIHN1Y2ggYW4gaXNzdWUgc28gdGhhdCB3ZSBjYW4gZXZhbHVhdGUg aXRzIGVmZmVjdCBvbiBvdXIgZG9jdW1lbnQgYW5kIGNvbnNpZGVyIGFueSByZXZpc2lvbnMgdGhh dCBtYXkgYmUgbmVlZGVkLCBmb2xsb3dpbmcgbm9ybWFsIElFVEYgcHJvY2Vzc2VzLiINCj4+PiAN Cj4+PiBCcmlhbg0KPj4+IA0KPj4+PiBPbiBNYXIgMjEsIDIwMTYsIGF0IDU6MzUgUE0sIFJvZ2Vy IE1hcnNoYWxsIDxSb2dlci5NYXJzaGFsbEBjb210ZWNodGVsLmNvbT4gd3JvdGU6DQo+Pj4+IA0K Pj4+PiBQcm9wb3NlZCBMaWFpc29uIHJlc3BvbnNlOg0KPj4+PiANCj4+Pj4gVGhlIElFVEYgRUNS SVQgd29ya2luZyBncm91cCB3b3VsZCBsaWtlIHRvIHRoYW5rIDNHUFAgVFNHIENUIFdHMSBmb3Ig dGhlaXIgcmVzcG9uc2UsIFREb2MgQzEtMTYwNzY0LCByZWZlcmVuY2luZyBMUyAoQzEtMTUyNjQ0 KSBvbiB0aGUgdG9waWMgb2YgTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVLiANCj4+Pj4gVGhl IEVDUklUIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2VkIHlvdXIgbGlhaXNvbiBhcyBpdCBhcHBsaWVz IHRvIHRoZSBJRVRGIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwgZG9jdW1lbnQgYW5kIHJlYWNoZWQg dGhlIGZvbGxvd2luZyBjb25jbHVzaW9uczogIEdpdmVuIHRoYXQgM0dQUCBpcyBub3Qgc2NoZWR1 bGVkIHRvIGZpbmlzaCB0aGVpciBzdGFnZS0zIHdvcmsgZm9yIGVDYWxsIGluIElNUyB1bnRpbCBK dW5lIDIwMTcsIGFzIHBhcnQgb2YgUmVsZWFzZSAxNCwgd2Ugd2lsbCBjb250aW51ZSBwcm9ncmVz c2luZyB0aGVzZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwgYXMgY3VycmVudGx5IHNjaGVkdWxl ZC4NCj4+Pj4gDQo+Pj4+IFdlIGFsc28gYWNrbm93bGVkZ2UgdGhhdCBkdXJpbmcgM0dQUCdzIGRl dmVsb3BtZW50IHBoYXNlLCBzb21lIGRpZmZlcmVuY2VzIG1heSBvY2N1ciBiZXR3ZWVuIHRoYXQg d2hpY2ggaXMgb3V0bGluZWQgd2l0aGluIHRoZSBleGlzdGluZyBkcmFmdC1pZXRmLWVjcml0LWVj YWxsIGFuZCB0aGF0IHdoaWNoIGVtZXJnZXMgZnJvbSB0aGUgM0dQUCB3b3JrLiBUaGUgSUVURiBw cm9jZXNzIGFsbG93cyBmb3IgUkZDcyB0byBiZSByZXZpc2VkIGluIHRoZSBldmVudCBvZiBjaGFu Z2VzIGluIHRlY2hub2xvZ3kuDQo+Pj4+IA0KPj4+PiBXZSdsbCBjb2xsZWN0IHdnIG1lbWJlciBj b21tZW50cyBvdmVyIHRoZSBuZXh0IGZldyBkYXlzIGFuZCB3aWxsIHRoZW4gbW92ZSB0byBzZW5k IG91dCB0aGUgb2ZmaWNpYWwgcmVzcG9uc2UgdG8gM0dQUC4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBS b2dlciBNYXJzaGFsbA0KPj4+PiBSb2dlci5tYXJzaGFsbEBjb210ZWNodGVsLmNvbQ0KPj4+PiBN YXJjIExpbnNuZXINCj4+Pj4gbWxpbnNuZXJAY2lzY28uY29tDQo+Pj4+IEVDUklUIENoYWlycw0K Pj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206 IFJvZ2VyIE1hcnNoYWxsDQo+Pj4+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMjEsIDIwMTYgMToyNCBQ TQ0KPj4+PiBUbzogRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRl Y2hub2xvZ2llcyANCj4+Pj4gRGlzY3Vzc2lvbiBMaXN0DQo+Pj4+IENjOiBNYXJjIExpbnNuZXI7 IEFsaXNzYSBDb29wZXI7IEJlbiBDYW1wYmVsbA0KPj4+PiBTdWJqZWN0OiBSRTogTmV3IExpYWlz b24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhl IEVVIg0KPj4+PiANCj4+Pj4gRUNSSVQgV0c6DQo+Pj4+IA0KPj4+PiBUaGUgY2hhaXJzIGhhdmUg cmV2aWV3ZWQgdGhlIHRocmVhZCBjb25jZXJuaW5nIHByb2Nlc3NpbmcgZHJhZnQtaWV0Zi1lY3Jp dC1lY2FsbC0wNSBhbmQgZHJhZnQtaWV0Zi1lY3JpdC1jYXItY3Jhc2gtMDUgYXMgd2VsbCBhcyB0 aGUgbW9zdCByZWNlbnQgbGlhaXNvbiByZWNlaXZlZCBmcm9tIDNHUFAgb24gMS8zMS8yMDE2IGFu ZCBkaXNjdXNzZWQgd2l0aCB0aGUgYXV0aG9ycy4gIEdpdmVuIHRoYXQgM0dQUCBpcyBub3Qgc2No ZWR1bGVkIHRvIGZpbmlzaCB0aGVpciB3b3JrIHVudGlsIEp1bmUgMjAxNywgd2Ugd2lsbCBjb250 aW51ZSBwcm9ncmVzc2luZyB0aGVzZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwgYXMgc2NoZWR1 bGVkLiBXZSBhbHNvIHJlbWluZCB0aGUgd29ya2luZyBncm91cCB0aGF0IHRoZSBJRVRGIHByb2Nl c3MgYWxsb3dzIGNoYW5nZXMgdG8gUkZDIHB1YmxpY2F0aW9ucywgZS5nLiwgaXNzdWFuY2Ugb2Yg YmlzIFJGQ3MgaW4gdGhlIGV2ZW50IHRoYXQgY2hhbmdlcyBpbiB0ZWNobm9sb2d5IHJlc3VsdCBp biB0aGUgbmVlZCB0byBtYWtlIHN1Y2ggYSBjaGFuZ2UuIFN1Y2ggZG9jdW1lbnRzIHdvdWxkIGJl IGluIHNjb3BlIG9mIHRoZSBjdXJyZW50IEVDUklUIGNoYXJ0ZXIsIHNob3VsZCB0aGUgbmVlZCBh cmlzZS4NCj4+Pj4gDQo+Pj4+IFdlIHdpbGwgc2VuZCBhIHJlcGx5IGxpYWlzb24gc3RhdGVtZW50 IHRvIDNHUFAgdG8gaW5mb3JtIHRoZW0gb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGFm dGVyIHdlIHBvc3QgdGhlIHByb3Bvc2VkIGxpYWlzb24gdGV4dCB0byB0aGUgbGlzdCwgd2hpY2gg d2lsbCBoYXBwZW4gc2hvcnRseS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBSb2dlciBNYXJzaGFsbCAo cm9nZXIubWFyc2hhbGxAY29tdGVjaHRlbC5jb20pICAmIE1hcmMgTGluc25lciANCj4+Pj4gKG1s aW5zbmVyQGNpc2NvLmNvbSkgRWNyaXQgY2hhaXJzDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IExpYWlzb24gU3RhdGVtZW50 IE1hbmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddDQo+Pj4+IFNlbnQ6IFN1bmRh eSwgSmFudWFyeSAzMSwgMjAxNiA0OjEzIFBNDQo+Pj4+IFRvOiBSb2dlciBNYXJzaGFsbDsgTWFy YyBMaW5zbmVyDQo+Pj4+IENjOiBCYXJyeSBMZWliYTsgTWFyYyBMaW5zbmVyOyBFbWVyZ2VuY3kg Q29udGV4dCBSZXNvbHV0aW9uIHdpdGggDQo+Pj4+IEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNj dXNzaW9uIExpc3Q7IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tOyANCj4+Pj4gM0dQUExpYWlz b25AZXRzaS5vcmc7IFJvZ2VyIE1hcnNoYWxsOyBBbGlzc2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwN Cj4+Pj4gU3ViamVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24g TkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KPj4+PiANCj4+Pj4gVGl0bGU6IFJlc3BvbnNl IHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSBTdWJtaXNzaW9uIA0KPj4+PiBE YXRlOiAyMDE2LTAxLTMxIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogDQo+Pj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDUyLw0KPj4+PiANCj4+Pj4gRnJvbTogIlN1 c2FubmEgS29vaXN0cmEiIDwzR1BQTGlhaXNvbkBldHNpLm9yZz4NCj4+Pj4gVG86IE1hcmMgTGlu c25lciA8bWFyYy5saW5zbmVyQGNpc2NvLmNvbT4sIFJvZ2VyIE1hcnNoYWxsIA0KPj4+PiA8cm1h cnNoYWxsQHRlbGVjb21zeXMuY29tPg0KPj4+PiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFA Y29tcHV0ZXIub3JnPixNYXJjIExpbnNuZXIgPG1hcmMubGluc25lckBjaXNjby5jb20+LEJlbiBD YW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPixBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5p bj4sUm9nZXIgTWFyc2hhbGwgPHJtYXJzaGFsbEB0ZWxlY29tc3lzLmNvbT4sRW1lcmdlbmN5IENv bnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExp c3QgPGVjcml0QGlldGYub3JnPiwgUmVzcG9uc2UgQ29udGFjdHM6IGdlb3JnLm1heWVyLmh1YXdl aUBnbXguY29tLCAzR1BQTGlhaXNvbkBldHNpLm9yZyBUZWNobmljYWwgQ29udGFjdHM6DQo+Pj4+ IFB1cnBvc2U6IEluIHJlc3BvbnNlDQo+Pj4+IA0KPj4+PiBSZWZlcmVuY2VkIGxpYWlzb246IExp YWlzb24gU3RhdGVtZW50IG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSANCj4+Pj4gRVUgKGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDEyLykNCj4+Pj4gDQo+Pj4+IEJv ZHk6IDEuIE92ZXJhbGwgZGVzY3JpcHRpb24NCj4+Pj4gM0dQUCBUU0cgQ1QgV0cxIHdvdWxkIGxp a2UgdG8gdGhhbmsgSUVURiBFY3JpdCBXRyBmb3IgdGhlIExTIChDMS0xNTI2NDQpIG9uIE5HIGVD YWxsIHN1cHBvcnQgZm9yIHRoZSBFVS4NCj4+Pj4gM0dQUCBUU0cgQ1QgV0cxIHdvdWxkIGxpa2Ug dG8gaW5mb3JtIElFVEYgRWNyaXQgV0cgdGhhdCAzR1BQIFRTRyBDVCBXRzEgd2lsbCB3b3JrIG9u IHN0YWdlLTMgZm9yIGVDYWxsIGluIElNUyBpbiBSZWxlYXNlIDE0IChlbmRpbmcgaW4gSnVuZSAy MDE3KSwgc3ViamVjdCB0byAzR1BQIFRTRyBTQSBXRzIgY29tcGxldGlvbiBvZiB0aGUgbm9ybWF0 aXZlIHN0YWdlLTIgd29yayBhbmQgYXBwcm92YWwgb2YgYSAzR1BQIFRTRyBDVCB3b3JrIGl0ZW0u DQo+Pj4+IDNHUFAgVFNHIENUIFdHMSBzdGFnZS0zIHdvcmsgbWlnaHQgcmVzdWx0IGluIHByb3Rv Y29sIHJlcXVpcmVtZW50cyBkZXZpYXRpbmcgb3IgY29uZmxpY3Rpbmcgd2l0aCB0aGUgY3VycmVu dCB2ZXJzaW9uIG9mIElFVEYgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCwgYW5kIHRodXMgbWlnaHQg aW1wYWN0IElFVEYgd29yay4NCj4+Pj4gDQo+Pj4+IDIuIEFjdGlvbnMNCj4+Pj4gVG8gSUVURiBF Y3JpdCBXRw0KPj4+PiBBQ1RJT046IDNHUFAgVFNHIENUIFdHMSByZXNwZWN0ZnVsbHkgYXNrcyBJ RVRGIEVjcml0IFdHIHRvIHRha2UgdGhlIGFib3ZlIGludG8gY29uc2lkZXJhdGlvbi4NCj4+Pj4g DQo+Pj4+IDMuIERhdGVzIG9mIG5leHQgVFNHIENUIFdHMSBtZWV0aW5ncw0KPj4+PiBUU0cgQ1Qg V0cxIE1lZXRpbmcgOTYJMTUtMTkgRmVicnVhcnkgMjAxNglKZWp1IElzbGFuZCwgS29yZWENCj4+ Pj4gVFNHIENUIFdHMSBNZWV0aW5nIDk3CTExLTE1IEFwcmlsIDIwMTYJTGp1YmxqYW5hLCBTbG92 ZW5pYQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IEF0dGFjaG1lbnRzOg0KPj4+PiANCj4+Pj4gIFJlc3Bv bnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSANCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNi0wMS0zMS0z Zw0KPj4+PiBwcC10c2djdC1jdDEtZWNyaXQtcmVzcG9uc2UtdG8tbHMtb24tbmctZWNhbGwtc3Vw cG9ydC1mb3ItdGhlLWV1LWF0DQo+Pj4+IHRhY2htZW50LTEucGRmDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gTk9USUNFIFRPIFJFQ0lQSUVOVDogVGhpcyBlbWFpbCwgaW5jbHVkaW5nIGF0dGFjaG1lbnRz LCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB3aGljaCBpcyBjb25maWRlbnRpYWwsIHByb3ByaWV0 YXJ5LCBhdHRvcm5leS1jbGllbnQgcHJpdmlsZWdlZCBhbmQvb3IgY29udHJvbGxlZCB1bmRlciBV LlMuIGV4cG9ydCBsYXdzIGFuZCByZWd1bGF0aW9ucyBhbmQgbWF5IGJlIHJlc3RyaWN0ZWQgZnJv bSBkaXNjbG9zdXJlIGJ5IGFwcGxpY2FibGUgU3RhdGUgYW5kIEZlZGVyYWwgbGF3LiBOb3RoaW5n IGluIHRoaXMgZW1haWwgc2hhbGwgY3JlYXRlIGFueSBsZWdhbCBiaW5kaW5nIGFncmVlbWVudCBi ZXR3ZWVuIHRoZSBwYXJ0aWVzIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIGhlcmVpbiBhbmQgcHJv dmlkZWQgYnkgYW4gYXV0aG9yaXplZCByZXByZXNlbnRhdGl2ZSBvZiBDb210ZWNoIFRlbGVjb21t dW5pY2F0aW9ucyBDb3JwLiBvciBpdHMgc3Vic2lkaWFyaWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgbWVzc2FnZSwgYmUgYWR2aXNlZCB0aGF0IGFueSBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmV0dXJuIGVt YWlsIGFuZCBwZXJtYW5lbnRseSBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgZW1h aWwgYW5kIGFueSBhdHRhY2hlZCBkb2N1bWVudGF0aW9uIGZyb20gYW55IGNvbXB1dGVyIG9yIG90 aGVyIG1lZGlhLg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4+IA0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gRWNy aXQgbWFpbGluZyBsaXN0DQo+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVj cml0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0DQo+IA0KPiANCj4gLS0NCj4gUmFuZGFsbCBHZWxsZW5zDQo+IE9waW5pb25zIGFyZSBwZXJz b25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5DQo+ IC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tIElu IHRoZSBVbml0ZWQgDQo+IFN0YXRlcyB0aGUgbWFqb3JpdHkgdW5kZXJ0YWtlcyB0byBzdXBwbHkg YSBtdWx0aXR1ZGUgb2YgcmVhZHktbWFkZSANCj4gb3BpbmlvbnMgZm9yIHRoZSB1c2Ugb2YgaW5k aXZpZHVhbHMsIHdobyBhcmUgdGh1cyByZWxpZXZlZCBmcm9tIHRoZSANCj4gbmVjZXNzaXR5IG9m IGZvcm1pbmcgb3BpbmlvbnMgb2YgdGhlaXIgb3duDQo+ICAgIC0tQWxleGlzIGRlIFRvY3F1ZXZp bGxlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From nobody Wed Mar 23 16:07: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 9497012D9BA for ; Wed, 23 Mar 2016 16:07:42 -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=vx2TBmt6; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=eW3I3gsm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMigRNOsTmuD for ; Wed, 23 Mar 2016 16:07:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0F112D6B0 for ; Wed, 23 Mar 2016 16:07:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A6F0F20A0D for ; Wed, 23 Mar 2016 19:07:37 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 23 Mar 2016 19:07:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qV1hBtQePXRXCxVJ+2m/Yxhd/Iw=; b=vx2TBm t6IQ6z+dtzii5WQHvgqe6+nky5ckcHb17JeNo4NbVJMpNgsWYyg9S5e5nZQDINKa M/Ctj0BQ3U3UTgKyMBKba70Zs+BnePgq+0wZAdBEb8kgOszY5dYYSoWlnMIefFOt WDGJcC8QgjdNn52bTWQyD/ywN8I286wvLmXkg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qV1hBtQePXRXCxV J+2m/Yxhd/Iw=; b=eW3I3gsmNl1WwL8kIom2EdbuXR99jbL13A+wzUAUaXDsdob iwKkQuNADbbiSJD/LOLZoF/is8EFMJ0zX9+IKkE6COEA+Uvn3zIj3ypqH9sHobFt g9q7sbnBJI3svikIKuQdzY3ox3lskMrQYJEa+zGlfRamvpzcq9fEBjsBAaXc= X-Sasl-enc: Gejes6J+wljPr5YyUXheDQFc7LLLQxWOmHKW/BCjzfJL 1458774457 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id C79866800E1; Wed, 23 Mar 2016 19:07:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB0D08@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 23 Mar 2016 16:07:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <195736B5-92D0-400F-8A5D-252562E6D2DC@cooperw.in> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D08@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "Drage, Keith (Nokia - GB)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "EXT Rosen, Brian" , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 23 Mar 2016 23:07:42 -0000 Hi Keith, > On Mar 23, 2016, at 2:09 AM, Drage, Keith (Nokia - GB) = wrote: >=20 > Personally I find the entire LS that you want indicating that the IETF = draft CANNOT be used in a 3GPP environment. I don=E2=80=99t understand the statement above. Could you elaborate? = Where does the LS say that the I-Ds cannot be used by 3GPP? Thanks, Alissa >=20 > I also find the draft response indicating a decision made by the WG = chairs and Ads that breaks the spirit of RFC 3113. > I therefore object to the position adopted by the Ads and WG chairs. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of EXT Rosen, = Brian > Sent: 22 March 2016 22:13 > To: Randall Gellens > Cc: Ben Campbell; Marc Linsner; Emergency Context Resolution with = Internet Technologies Discussion List > Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG = eCall support for the EU" >=20 > The problem I have with the current text is that it says to 3GPP = =E2=80=9Cchange all you want, we=E2=80=99ll change ours to match=E2=80=9D.= I want that to be =E2=80=9Cwe went ahead, please try to use it=E2=80=9D.= >=20 >> On Mar 22, 2016, at 5:37 PM, Randall Gellens = wrote: >>=20 >> I think James has a point, and Brian's suggested change isn't needed. >>=20 >> At 6:41 AM +1100 3/23/16, James Winterbottom wrote: >>=20 >>> That sounds a little provocative to me. >>>=20 >>>=20 >>>> On 23 Mar 2016, at 5:16 am, Rosen, Brian = wrote: >>>>=20 >>>> Can I suggest a reword of the 3rd paragraph. >>>>=20 >>>> "If 3GPP finds it necessary to introduce an incompatibility between = this document, as finally published, and its work, we request that you = inform us of such an issue so that we can evaluate its effect on our = document and consider any revisions that may be needed, following normal = IETF processes." >>>>=20 >>>> Brian >>>>=20 >>>>> On Mar 21, 2016, at 5:35 PM, Roger Marshall = wrote: >>>>>=20 >>>>> Proposed Liaison response: >>>>>=20 >>>>> The IETF ECRIT working group would like to thank 3GPP TSG CT WG1 = for their response, TDoc C1-160764, referencing LS (C1-152644) on the = topic of NG eCall support for the EU.=20 >>>>> The ECRIT working group discussed your liaison as it applies to = the IETF draft-ietf-ecrit-ecall document and reached the following = conclusions: Given that 3GPP is not scheduled to finish their stage-3 = work for eCall in IMS until June 2017, as part of Release 14, we will = continue progressing these drafts to IETF last call as currently = scheduled. >>>>>=20 >>>>> We also acknowledge that during 3GPP's development phase, some = differences may occur between that which is outlined within the existing = draft-ietf-ecrit-ecall and that which emerges from the 3GPP work. The = IETF process allows for RFCs to be revised in the event of changes in = technology. >>>>>=20 >>>>> We'll collect wg member comments over the next few days and will = then move to send out the official response to 3GPP. >>>>>=20 >>>>>=20 >>>>> Roger Marshall >>>>> Roger.marshall@comtechtel.com >>>>> Marc Linsner >>>>> mlinsner@cisco.com >>>>> ECRIT Chairs >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Roger Marshall >>>>> Sent: Monday, March 21, 2016 1:24 PM >>>>> To: Emergency Context Resolution with Internet Technologies=20 >>>>> Discussion List >>>>> Cc: Marc Linsner; Alissa Cooper; Ben Campbell >>>>> Subject: RE: New Liaison Statement, "Response to LS on NG eCall = support for the EU" >>>>>=20 >>>>> ECRIT WG: >>>>>=20 >>>>> The chairs have reviewed the thread concerning processing = draft-ietf-ecrit-ecall-05 and draft-ietf-ecrit-car-crash-05 as well as = the most recent liaison received from 3GPP on 1/31/2016 and discussed = with the authors. Given that 3GPP is not scheduled to finish their work = until June 2017, we will continue progressing these drafts to IETF last = call as scheduled. We also remind the working group that the IETF = process allows changes to RFC publications, e.g., issuance of bis RFCs = in the event that changes in technology result in the need to make such = a change. Such documents would be in scope of the current ECRIT charter, = should the need arise. >>>>>=20 >>>>> We will send a reply liaison statement to 3GPP to inform them of = the status of the documents after we post the proposed liaison text to = the list, which will happen shortly. >>>>>=20 >>>>>=20 >>>>> Roger Marshall (roger.marshall@comtechtel.com) & Marc Linsner=20 >>>>> (mlinsner@cisco.com) Ecrit chairs >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] >>>>> Sent: Sunday, January 31, 2016 4:13 PM >>>>> To: Roger Marshall; Marc Linsner >>>>> Cc: Barry Leiba; Marc Linsner; Emergency Context Resolution with=20= >>>>> Internet Technologies Discussion List; georg.mayer.huawei@gmx.com;=20= >>>>> 3GPPLiaison@etsi.org; Roger Marshall; Alissa Cooper; Ben Campbell >>>>> Subject: New Liaison Statement, "Response to LS on NG eCall = support for the EU" >>>>>=20 >>>>> Title: Response to LS on NG eCall support for the EU Submission=20 >>>>> Date: 2016-01-31 URL of the IETF Web page:=20 >>>>> https://datatracker.ietf.org/liaison/1452/ >>>>>=20 >>>>> From: "Susanna Kooistra" <3GPPLiaison@etsi.org> >>>>> To: Marc Linsner , Roger Marshall=20 >>>>> >>>>> Cc: Barry Leiba ,Marc Linsner = ,Ben Campbell ,Alissa Cooper = ,Roger Marshall ,Emergency = Context Resolution with Internet Technologies Discussion List = , Response Contacts: georg.mayer.huawei@gmx.com, = 3GPPLiaison@etsi.org Technical Contacts: >>>>> Purpose: In response >>>>>=20 >>>>> Referenced liaison: Liaison Statement on NG eCall support for the=20= >>>>> EU (https://datatracker.ietf.org/liaison/1412/) >>>>>=20 >>>>> Body: 1. Overall description >>>>> 3GPP TSG CT WG1 would like to thank IETF Ecrit WG for the LS = (C1-152644) on NG eCall support for the EU. >>>>> 3GPP TSG CT WG1 would like to inform IETF Ecrit WG that 3GPP TSG = CT WG1 will work on stage-3 for eCall in IMS in Release 14 (ending in = June 2017), subject to 3GPP TSG SA WG2 completion of the normative = stage-2 work and approval of a 3GPP TSG CT work item. >>>>> 3GPP TSG CT WG1 stage-3 work might result in protocol requirements = deviating or conflicting with the current version of IETF = draft-ietf-ecrit-ecall, and thus might impact IETF work. >>>>>=20 >>>>> 2. Actions >>>>> To IETF Ecrit WG >>>>> ACTION: 3GPP TSG CT WG1 respectfully asks IETF Ecrit WG to take = the above into consideration. >>>>>=20 >>>>> 3. Dates of next TSG CT WG1 meetings >>>>> TSG CT WG1 Meeting 96 15-19 February 2016 Jeju Island, = Korea >>>>> TSG CT WG1 Meeting 97 11-15 April 2016 Ljubljana, = Slovenia >>>>>=20 >>>>>=20 >>>>> Attachments: >>>>>=20 >>>>> Response to LS on NG eCall support for the EU=20 >>>>> = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-01-31-3g >>>>> = pp-tsgct-ct1-ecrit-response-to-ls-on-ng-ecall-support-for-the-eu-at >>>>> tachment-1.pdf >>>>>=20 >>>>>=20 >>>>> NOTICE TO RECIPIENT: This email, including attachments, may = contain information which is confidential, proprietary, attorney-client = privileged and/or controlled under U.S. export laws and regulations and = may be restricted from disclosure by applicable State and Federal law. = Nothing in this email shall create any legal binding agreement between = the parties unless expressly stated herein and provided by an 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 >>>>=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: --------------- In the United=20= >> States the majority undertakes to supply a multitude of ready-made=20 >> opinions for the use of individuals, who are thus relieved from the=20= >> necessity of forming opinions of their own >> --Alexis de Tocqueville >>=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 Mar 23 17:04: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 15F7212D99B for ; Wed, 23 Mar 2016 17:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 3T9x_gSfxNyW for ; Wed, 23 Mar 2016 17:04:15 -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 2FC9C12D988 for ; Wed, 23 Mar 2016 17:04:15 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 838B5A07539E; Thu, 24 Mar 2016 00:04: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 u2O04C0Z012648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 00:04:12 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2O04AkV018960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Mar 2016 01:04:11 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 01:04:10 +0100 From: "Drage, Keith (Nokia - GB)" To: EXT Alissa Cooper Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRg7nP6xl9dijRD0q6VsNh0ZrXH59ltb+AgAAXmQCAACB4gIAACdkAgAAppHCAAXgnAIAAHidA Date: Thu, 24 Mar 2016 00:04:10 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB1707@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D08@FR712WXCHMBA11.zeu.alcatel-lucent.com> <195736B5-92D0-400F-8A5D-252562E6D2DC@cooperw.in> In-Reply-To: <195736B5-92D0-400F-8A5D-252562E6D2DC@cooperw.in> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "EXT Rosen, Brian" , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 24 Mar 2016 00:04:18 -0000 V2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5IGlzLCB0aGF0IGJ5IHByb2NlZWRpbmcsIHRoYXQgSUVU RiBhcmUgcHV0dGluZyBibG9ja3MgaW4gdGhlIHdheSBvZiAzR1BQIGRlZmluaW5nIHRoZWlyIHNl cnZpY2UgZm9yIHRoZWlyIG93biB1c2UuDQoNCkl0IGlzIGNsZWFyIHRvIG1lIHRoYXQgdGhlIG9u bHkgYXBwbGljYWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50IGlzIGluIGEgM0dQUCBlbnZpcm9ubWVu dCwgYW5kIDNHUFAgbmVlZHMgdG8gbWFrZSB0aGVpciBvd24gZGVjaXNpb25zIGFzIHRvIGhvdyB0 aGUgc2VydmljZSBvcGVyYXRlcy4gVGhlcmVmb3JlIHRoZSAzR1BQIHdvcmsgaGFzIHRvIGNvbWUg Zmlyc3QuDQoNCkkgaWRlbnRpZmllZCBpbiBhIHNlcGFyYXRlIG1haWwgYSBudW1iZXIgb2YgaXNz dWVzLg0KDQpJZiBmb3IgZXhhbXBsZSB0aGUgc2VydmljZSBVUk4gZGVmaW5lZCBieSB0aGUgSUVU RiBkcmFmdCBkb2VzIG5vdCBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgM0dQUCwgdGhlbiAzR1BQ IHdpbGwgbmVlZCB0byByZXF1ZXN0IGl0cyBvd24sIGFuZCBwb3RlbnRpYWxseSBibG9jayB0aGUg SUVURiBkZWZpbmVkIG9uZXMgYXMgdGhleSBjb3VsZCBjYXVzZSBoYXJtLCBhbmQgLyBvciBkYW5n ZXIgdG8gbGlmZSAoZHVlIGZhaWxlZCBjYWxscykgaW4gY2VydGFpbiByZWd1bGF0b3J5IGVudmly b25tZW50cy4NCg0KUmVnYXJkcw0KDQpLZWl0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogRVhUIEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0gDQpT ZW50OiAyMyBNYXJjaCAyMDE2IDIzOjA4DQpUbzogRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKQ0K Q2M6IEVYVCBSb3NlbiwgQnJpYW47IFJhbmRhbGwgR2VsbGVuczsgQmVuIENhbXBiZWxsOyBNYXJj IExpbnNuZXI7IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNo bm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBOZXcgTGlhaXNv biBTdGF0ZW1lbnQsICJSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUg RVUiDQoNCkhpIEtlaXRoLA0KDQo+IE9uIE1hciAyMywgMjAxNiwgYXQgMjowOSBBTSwgRHJhZ2Us IEtlaXRoIChOb2tpYSAtIEdCKSA8a2VpdGguZHJhZ2VAbm9raWEuY29tPiB3cm90ZToNCj4gDQo+ IFBlcnNvbmFsbHkgSSBmaW5kIHRoZSBlbnRpcmUgTFMgdGhhdCB5b3Ugd2FudCBpbmRpY2F0aW5n IHRoYXQgdGhlIElFVEYgZHJhZnQgQ0FOTk9UIGJlIHVzZWQgaW4gYSAzR1BQIGVudmlyb25tZW50 Lg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgc3RhdGVtZW50IGFib3ZlLiBDb3VsZCB5b3Ug ZWxhYm9yYXRlPyBXaGVyZSBkb2VzIHRoZSBMUyBzYXkgdGhhdCB0aGUgSS1EcyBjYW5ub3QgYmUg dXNlZCBieSAzR1BQPw0KDQpUaGFua3MsDQpBbGlzc2ENCg0KPiANCj4gSSBhbHNvIGZpbmQgdGhl IGRyYWZ0IHJlc3BvbnNlIGluZGljYXRpbmcgYSBkZWNpc2lvbiBtYWRlIGJ5IHRoZSBXRyBjaGFp cnMgYW5kIEFkcyB0aGF0IGJyZWFrcyB0aGUgc3Bpcml0IG9mIFJGQyAzMTEzLg0KDQo+IEkgdGhl cmVmb3JlIG9iamVjdCB0byB0aGUgcG9zaXRpb24gYWRvcHRlZCBieSB0aGUgQWRzIGFuZCBXRyBj aGFpcnMuDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBLZWl0aA0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRVhUIFJvc2VuLCANCj4gQnJpYW4NCj4gU2VudDogMjIgTWFyY2ggMjAx NiAyMjoxMw0KPiBUbzogUmFuZGFsbCBHZWxsZW5zDQo+IENjOiBCZW4gQ2FtcGJlbGw7IE1hcmMg TGluc25lcjsgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIA0KPiBJbnRlcm5ldCBU ZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0DQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIE5ldyBM aWFpc29uIFN0YXRlbWVudCwgIlJlc3BvbnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9y IHRoZSBFVSINCj4gDQo+IFRoZSBwcm9ibGVtIEkgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IHRleHQg aXMgdGhhdCBpdCBzYXlzIHRvIDNHUFAg4oCcY2hhbmdlIGFsbCB5b3Ugd2FudCwgd2XigJlsbCBj aGFuZ2Ugb3VycyB0byBtYXRjaOKAnS4gIEkgd2FudCB0aGF0IHRvIGJlIOKAnHdlIHdlbnQgYWhl YWQsIHBsZWFzZSB0cnkgdG8gdXNlIGl04oCdLg0KPiANCj4+IE9uIE1hciAyMiwgMjAxNiwgYXQg NTozNyBQTSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPiB3cm90 ZToNCj4+IA0KPj4gSSB0aGluayBKYW1lcyBoYXMgYSBwb2ludCwgYW5kIEJyaWFuJ3Mgc3VnZ2Vz dGVkIGNoYW5nZSBpc24ndCBuZWVkZWQuDQo+PiANCj4+IEF0IDY6NDEgQU0gKzExMDAgMy8yMy8x NiwgSmFtZXMgV2ludGVyYm90dG9tIHdyb3RlOg0KPj4gDQo+Pj4gVGhhdCBzb3VuZHMgYSBsaXR0 bGUgcHJvdm9jYXRpdmUgdG8gbWUuDQo+Pj4gDQo+Pj4gDQo+Pj4+IE9uIDIzIE1hciAyMDE2LCBh dCA1OjE2IGFtLCBSb3NlbiwgQnJpYW4gPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PiB3cm90ZToN Cj4+Pj4gDQo+Pj4+IENhbiBJIHN1Z2dlc3QgYSByZXdvcmQgb2YgdGhlIDNyZCBwYXJhZ3JhcGgu DQo+Pj4+IA0KPj4+PiAiSWYgM0dQUCBmaW5kcyBpdCBuZWNlc3NhcnkgdG8gaW50cm9kdWNlIGFu IGluY29tcGF0aWJpbGl0eSBiZXR3ZWVuIHRoaXMgZG9jdW1lbnQsIGFzIGZpbmFsbHkgcHVibGlz aGVkLCBhbmQgaXRzIHdvcmssIHdlIHJlcXVlc3QgdGhhdCB5b3UgaW5mb3JtIHVzIG9mIHN1Y2gg YW4gaXNzdWUgc28gdGhhdCB3ZSBjYW4gZXZhbHVhdGUgaXRzIGVmZmVjdCBvbiBvdXIgZG9jdW1l bnQgYW5kIGNvbnNpZGVyIGFueSByZXZpc2lvbnMgdGhhdCBtYXkgYmUgbmVlZGVkLCBmb2xsb3dp bmcgbm9ybWFsIElFVEYgcHJvY2Vzc2VzLiINCj4+Pj4gDQo+Pj4+IEJyaWFuDQo+Pj4+IA0KPj4+ Pj4gT24gTWFyIDIxLCAyMDE2LCBhdCA1OjM1IFBNLCBSb2dlciBNYXJzaGFsbCA8Um9nZXIuTWFy c2hhbGxAY29tdGVjaHRlbC5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBQcm9wb3NlZCBMaWFp c29uIHJlc3BvbnNlOg0KPj4+Pj4gDQo+Pj4+PiBUaGUgSUVURiBFQ1JJVCB3b3JraW5nIGdyb3Vw IHdvdWxkIGxpa2UgdG8gdGhhbmsgM0dQUCBUU0cgQ1QgV0cxIGZvciB0aGVpciByZXNwb25zZSwg VERvYyBDMS0xNjA3NjQsIHJlZmVyZW5jaW5nIExTIChDMS0xNTI2NDQpIG9uIHRoZSB0b3BpYyBv ZiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUuIA0KPj4+Pj4gVGhlIEVDUklUIHdvcmtpbmcg Z3JvdXAgZGlzY3Vzc2VkIHlvdXIgbGlhaXNvbiBhcyBpdCBhcHBsaWVzIHRvIHRoZSBJRVRGIGRy YWZ0LWlldGYtZWNyaXQtZWNhbGwgZG9jdW1lbnQgYW5kIHJlYWNoZWQgdGhlIGZvbGxvd2luZyBj b25jbHVzaW9uczogIEdpdmVuIHRoYXQgM0dQUCBpcyBub3Qgc2NoZWR1bGVkIHRvIGZpbmlzaCB0 aGVpciBzdGFnZS0zIHdvcmsgZm9yIGVDYWxsIGluIElNUyB1bnRpbCBKdW5lIDIwMTcsIGFzIHBh cnQgb2YgUmVsZWFzZSAxNCwgd2Ugd2lsbCBjb250aW51ZSBwcm9ncmVzc2luZyB0aGVzZSBkcmFm dHMgdG8gSUVURiBsYXN0IGNhbGwgYXMgY3VycmVudGx5IHNjaGVkdWxlZC4NCj4+Pj4+IA0KPj4+ Pj4gV2UgYWxzbyBhY2tub3dsZWRnZSB0aGF0IGR1cmluZyAzR1BQJ3MgZGV2ZWxvcG1lbnQgcGhh c2UsIHNvbWUgZGlmZmVyZW5jZXMgbWF5IG9jY3VyIGJldHdlZW4gdGhhdCB3aGljaCBpcyBvdXRs aW5lZCB3aXRoaW4gdGhlIGV4aXN0aW5nIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwgYW5kIHRoYXQg d2hpY2ggZW1lcmdlcyBmcm9tIHRoZSAzR1BQIHdvcmsuIFRoZSBJRVRGIHByb2Nlc3MgYWxsb3dz IGZvciBSRkNzIHRvIGJlIHJldmlzZWQgaW4gdGhlIGV2ZW50IG9mIGNoYW5nZXMgaW4gdGVjaG5v bG9neS4NCj4+Pj4+IA0KPj4+Pj4gV2UnbGwgY29sbGVjdCB3ZyBtZW1iZXIgY29tbWVudHMgb3Zl ciB0aGUgbmV4dCBmZXcgZGF5cyBhbmQgd2lsbCB0aGVuIG1vdmUgdG8gc2VuZCBvdXQgdGhlIG9m ZmljaWFsIHJlc3BvbnNlIHRvIDNHUFAuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gUm9nZXIgTWFy c2hhbGwNCj4+Pj4+IFJvZ2VyLm1hcnNoYWxsQGNvbXRlY2h0ZWwuY29tDQo+Pj4+PiBNYXJjIExp bnNuZXINCj4+Pj4+IG1saW5zbmVyQGNpc2NvLmNvbQ0KPj4+Pj4gRUNSSVQgQ2hhaXJzDQo+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206 IFJvZ2VyIE1hcnNoYWxsDQo+Pj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDIxLCAyMDE2IDE6MjQg UE0NCj4+Pj4+IFRvOiBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQg VGVjaG5vbG9naWVzIA0KPj4+Pj4gRGlzY3Vzc2lvbiBMaXN0DQo+Pj4+PiBDYzogTWFyYyBMaW5z bmVyOyBBbGlzc2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwNCj4+Pj4+IFN1YmplY3Q6IFJFOiBOZXcg TGlhaXNvbiBTdGF0ZW1lbnQsICJSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZv ciB0aGUgRVUiDQo+Pj4+PiANCj4+Pj4+IEVDUklUIFdHOg0KPj4+Pj4gDQo+Pj4+PiBUaGUgY2hh aXJzIGhhdmUgcmV2aWV3ZWQgdGhlIHRocmVhZCBjb25jZXJuaW5nIHByb2Nlc3NpbmcgZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbC0wNSBhbmQgZHJhZnQtaWV0Zi1lY3JpdC1jYXItY3Jhc2gtMDUgYXMg d2VsbCBhcyB0aGUgbW9zdCByZWNlbnQgbGlhaXNvbiByZWNlaXZlZCBmcm9tIDNHUFAgb24gMS8z MS8yMDE2IGFuZCBkaXNjdXNzZWQgd2l0aCB0aGUgYXV0aG9ycy4gIEdpdmVuIHRoYXQgM0dQUCBp cyBub3Qgc2NoZWR1bGVkIHRvIGZpbmlzaCB0aGVpciB3b3JrIHVudGlsIEp1bmUgMjAxNywgd2Ug d2lsbCBjb250aW51ZSBwcm9ncmVzc2luZyB0aGVzZSBkcmFmdHMgdG8gSUVURiBsYXN0IGNhbGwg YXMgc2NoZWR1bGVkLiBXZSBhbHNvIHJlbWluZCB0aGUgd29ya2luZyBncm91cCB0aGF0IHRoZSBJ RVRGIHByb2Nlc3MgYWxsb3dzIGNoYW5nZXMgdG8gUkZDIHB1YmxpY2F0aW9ucywgZS5nLiwgaXNz dWFuY2Ugb2YgYmlzIFJGQ3MgaW4gdGhlIGV2ZW50IHRoYXQgY2hhbmdlcyBpbiB0ZWNobm9sb2d5 IHJlc3VsdCBpbiB0aGUgbmVlZCB0byBtYWtlIHN1Y2ggYSBjaGFuZ2UuIFN1Y2ggZG9jdW1lbnRz IHdvdWxkIGJlIGluIHNjb3BlIG9mIHRoZSBjdXJyZW50IEVDUklUIGNoYXJ0ZXIsIHNob3VsZCB0 aGUgbmVlZCBhcmlzZS4NCj4+Pj4+IA0KPj4+Pj4gV2Ugd2lsbCBzZW5kIGEgcmVwbHkgbGlhaXNv biBzdGF0ZW1lbnQgdG8gM0dQUCB0byBpbmZvcm0gdGhlbSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBk b2N1bWVudHMgYWZ0ZXIgd2UgcG9zdCB0aGUgcHJvcG9zZWQgbGlhaXNvbiB0ZXh0IHRvIHRoZSBs aXN0LCB3aGljaCB3aWxsIGhhcHBlbiBzaG9ydGx5Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFJv Z2VyIE1hcnNoYWxsIChyb2dlci5tYXJzaGFsbEBjb210ZWNodGVsLmNvbSkgICYgTWFyYyBMaW5z bmVyDQo+Pj4+PiAobWxpbnNuZXJAY2lzY28uY29tKSBFY3JpdCBjaGFpcnMNCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9t OiBMaWFpc29uIFN0YXRlbWVudCBNYW5hZ2VtZW50IFRvb2wgW21haWx0bzpsc210QGlldGYub3Jn XQ0KPj4+Pj4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDMxLCAyMDE2IDQ6MTMgUE0NCj4+Pj4+IFRv OiBSb2dlciBNYXJzaGFsbDsgTWFyYyBMaW5zbmVyDQo+Pj4+PiBDYzogQmFycnkgTGVpYmE7IE1h cmMgTGluc25lcjsgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIA0KPj4+Pj4gSW50 ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24gTGlzdDsgZ2VvcmcubWF5ZXIuaHVhd2VpQGdt eC5jb207IA0KPj4+Pj4gM0dQUExpYWlzb25AZXRzaS5vcmc7IFJvZ2VyIE1hcnNoYWxsOyBBbGlz c2EgQ29vcGVyOyBCZW4gQ2FtcGJlbGwNCj4+Pj4+IFN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRl bWVudCwgIlJlc3BvbnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSINCj4+ Pj4+IA0KPj4+Pj4gVGl0bGU6IFJlc3BvbnNlIHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9y IHRoZSBFVSBTdWJtaXNzaW9uDQo+Pj4+PiBEYXRlOiAyMDE2LTAxLTMxIFVSTCBvZiB0aGUgSUVU RiBXZWIgcGFnZTogDQo+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24v MTQ1Mi8NCj4+Pj4+IA0KPj4+Pj4gRnJvbTogIlN1c2FubmEgS29vaXN0cmEiIDwzR1BQTGlhaXNv bkBldHNpLm9yZz4NCj4+Pj4+IFRvOiBNYXJjIExpbnNuZXIgPG1hcmMubGluc25lckBjaXNjby5j b20+LCBSb2dlciBNYXJzaGFsbCANCj4+Pj4+IDxybWFyc2hhbGxAdGVsZWNvbXN5cy5jb20+DQo+ Pj4+PiBDYzogQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPixNYXJjIExpbnNu ZXIgPG1hcmMubGluc25lckBjaXNjby5jb20+LEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29t PixBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sUm9nZXIgTWFyc2hhbGwgPHJtYXJz aGFsbEB0ZWxlY29tc3lzLmNvbT4sRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIElu dGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3QgPGVjcml0QGlldGYub3JnPiwgUmVz cG9uc2UgQ29udGFjdHM6IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tLCAzR1BQTGlhaXNvbkBl dHNpLm9yZyBUZWNobmljYWwgQ29udGFjdHM6DQo+Pj4+PiBQdXJwb3NlOiBJbiByZXNwb25zZQ0K Pj4+Pj4gDQo+Pj4+PiBSZWZlcmVuY2VkIGxpYWlzb246IExpYWlzb24gU3RhdGVtZW50IG9uIE5H IGVDYWxsIHN1cHBvcnQgZm9yIHRoZSANCj4+Pj4+IEVVIChodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTQxMi8pDQo+Pj4+PiANCj4+Pj4+IEJvZHk6IDEuIE92ZXJhbGwgZGVz Y3JpcHRpb24NCj4+Pj4+IDNHUFAgVFNHIENUIFdHMSB3b3VsZCBsaWtlIHRvIHRoYW5rIElFVEYg RWNyaXQgV0cgZm9yIHRoZSBMUyAoQzEtMTUyNjQ0KSBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0 aGUgRVUuDQo+Pj4+PiAzR1BQIFRTRyBDVCBXRzEgd291bGQgbGlrZSB0byBpbmZvcm0gSUVURiBF Y3JpdCBXRyB0aGF0IDNHUFAgVFNHIENUIFdHMSB3aWxsIHdvcmsgb24gc3RhZ2UtMyBmb3IgZUNh bGwgaW4gSU1TIGluIFJlbGVhc2UgMTQgKGVuZGluZyBpbiBKdW5lIDIwMTcpLCBzdWJqZWN0IHRv IDNHUFAgVFNHIFNBIFdHMiBjb21wbGV0aW9uIG9mIHRoZSBub3JtYXRpdmUgc3RhZ2UtMiB3b3Jr IGFuZCBhcHByb3ZhbCBvZiBhIDNHUFAgVFNHIENUIHdvcmsgaXRlbS4NCj4+Pj4+IDNHUFAgVFNH IENUIFdHMSBzdGFnZS0zIHdvcmsgbWlnaHQgcmVzdWx0IGluIHByb3RvY29sIHJlcXVpcmVtZW50 cyBkZXZpYXRpbmcgb3IgY29uZmxpY3Rpbmcgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIElF VEYgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbCwgYW5kIHRodXMgbWlnaHQgaW1wYWN0IElFVEYgd29y ay4NCj4+Pj4+IA0KPj4+Pj4gMi4gQWN0aW9ucw0KPj4+Pj4gVG8gSUVURiBFY3JpdCBXRw0KPj4+ Pj4gQUNUSU9OOiAzR1BQIFRTRyBDVCBXRzEgcmVzcGVjdGZ1bGx5IGFza3MgSUVURiBFY3JpdCBX RyB0byB0YWtlIHRoZSBhYm92ZSBpbnRvIGNvbnNpZGVyYXRpb24uDQo+Pj4+PiANCj4+Pj4+IDMu IERhdGVzIG9mIG5leHQgVFNHIENUIFdHMSBtZWV0aW5ncw0KPj4+Pj4gVFNHIENUIFdHMSBNZWV0 aW5nIDk2CTE1LTE5IEZlYnJ1YXJ5IDIwMTYJSmVqdSBJc2xhbmQsIEtvcmVhDQo+Pj4+PiBUU0cg Q1QgV0cxIE1lZXRpbmcgOTcJMTEtMTUgQXByaWwgMjAxNglManVibGphbmEsIFNsb3ZlbmlhDQo+ Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQXR0YWNobWVudHM6DQo+Pj4+PiANCj4+Pj4+IFJlc3BvbnNl IHRvIExTIG9uIE5HIGVDYWxsIHN1cHBvcnQgZm9yIHRoZSBFVSANCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTYtMDEtMzEtMw0K Pj4+Pj4gZyANCj4+Pj4+IHBwLXRzZ2N0LWN0MS1lY3JpdC1yZXNwb25zZS10by1scy1vbi1uZy1l Y2FsbC1zdXBwb3J0LWZvci10aGUtZXUtYQ0KPj4+Pj4gdA0KPj4+Pj4gdGFjaG1lbnQtMS5wZGYN Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBOT1RJQ0UgVE8gUkVDSVBJRU5UOiBUaGlzIGVtYWlsLCBp bmNsdWRpbmcgYXR0YWNobWVudHMsIG1heSBjb250YWluIGluZm9ybWF0aW9uIHdoaWNoIGlzIGNv bmZpZGVudGlhbCwgcHJvcHJpZXRhcnksIGF0dG9ybmV5LWNsaWVudCBwcml2aWxlZ2VkIGFuZC9v ciBjb250cm9sbGVkIHVuZGVyIFUuUy4gZXhwb3J0IGxhd3MgYW5kIHJlZ3VsYXRpb25zIGFuZCBt YXkgYmUgcmVzdHJpY3RlZCBmcm9tIGRpc2Nsb3N1cmUgYnkgYXBwbGljYWJsZSBTdGF0ZSBhbmQg RmVkZXJhbCBsYXcuIE5vdGhpbmcgaW4gdGhpcyBlbWFpbCBzaGFsbCBjcmVhdGUgYW55IGxlZ2Fs IGJpbmRpbmcgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBhcnRpZXMgdW5sZXNzIGV4cHJlc3NseSBz dGF0ZWQgaGVyZWluIGFuZCBwcm92aWRlZCBieSBhbiBhdXRob3JpemVkIHJlcHJlc2VudGF0aXZl IG9mIENvbXRlY2ggVGVsZWNvbW11bmljYXRpb25zIENvcnAuIG9yIGl0cyBzdWJzaWRpYXJpZXMu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlLCBi ZSBhZHZpc2VkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgdXNlIG9m IHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1l ZGlhdGVseSBieSByZXR1cm4gZW1haWwgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBlbWFpbCBhbmQgYW55IGF0dGFjaGVkIGRvY3VtZW50YXRpb24gZnJv bSBhbnkgY29tcHV0ZXIgb3Igb3RoZXIgbWVkaWEuDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ Pj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lY3JpdA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+IEVjcml0QGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQN Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+IEVjcml0QGlldGYub3JnDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4gDQo+PiANCj4+IC0tDQo+ PiBSYW5kYWxsIEdlbGxlbnMNCj4+IE9waW5pb25zIGFyZSBwZXJzb25hbDsgICAgZmFjdHMgYXJl IHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5DQo+PiAtLS0tLS0tLS0tLS0tLSBS YW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLSBJbiB0aGUgVW5pdGVkIA0KPj4g U3RhdGVzIHRoZSBtYWpvcml0eSB1bmRlcnRha2VzIHRvIHN1cHBseSBhIG11bHRpdHVkZSBvZiBy ZWFkeS1tYWRlIA0KPj4gb3BpbmlvbnMgZm9yIHRoZSB1c2Ugb2YgaW5kaXZpZHVhbHMsIHdobyBh cmUgdGh1cyByZWxpZXZlZCBmcm9tIHRoZSANCj4+IG5lY2Vzc2l0eSBvZiBmb3JtaW5nIG9waW5p b25zIG9mIHRoZWlyIG93bg0KPj4gICAtLUFsZXhpcyBkZSBUb2NxdWV2aWxsZQ0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRWNyaXQg bWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFp bGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCg0K From nobody Thu Mar 24 00:55: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 8251E12D0C6 for ; Thu, 24 Mar 2016 00:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KSlqAIXFgHuP for ; Thu, 24 Mar 2016 00:55:54 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9409512D5B3 for ; Thu, 24 Mar 2016 00:55:53 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-12-56f39d870505 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.87.23401.78D93F65; Thu, 24 Mar 2016 08:55:51 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.201]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Thu, 24 Mar 2016 08:55:51 +0100 From: Ivo Sedlacek To: "Drage, Keith (Nokia - GB)" , EXT Alissa Cooper Thread-Topic: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" Thread-Index: AQHRg7nLe8dcjY6zo0iz9xnDGcDJmJ9ltb+AgAAXmQCAACB4gIAACdkAgAC3Z4CAAOpkAIAAD7YAgACUhfA= Date: Thu, 24 Mar 2016 07:55:50 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011635DDA4@ESESSMB301.ericsson.se> References: <20160201001230.24574.16071.idtracker@ietfa.amsl.com> <5BE65331-A014-4518-8D05-F7BD885E39DE@neustar.biz> <39BB2FF6-A69B-46AE-9653-1B28A8EE6023@gmail.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D08@FR712WXCHMBA11.zeu.alcatel-lucent.com> <195736B5-92D0-400F-8A5D-252562E6D2DC@cooperw.in> <949EF20990823C4C85C18D59AA11AD8BADEB1707@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB1707@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.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7im773M9hBpPvWFhMP/OX0WJ+52l2 i2knLzNbNC56ymqxYctxFosNp76xOLB5TPm9kdXjy5OXTB5Llvxk8tjR8JzZ4+6tS0wes3Y+ YQlgi+KySUnNySxLLdK3S+DKuPNvDnPBudKKde82sTQwninqYuTgkBAwkVi5zKqLkRPIFJO4 cG89WxcjF4eQwGFGielHOtghnCWMEpMP3WYEqWIT0JOYuOUIK4gtIpAgMeNCIzNIEbPATUaJ Z91fWECmCgvESvR+cYaoiZNo/vERaBA7kJ0ksT0MJMoioCpxe+ccFhCbV8BX4vL+X6wQq1ay SDRt+sYOkuAEmjJ3xXmwIkYBWYmrf3rBTmAWEJe49WQ+E8TRAhJL9pxnhrBFJV4+/scKYStK 7DzbzgxyDbOApsT6XfoQrYoSU7ofskPsFZQ4OfMJywRGsVlIps5C6JiFpGMWko4FjCyrGEWL U4uLc9ONjPRSizKTi4vz8/TyUks2MQIj8eCW31Y7GA8+dzzEKMDBqMTD+0H+c5gQa2JZcWXu IUYJDmYlEV6+OqAQb0piZVVqUX58UWlOavEhRmkOFiVxXrZPl8OEBNITS1KzU1MLUotgskwc nFINjGYOaapJEYZ6Mo5blkW3nbEy6X7aL8FX9PGwbHX70TNJJjFBK2pqWs623Fwyc5ZdVwRX vEjAycN/Fnyt38gW+zb65JqCyZP0vE0/Nou8OTvhuXjZhBMbtkmFrYv7Zbl/km26ttgifs9r 73b/tPt/425hpeSO1CRf6bIXV79ke9SufsjOcFz0vBJLcUaioRZzUXEiAMJWrxzAAgAA Archived-At: Cc: "EXT Rosen, Brian" , Marc Linsner , Emergency Context Resolution with Internet Technologies Discussion List , Ben Campbell Subject: Re: [Ecrit] New Liaison Statement, "Response to LS on NG eCall support for the EU" X-BeenThere: ecrit@ietf.org 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, 24 Mar 2016 07:55:57 -0000 KzENCg0KS2luZCByZWdhcmRzDQoNCkl2bw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI0LCAyMDE2 IDE6MDQgQU0NClRvOiBFWFQgQWxpc3NhIENvb3Blcg0KQ2M6IEVYVCBSb3NlbiwgQnJpYW47IE1h cmMgTGluc25lcjsgRW1lcmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRl Y2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3Q7IEJlbiBDYW1wYmVsbA0KU3ViamVjdDogUmU6IFtF Y3JpdF0gTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcgZUNhbGwg c3VwcG9ydCBmb3IgdGhlIEVVIg0KDQpXaGF0IEkgd2FzIHRyeWluZyB0byBzYXkgaXMsIHRoYXQg YnkgcHJvY2VlZGluZywgdGhhdCBJRVRGIGFyZSBwdXR0aW5nIGJsb2NrcyBpbiB0aGUgd2F5IG9m IDNHUFAgZGVmaW5pbmcgdGhlaXIgc2VydmljZSBmb3IgdGhlaXIgb3duIHVzZS4NCg0KSXQgaXMg Y2xlYXIgdG8gbWUgdGhhdCB0aGUgb25seSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQg aXMgaW4gYSAzR1BQIGVudmlyb25tZW50LCBhbmQgM0dQUCBuZWVkcyB0byBtYWtlIHRoZWlyIG93 biBkZWNpc2lvbnMgYXMgdG8gaG93IHRoZSBzZXJ2aWNlIG9wZXJhdGVzLiBUaGVyZWZvcmUgdGhl IDNHUFAgd29yayBoYXMgdG8gY29tZSBmaXJzdC4NCg0KSSBpZGVudGlmaWVkIGluIGEgc2VwYXJh dGUgbWFpbCBhIG51bWJlciBvZiBpc3N1ZXMuDQoNCklmIGZvciBleGFtcGxlIHRoZSBzZXJ2aWNl IFVSTiBkZWZpbmVkIGJ5IHRoZSBJRVRGIGRyYWZ0IGRvZXMgbm90IG1lZXQgdGhlIHJlcXVpcmVt ZW50cyBvZiAzR1BQLCB0aGVuIDNHUFAgd2lsbCBuZWVkIHRvIHJlcXVlc3QgaXRzIG93biwgYW5k IHBvdGVudGlhbGx5IGJsb2NrIHRoZSBJRVRGIGRlZmluZWQgb25lcyBhcyB0aGV5IGNvdWxkIGNh dXNlIGhhcm0sIGFuZCAvIG9yIGRhbmdlciB0byBsaWZlIChkdWUgZmFpbGVkIGNhbGxzKSBpbiBj ZXJ0YWluIHJlZ3VsYXRvcnkgZW52aXJvbm1lbnRzLg0KDQpSZWdhcmRzDQoNCktlaXRoDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFWFQgQWxpc3NhIENvb3BlciBbbWFpbHRv OmFsaXNzYUBjb29wZXJ3LmluXQ0KU2VudDogMjMgTWFyY2ggMjAxNiAyMzowOA0KVG86IERyYWdl LCBLZWl0aCAoTm9raWEgLSBHQikNCkNjOiBFWFQgUm9zZW4sIEJyaWFuOyBSYW5kYWxsIEdlbGxl bnM7IEJlbiBDYW1wYmVsbDsgTWFyYyBMaW5zbmVyOyBFbWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0 aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24gTGlzdA0KU3ViamVjdDog UmU6IFtFY3JpdF0gTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMgb24gTkcg ZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KDQpIaSBLZWl0aCwNCg0KPiBPbiBNYXIgMjMsIDIw MTYsIGF0IDI6MDkgQU0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5v a2lhLmNvbT4gd3JvdGU6DQo+IA0KPiBQZXJzb25hbGx5IEkgZmluZCB0aGUgZW50aXJlIExTIHRo YXQgeW91IHdhbnQgaW5kaWNhdGluZyB0aGF0IHRoZSBJRVRGIGRyYWZ0IENBTk5PVCBiZSB1c2Vk IGluIGEgM0dQUCBlbnZpcm9ubWVudC4NCg0KSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHN0YXRl bWVudCBhYm92ZS4gQ291bGQgeW91IGVsYWJvcmF0ZT8gV2hlcmUgZG9lcyB0aGUgTFMgc2F5IHRo YXQgdGhlIEktRHMgY2Fubm90IGJlIHVzZWQgYnkgM0dQUD8NCg0KVGhhbmtzLA0KQWxpc3NhDQoN Cj4gDQo+IEkgYWxzbyBmaW5kIHRoZSBkcmFmdCByZXNwb25zZSBpbmRpY2F0aW5nIGEgZGVjaXNp b24gbWFkZSBieSB0aGUgV0cgY2hhaXJzIGFuZCBBZHMgdGhhdCBicmVha3MgdGhlIHNwaXJpdCBv ZiBSRkMgMzExMy4NCg0KPiBJIHRoZXJlZm9yZSBvYmplY3QgdG8gdGhlIHBvc2l0aW9uIGFkb3B0 ZWQgYnkgdGhlIEFkcyBhbmQgV0cgY2hhaXJzLg0KPiANCj4gUmVnYXJkcw0KPiANCj4gS2VpdGgN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVjcml0IFttYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVYVCBSb3NlbiwgDQo+IEJyaWFu DQo+IFNlbnQ6IDIyIE1hcmNoIDIwMTYgMjI6MTMNCj4gVG86IFJhbmRhbGwgR2VsbGVucw0KPiBD YzogQmVuIENhbXBiZWxsOyBNYXJjIExpbnNuZXI7IEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRp b24gd2l0aCANCj4gSW50ZXJuZXQgVGVjaG5vbG9naWVzIERpc2N1c3Npb24gTGlzdA0KPiBTdWJq ZWN0OiBSZTogW0Vjcml0XSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJSZXNwb25zZSB0byBMUyBv biBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUiDQo+IA0KPiBUaGUgcHJvYmxlbSBJIGhhdmUg d2l0aCB0aGUgY3VycmVudCB0ZXh0IGlzIHRoYXQgaXQgc2F5cyB0byAzR1BQIOKAnGNoYW5nZSBh bGwgeW91IHdhbnQsIHdl4oCZbGwgY2hhbmdlIG91cnMgdG8gbWF0Y2jigJ0uICBJIHdhbnQgdGhh dCB0byBiZSDigJx3ZSB3ZW50IGFoZWFkLCBwbGVhc2UgdHJ5IHRvIHVzZSBpdOKAnS4NCj4gDQo+ PiBPbiBNYXIgMjIsIDIwMTYsIGF0IDU6MzcgUE0sIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkBy YW5keS5wZW5zaXZlLm9yZz4gd3JvdGU6DQo+PiANCj4+IEkgdGhpbmsgSmFtZXMgaGFzIGEgcG9p bnQsIGFuZCBCcmlhbidzIHN1Z2dlc3RlZCBjaGFuZ2UgaXNuJ3QgbmVlZGVkLg0KPj4gDQo+PiBB dCA2OjQxIEFNICsxMTAwIDMvMjMvMTYsIEphbWVzIFdpbnRlcmJvdHRvbSB3cm90ZToNCj4+IA0K Pj4+IFRoYXQgc291bmRzIGEgbGl0dGxlIHByb3ZvY2F0aXZlIHRvIG1lLg0KPj4+IA0KPj4+IA0K Pj4+PiBPbiAyMyBNYXIgMjAxNiwgYXQgNToxNiBhbSwgUm9zZW4sIEJyaWFuIDxCcmlhbi5Sb3Nl bkBuZXVzdGFyLmJpej4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBDYW4gSSBzdWdnZXN0IGEgcmV3b3Jk IG9mIHRoZSAzcmQgcGFyYWdyYXBoLg0KPj4+PiANCj4+Pj4gIklmIDNHUFAgZmluZHMgaXQgbmVj ZXNzYXJ5IHRvIGludHJvZHVjZSBhbiBpbmNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGlzIGRvY3Vt ZW50LCBhcyBmaW5hbGx5IHB1Ymxpc2hlZCwgYW5kIGl0cyB3b3JrLCB3ZSByZXF1ZXN0IHRoYXQg eW91IGluZm9ybSB1cyBvZiBzdWNoIGFuIGlzc3VlIHNvIHRoYXQgd2UgY2FuIGV2YWx1YXRlIGl0 cyBlZmZlY3Qgb24gb3VyIGRvY3VtZW50IGFuZCBjb25zaWRlciBhbnkgcmV2aXNpb25zIHRoYXQg bWF5IGJlIG5lZWRlZCwgZm9sbG93aW5nIG5vcm1hbCBJRVRGIHByb2Nlc3Nlcy4iDQo+Pj4+IA0K Pj4+PiBCcmlhbg0KPj4+PiANCj4+Pj4+IE9uIE1hciAyMSwgMjAxNiwgYXQgNTozNSBQTSwgUm9n ZXIgTWFyc2hhbGwgPFJvZ2VyLk1hcnNoYWxsQGNvbXRlY2h0ZWwuY29tPiB3cm90ZToNCj4+Pj4+ IA0KPj4+Pj4gUHJvcG9zZWQgTGlhaXNvbiByZXNwb25zZToNCj4+Pj4+IA0KPj4+Pj4gVGhlIElF VEYgRUNSSVQgd29ya2luZyBncm91cCB3b3VsZCBsaWtlIHRvIHRoYW5rIDNHUFAgVFNHIENUIFdH MSBmb3IgdGhlaXIgcmVzcG9uc2UsIFREb2MgQzEtMTYwNzY0LCByZWZlcmVuY2luZyBMUyAoQzEt MTUyNjQ0KSBvbiB0aGUgdG9waWMgb2YgTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVLiANCj4+ Pj4+IFRoZSBFQ1JJVCB3b3JraW5nIGdyb3VwIGRpc2N1c3NlZCB5b3VyIGxpYWlzb24gYXMgaXQg YXBwbGllcyB0byB0aGUgSUVURiBkcmFmdC1pZXRmLWVjcml0LWVjYWxsIGRvY3VtZW50IGFuZCBy ZWFjaGVkIHRoZSBmb2xsb3dpbmcgY29uY2x1c2lvbnM6ICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90 IHNjaGVkdWxlZCB0byBmaW5pc2ggdGhlaXIgc3RhZ2UtMyB3b3JrIGZvciBlQ2FsbCBpbiBJTVMg dW50aWwgSnVuZSAyMDE3LCBhcyBwYXJ0IG9mIFJlbGVhc2UgMTQsIHdlIHdpbGwgY29udGludWUg cHJvZ3Jlc3NpbmcgdGhlc2UgZHJhZnRzIHRvIElFVEYgbGFzdCBjYWxsIGFzIGN1cnJlbnRseSBz Y2hlZHVsZWQuDQo+Pj4+PiANCj4+Pj4+IFdlIGFsc28gYWNrbm93bGVkZ2UgdGhhdCBkdXJpbmcg M0dQUCdzIGRldmVsb3BtZW50IHBoYXNlLCBzb21lIGRpZmZlcmVuY2VzIG1heSBvY2N1ciBiZXR3 ZWVuIHRoYXQgd2hpY2ggaXMgb3V0bGluZWQgd2l0aGluIHRoZSBleGlzdGluZyBkcmFmdC1pZXRm LWVjcml0LWVjYWxsIGFuZCB0aGF0IHdoaWNoIGVtZXJnZXMgZnJvbSB0aGUgM0dQUCB3b3JrLiBU aGUgSUVURiBwcm9jZXNzIGFsbG93cyBmb3IgUkZDcyB0byBiZSByZXZpc2VkIGluIHRoZSBldmVu dCBvZiBjaGFuZ2VzIGluIHRlY2hub2xvZ3kuDQo+Pj4+PiANCj4+Pj4+IFdlJ2xsIGNvbGxlY3Qg d2cgbWVtYmVyIGNvbW1lbnRzIG92ZXIgdGhlIG5leHQgZmV3IGRheXMgYW5kIHdpbGwgdGhlbiBt b3ZlIHRvIHNlbmQgb3V0IHRoZSBvZmZpY2lhbCByZXNwb25zZSB0byAzR1BQLg0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IFJvZ2VyIE1hcnNoYWxsDQo+Pj4+PiBSb2dlci5tYXJzaGFsbEBjb210ZWNo dGVsLmNvbQ0KPj4+Pj4gTWFyYyBMaW5zbmVyDQo+Pj4+PiBtbGluc25lckBjaXNjby5jb20NCj4+ Pj4+IEVDUklUIENoYWlycw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBSb2dlciBNYXJzaGFsbA0KPj4+Pj4gU2VudDogTW9uZGF5 LCBNYXJjaCAyMSwgMjAxNiAxOjI0IFBNDQo+Pj4+PiBUbzogRW1lcmdlbmN5IENvbnRleHQgUmVz b2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyANCj4+Pj4+IERpc2N1c3Npb24gTGlz dA0KPj4+Pj4gQ2M6IE1hcmMgTGluc25lcjsgQWxpc3NhIENvb3BlcjsgQmVuIENhbXBiZWxsDQo+ Pj4+PiBTdWJqZWN0OiBSRTogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiUmVzcG9uc2UgdG8gTFMg b24gTkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVIg0KPj4+Pj4gDQo+Pj4+PiBFQ1JJVCBXRzoN Cj4+Pj4+IA0KPj4+Pj4gVGhlIGNoYWlycyBoYXZlIHJldmlld2VkIHRoZSB0aHJlYWQgY29uY2Vy bmluZyBwcm9jZXNzaW5nIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMDUgYW5kIGRyYWZ0LWlldGYt ZWNyaXQtY2FyLWNyYXNoLTA1IGFzIHdlbGwgYXMgdGhlIG1vc3QgcmVjZW50IGxpYWlzb24gcmVj ZWl2ZWQgZnJvbSAzR1BQIG9uIDEvMzEvMjAxNiBhbmQgZGlzY3Vzc2VkIHdpdGggdGhlIGF1dGhv cnMuICBHaXZlbiB0aGF0IDNHUFAgaXMgbm90IHNjaGVkdWxlZCB0byBmaW5pc2ggdGhlaXIgd29y ayB1bnRpbCBKdW5lIDIwMTcsIHdlIHdpbGwgY29udGludWUgcHJvZ3Jlc3NpbmcgdGhlc2UgZHJh ZnRzIHRvIElFVEYgbGFzdCBjYWxsIGFzIHNjaGVkdWxlZC4gV2UgYWxzbyByZW1pbmQgdGhlIHdv cmtpbmcgZ3JvdXAgdGhhdCB0aGUgSUVURiBwcm9jZXNzIGFsbG93cyBjaGFuZ2VzIHRvIFJGQyBw dWJsaWNhdGlvbnMsIGUuZy4sIGlzc3VhbmNlIG9mIGJpcyBSRkNzIGluIHRoZSBldmVudCB0aGF0 IGNoYW5nZXMgaW4gdGVjaG5vbG9neSByZXN1bHQgaW4gdGhlIG5lZWQgdG8gbWFrZSBzdWNoIGEg Y2hhbmdlLiBTdWNoIGRvY3VtZW50cyB3b3VsZCBiZSBpbiBzY29wZSBvZiB0aGUgY3VycmVudCBF Q1JJVCBjaGFydGVyLCBzaG91bGQgdGhlIG5lZWQgYXJpc2UuDQo+Pj4+PiANCj4+Pj4+IFdlIHdp bGwgc2VuZCBhIHJlcGx5IGxpYWlzb24gc3RhdGVtZW50IHRvIDNHUFAgdG8gaW5mb3JtIHRoZW0g b2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnRzIGFmdGVyIHdlIHBvc3QgdGhlIHByb3Bvc2Vk IGxpYWlzb24gdGV4dCB0byB0aGUgbGlzdCwgd2hpY2ggd2lsbCBoYXBwZW4gc2hvcnRseS4NCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBSb2dlciBNYXJzaGFsbCAocm9nZXIubWFyc2hhbGxAY29tdGVj aHRlbC5jb20pICAmIE1hcmMgTGluc25lcg0KPj4+Pj4gKG1saW5zbmVyQGNpc2NvLmNvbSkgRWNy aXQgY2hhaXJzDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogTGlhaXNvbiBTdGF0ZW1lbnQgTWFuYWdlbWVudCBUb29s IFttYWlsdG86bHNtdEBpZXRmLm9yZ10NCj4+Pj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAzMSwg MjAxNiA0OjEzIFBNDQo+Pj4+PiBUbzogUm9nZXIgTWFyc2hhbGw7IE1hcmMgTGluc25lcg0KPj4+ Pj4gQ2M6IEJhcnJ5IExlaWJhOyBNYXJjIExpbnNuZXI7IEVtZXJnZW5jeSBDb250ZXh0IFJlc29s dXRpb24gd2l0aCANCj4+Pj4+IEludGVybmV0IFRlY2hub2xvZ2llcyBEaXNjdXNzaW9uIExpc3Q7 IGdlb3JnLm1heWVyLmh1YXdlaUBnbXguY29tOyANCj4+Pj4+IDNHUFBMaWFpc29uQGV0c2kub3Jn OyBSb2dlciBNYXJzaGFsbDsgQWxpc3NhIENvb3BlcjsgQmVuIENhbXBiZWxsDQo+Pj4+PiBTdWJq ZWN0OiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBz dXBwb3J0IGZvciB0aGUgRVUiDQo+Pj4+PiANCj4+Pj4+IFRpdGxlOiBSZXNwb25zZSB0byBMUyBv biBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgRVUgU3VibWlzc2lvbg0KPj4+Pj4gRGF0ZTogMjAx Ni0wMS0zMSBVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6IA0KPj4+Pj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTIvDQo+Pj4+PiANCj4+Pj4+IEZyb206ICJTdXNhbm5h IEtvb2lzdHJhIiA8M0dQUExpYWlzb25AZXRzaS5vcmc+DQo+Pj4+PiBUbzogTWFyYyBMaW5zbmVy IDxtYXJjLmxpbnNuZXJAY2lzY28uY29tPiwgUm9nZXIgTWFyc2hhbGwgDQo+Pj4+PiA8cm1hcnNo YWxsQHRlbGVjb21zeXMuY29tPg0KPj4+Pj4gQ2M6IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNv bXB1dGVyLm9yZz4sTWFyYyBMaW5zbmVyIDxtYXJjLmxpbnNuZXJAY2lzY28uY29tPixCZW4gQ2Ft cGJlbGwgPGJlbkBub3N0cnVtLmNvbT4sQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+ LFJvZ2VyIE1hcnNoYWxsIDxybWFyc2hhbGxAdGVsZWNvbXN5cy5jb20+LEVtZXJnZW5jeSBDb250 ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dpZXMgRGlzY3Vzc2lvbiBMaXN0 IDxlY3JpdEBpZXRmLm9yZz4sIFJlc3BvbnNlIENvbnRhY3RzOiBnZW9yZy5tYXllci5odWF3ZWlA Z214LmNvbSwgM0dQUExpYWlzb25AZXRzaS5vcmcgVGVjaG5pY2FsIENvbnRhY3RzOg0KPj4+Pj4g UHVycG9zZTogSW4gcmVzcG9uc2UNCj4+Pj4+IA0KPj4+Pj4gUmVmZXJlbmNlZCBsaWFpc29uOiBM aWFpc29uIFN0YXRlbWVudCBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUgDQo+Pj4+PiBFVSAo aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0MTIvKQ0KPj4+Pj4gDQo+Pj4+ PiBCb2R5OiAxLiBPdmVyYWxsIGRlc2NyaXB0aW9uDQo+Pj4+PiAzR1BQIFRTRyBDVCBXRzEgd291 bGQgbGlrZSB0byB0aGFuayBJRVRGIEVjcml0IFdHIGZvciB0aGUgTFMgKEMxLTE1MjY0NCkgb24g TkcgZUNhbGwgc3VwcG9ydCBmb3IgdGhlIEVVLg0KPj4+Pj4gM0dQUCBUU0cgQ1QgV0cxIHdvdWxk IGxpa2UgdG8gaW5mb3JtIElFVEYgRWNyaXQgV0cgdGhhdCAzR1BQIFRTRyBDVCBXRzEgd2lsbCB3 b3JrIG9uIHN0YWdlLTMgZm9yIGVDYWxsIGluIElNUyBpbiBSZWxlYXNlIDE0IChlbmRpbmcgaW4g SnVuZSAyMDE3KSwgc3ViamVjdCB0byAzR1BQIFRTRyBTQSBXRzIgY29tcGxldGlvbiBvZiB0aGUg bm9ybWF0aXZlIHN0YWdlLTIgd29yayBhbmQgYXBwcm92YWwgb2YgYSAzR1BQIFRTRyBDVCB3b3Jr IGl0ZW0uDQo+Pj4+PiAzR1BQIFRTRyBDVCBXRzEgc3RhZ2UtMyB3b3JrIG1pZ2h0IHJlc3VsdCBp biBwcm90b2NvbCByZXF1aXJlbWVudHMgZGV2aWF0aW5nIG9yIGNvbmZsaWN0aW5nIHdpdGggdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiBJRVRGIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwsIGFuZCB0aHVz IG1pZ2h0IGltcGFjdCBJRVRGIHdvcmsuDQo+Pj4+PiANCj4+Pj4+IDIuIEFjdGlvbnMNCj4+Pj4+ IFRvIElFVEYgRWNyaXQgV0cNCj4+Pj4+IEFDVElPTjogM0dQUCBUU0cgQ1QgV0cxIHJlc3BlY3Rm dWxseSBhc2tzIElFVEYgRWNyaXQgV0cgdG8gdGFrZSB0aGUgYWJvdmUgaW50byBjb25zaWRlcmF0 aW9uLg0KPj4+Pj4gDQo+Pj4+PiAzLiBEYXRlcyBvZiBuZXh0IFRTRyBDVCBXRzEgbWVldGluZ3MN Cj4+Pj4+IFRTRyBDVCBXRzEgTWVldGluZyA5NgkxNS0xOSBGZWJydWFyeSAyMDE2CUplanUgSXNs YW5kLCBLb3JlYQ0KPj4+Pj4gVFNHIENUIFdHMSBNZWV0aW5nIDk3CTExLTE1IEFwcmlsIDIwMTYJ TGp1YmxqYW5hLCBTbG92ZW5pYQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEF0dGFjaG1lbnRzOg0K Pj4+Pj4gDQo+Pj4+PiBSZXNwb25zZSB0byBMUyBvbiBORyBlQ2FsbCBzdXBwb3J0IGZvciB0aGUg RVUNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9kdC9kb2N1bWVudHMvTElBSVNPTi9s aWFpc29uLTIwMTYtMDEtMzEtMw0KPj4+Pj4gZw0KPj4+Pj4gcHAtdHNnY3QtY3QxLWVjcml0LXJl c3BvbnNlLXRvLWxzLW9uLW5nLWVjYWxsLXN1cHBvcnQtZm9yLXRoZS1ldS1hDQo+Pj4+PiB0DQo+ Pj4+PiB0YWNobWVudC0xLnBkZg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE5PVElDRSBUTyBSRUNJ UElFTlQ6IFRoaXMgZW1haWwsIGluY2x1ZGluZyBhdHRhY2htZW50cywgbWF5IGNvbnRhaW4gaW5m b3JtYXRpb24gd2hpY2ggaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgYXR0b3JuZXktY2xp ZW50IHByaXZpbGVnZWQgYW5kL29yIGNvbnRyb2xsZWQgdW5kZXIgVS5TLiBleHBvcnQgbGF3cyBh bmQgcmVndWxhdGlvbnMgYW5kIG1heSBiZSByZXN0cmljdGVkIGZyb20gZGlzY2xvc3VyZSBieSBh cHBsaWNhYmxlIFN0YXRlIGFuZCBGZWRlcmFsIGxhdy4gTm90aGluZyBpbiB0aGlzIGVtYWlsIHNo YWxsIGNyZWF0ZSBhbnkgbGVnYWwgYmluZGluZyBhZ3JlZW1lbnQgYmV0d2VlbiB0aGUgcGFydGll cyB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBoZXJlaW4gYW5kIHByb3ZpZGVkIGJ5IGFuIGF1dGhv cml6ZWQgcmVwcmVzZW50YXRpdmUgb2YgQ29tdGVjaCBUZWxlY29tbXVuaWNhdGlvbnMgQ29ycC4g b3IgaXRzIHN1YnNpZGlhcmllcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIG1lc3NhZ2UsIGJlIGFkdmlzZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLCBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJldHVybiBlbWFpbCBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsIGFuZCBhbnkgYXR0YWNo ZWQgZG9jdW1lbnRhdGlvbiBmcm9tIGFueSBjb21wdXRlciBvciBvdGhlciBtZWRpYS4NCj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBF Y3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4+IA0KPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBFY3JpdCBtYWlsaW5n IGxpc3QNCj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4gRWNyaXRA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 DQo+PiANCj4+IA0KPj4gLS0NCj4+IFJhbmRhbGwgR2VsbGVucw0KPj4gT3BpbmlvbnMgYXJlIHBl cnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkN Cj4+IC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0t IEluIHRoZSBVbml0ZWQgDQo+PiBTdGF0ZXMgdGhlIG1ham9yaXR5IHVuZGVydGFrZXMgdG8gc3Vw cGx5IGEgbXVsdGl0dWRlIG9mIHJlYWR5LW1hZGUgDQo+PiBvcGluaW9ucyBmb3IgdGhlIHVzZSBv ZiBpbmRpdmlkdWFscywgd2hvIGFyZSB0aHVzIHJlbGlldmVkIGZyb20gdGhlIA0KPj4gbmVjZXNz aXR5IG9mIGZvcm1pbmcgb3BpbmlvbnMgb2YgdGhlaXIgb3duDQo+PiAgIC0tQWxleGlzIGRlIFRv Y3F1ZXZpbGxlDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5n IGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lY3JpdA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3Jp dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0K From nobody Thu Mar 24 06:34: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 77A1012DB46 for ; Thu, 24 Mar 2016 06:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MwmJSVTfUD_P for ; Thu, 24 Mar 2016 06:33:56 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 2DD8E12D122 for ; Thu, 24 Mar 2016 06:33:08 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2ODNP5g027443; Thu, 24 Mar 2016 09:33:08 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 21s1dtfvhp-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Mar 2016 09:33:07 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.230]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 09:33:06 -0400 From: "Rosen, Brian" To: "Drage, Keith (Nokia - GB)" Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-07 Thread-Index: AQHRhdGy4JPO9syOe0mJHiUKcCY+tQ== Date: Thu, 24 Mar 2016 13:33:06 +0000 Message-ID: <6CDFB7FE-3F64-454F-8642-D7C515805EE0@neustar.biz> References: <949EF20990823C4C85C18D59AA11AD8BADEB0D00@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEB0D00@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.154.7.46] Content-Type: text/plain; charset="utf-8" Content-ID: <2E77570E5322FA40BD5B12E8504A8AAA@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-24_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: Emergency Context Resolution with Internet Technologies Discussion List Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 13:34:00 -0000 DQo+IE9uIE1hciAyMywgMjAxNiwgYXQgNTowOCBBTSwgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdC KSA8a2VpdGguZHJhZ2VAbm9raWEuY29tPiB3cm90ZToNCj4gDQo+PiBGcm9tIG15IGtub3dsZWRn ZSBvZiB0aGUgM0dQUCB3b3JrIHNvIGZhciAoZXNzZW50aWFsbHkgdGhlIHN0YWdlIDEgc2Vydmlj ZSByZXF1aXJlbWVudHMpIEkgd291bGQgbm90ZSBhdCBsZWFzdCBzb21lIHRoaW5ncyB3aXRoIHRo aXMgZHJhZnQ6DQo+IA0KPiAxKQlUaGUgc2VydmljZSBVUk4gaXMgbWVhbnQgdG8gaWRlbnRpZnkg dGhlIHJlc291cmNlIHRoYXQgaXMgcmVxdWlyZWQgYnkgdGhlIHJlcXVlc3RpbmcgdXNlci4gSW4g YSAzR1BQIGVudmlyb25tZW50IHRoYXQgcmVzb3VyY2Ugd2lsbCBiZSBhbiBlbnRpdHkgdGhhdCBz dXBwb3J0cyBib3RoIHNvbWUgZGF0YSBtZWFucyBvZiB0cmFuc21pc3Npb24gKEkgY2FuIGd1ZXNz IGl0IHdpbGwgc29tZXRpbWVzIGJlIGEgYm9keSBidXQgdGhhdCBkaXNjdXNzaW9uIGhhcyBub3Qg cmVhY2hlZCB0aGF0IHBvaW50IHlldCksIGJ1dCB3aWxsIGFsc28gYmUgcmVxdWlyZWQgdG8gc3Vw cG9ydCBhbiBpbi1iYW5kIGZvcm0gb2YgdGhlIGV4aXN0aW5nIENTIHN1cHBvcnRlZCBNU0QuIFRo aXMgaXMgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIG1pZ3JhdGlvbiBwdXJwb3Nlcy4gQW55IFVS TiB0aGF0IGRvZXMgbm90IGlkZW50aWZ5IHN1cHBvcnQgb2YgYm90aCByZXNvdXJjZXMgY2Fubm90 IGJlIHVzZWQgaW4gYSAzR1BQIGVudmlyb25tZW50Lg0KVGhlIFVSTiBpcyBhIG1hcmtlciwgbm90 IGEgcmVzb3VyY2UgcmVxdWlyZWQuICBJdCBtYXJrcyBlbWVyZ2VuY3kgY2FsbHMuICBUaGUgcm91 dGUgaXMgaW4gdGhlIFJvdXRlIGhlYWRlci4gIFlvdSBjYW4gcHV0IGFueXRoaW5nIHlvdSB3YW50 IGluIHRoZXJlLiAgQWRkaXRpb25hbGx5LCB3ZSBuZXZlciBmb3VuZCBpdCBuZWNlc3NhcnkgdG8g bWl4IENTIHN1cHBvcnRlZCBlbWVyZ2VuY3kgY2FsbHMgd2l0aCBJUCBzdXBwb3J0ZWQgZW1lcmdl bmN5IGNhbGxzLCBhbmQgSSBkb27igJl0IHNlZSB3aHkgQ1MgY2FsbHMgd291bGQgY2hhbmdlIGF0 IGFsbCBmcm9tIHdoYXQgdGhleSBhcmUgbm93LiAgWW91IG1hcmsgQ1MgY2FsbHMgd2l0aCDigJwx MTLigJ0sIG5vdCBhIHNlcnZpY2UgVVJOLCBhbmQgeW91IHRyZWF0IHRoZW0gY29uc2lkZXJhYmx5 IGRpZmZlcmVudGx5IHRoYW4gSVAgY2FsbHMuDQo+IA0KPiAyKQlSb2FtaW5nIGlzIGltcG9ydGFu dCBpbiAzR1BQLiBTb21lIGNvdW50cmllcyBkbyBub3Qgc3VwcG9ydCBlY2FsbCAoYW5kIHRoZXJl Zm9yZSBkbyBub3QgcHJvdmlkZWQgZGVkaWNhdGVkIGVjYWxsIFBTQVBzKS4gVGhlIHByb3Bvc2Vk IFVSTnMgd2lsbCB0aGVyZWZvcmUsIGJ5IHZpcnR1ZSBvZiBzdHJpcHBpbmcgdW5yZWNvZ25pemVk IHN1YnR5cGVzLCBlbmQgdXAgb24gdGhlIG5vcm1hbCBQU0FQcy4gVGhhdCBjb3VsZCBiZSBPSyBp ZiB0aGVyZSBpcyBhIHZvaWNlIG1lZGlhIGluY2x1ZGVkLiBIb3dldmVyIHRoZXJlIGlzIGEgZGF0 YSBvbmx5IGNhc2UgaW4gZWNhbGwgd2hpY2ggd2lsbCBub3QgYmUgZGlyZWN0bHkgdXNhYmxlIGJ5 IGEgc3RhbmRhcmQgUFNBUCAtIGl0IHdpbGwgZXNzZW50aWFsbHkgYmUgYSBzaWxlbnQgZW1lcmdl bmN5IGNhbGwuIE5vdGUgdGhhdCB0aGUgYXR0aXR1ZGUgb2YgcmVndWxhdG9yeSBhdXRob3JpdGll cyB0byBjYWxscyB0aGV5IGNhbm5vdCBoYW5kbGUgdmFyaWVzIGZyb20gY291bnRyeSB0byBjb3Vu dHJ5IChzb21lIGNvdW50cmllcyBtaWdodCBldmVuIHByb3NlY3V0ZSB0aGUgZ2VuZXJhdG9yIG9m IHN1Y2ggY2FsbHMpLiBNZWNoYW5pc21zIG1heSBuZWVkIHRvIGJlIGluIHBsYWNlIHRvIHByZXZl bnQgc3VjaCBlY2FsbHMgd2hlbiBpbiByZWd1bGF0b3J5IHJlZ2ltZXMgd2hlcmUgZWNhbGwgaXMg bm90IHN1cHBvcnRlZC4NCklmIHlvdSB3YW50IHRvIOKAnHByZXZlbnTigJ0gdGhlbSwgeW91IGhh dmUgdHdvIGNob2ljZXMuICBPbmUgaXMgdG8gcmV0dXJuIGFuIGVycm9yIG9uIHRoZSBzaWduYWxp bmcsIHRoZSBvdGhlciBpcyB0byByb3V0ZSB0aGVtIHRvIGFuIElWUiBvciBzb21ldGhpbmcgZXF1 aXZhbGVudCB0aGF0IHRlbGxzIHRoZW0gc3VjaCBjYWxscyBhcmUgbm90IHBlcm1pdHRlZC4gIFRo ZSBmb3JtZXIgd291bGQgcmVxdWlyZSBzb21lIG1vcmUgbWVjaGFuaXNtLCBidXQgSSBkb27igJl0 IHNlZSB0aGF0IGl0IHdvdWxkIGJlIGluY29tcGF0aWJsZSB3aXRoIHRoaXMgZG9jdW1lbnQuICBU aGUgbGF0dGVyIGRvZXNu4oCZdCB0YWtlIGFueSBzdGFuZGFyZHMsIGp1c3QgY29udmVudGlvbiBh bmQgcHJvdmlzaW9uaW5nIG9mIHRoZSByb3V0ZSBkYXRhYmFzZS4gICBTaW5jZSB0aGUgcHJldmVu dGlvbiBpcyBsb2NhdGlvbiBkZXBlbmRlbnQsIGl0IHdvdWxkIGJlIGVhc2llc3QgdG8gZG8gaXQg YWxsIGluIHRoZSByb3V0ZSBkYXRhYmFzZSBhbmQgcm91dGUgdG8gYW4gSVZSIG9yIHRvbmVzIGdl bmVyYXRvciB0aGF0IGluZm9ybXMgdGhlIHVzZXIgdGhleSBhcmUgbm90IGFsbG93ZWQuIA0KDQo+ IA0KPiAzKQlUaGUgM0dQUCByZXF1aXJlbWVudHMgZm9yIHRlc3QgY2FsbHMgYXJlIG5vdCB5ZXQg Y2xlYXIgKGF0IGxlYXN0IHRvIG1lKS4gV2hhdCBpcyBjbGVhciBpcyB0aGF0IGlmIHRoZXkgYXJl IHRyZWF0ZWQgYXMgbm9ybWFsIGNhbGxzIHRoZW4gdGhleSB3aWxsIG5vdCAiTU5PcyBjYW4gdHJl YXQgYSB2ZWhpY2xlIGNhbGwgaW4gdGhlICJ0ZXN0IiBzZXJ2aWNlIFVSTiBpbiBhIHdheSB0aGF0 IHRlc3RzIGFzIG11Y2ggZnVuY3Rpb25hbGl0eSBhcyBkZXNpcmVkIiBiZWNhdXNlIG11Y2ggb2Yg dGhlIG5ldHdvcmsgZXF1aXBtZW50IHdpbGwgbm90IGJlIHRoZSBzYW1lLiBGdXJ0aGVyIGZvciBh IHJvYW1pbmcgdXNlciwgdGhlIHRlc3QgY2FsbCBtYXkgbm90IGV2ZW4gc3VjY2VlZC4gRnVydGhl ciBpdCBpcyBub3QgeWV0IGNsZWFyICh0byBtZSkgd2hldGhlciBhbGwgM0dQUCBlY2FsbCBlcXVp cG1lbnQgYW5kIG5ldHdvcmsgcHJvdmlkZXJzIHdpbGwgc3VwcG9ydCBub24tZW1lcmdlbmN5IGNh bGxzIGZyb20gYW4gZWNhbGwgZGV2aWNlLiAgDQpZb3UgY2FuIGp1c3QgZGlzYWxsb3cgdGVzdCBj YWxscyBpZiB5b3Ugd2FudCB0bywgYnV0IEkgdGhpbmsgdGhhdCB3b3VsZCBiZSB2ZXJ5IHVuZm9y dHVuYXRlLiAgV2hpbGUgaW1wbGVtZW50YXRpb25zIHByb2JhYmx5IGhhdmUgdG8gaGF2ZSBtZWNo YW5pc21zIHRvIGxpbWl0IGludGFrZSBvZiB0ZXN0IGNhbGxzIGlmIHRoZXkgd2lsbCBjYXVzZSBp bXBhaXJtZW50IG9mIHRoZSBuZXR3b3JrIG9yIFBTQVAsIGluIGV2ZXJ5IG90aGVyIHdheSwgdGhl IG5ldHdvcmsgc2hvdWxkIHRyZWF0IHRoZW0gZXhhY3RseSBsaWtlIGVtZXJnZW5jeSBjYWxscy4g IEkgZG9u4oCZdCBzZWUgYW55IGltcGFjdCBvbiAzR1BQIG5ldHdvcmtzIC0gdGhleSBzaG91bGQg YmUgdHJlYXRlZCBhcyBlbWVyZ2VuY3kgZWNhbGxzLiAgSWYgeW91IGFyZSBoYW5kbGluZyB0ZXN0 IGNhbGxzIHdoZXJlIOKAnG11Y2ggb2YgdGhlIG5ldHdvcmsgIGVxdWlwbWVudCB3aWxsIG5vdCBi ZSB0aGUgc2FtZeKAnSwgeW91IGFyZSBkb2luZyBpdCB3cm9uZy4gIFRoZSB3aG9sZSBwb2ludCBv ZiB0aGUgdGVzdCBjYWxsIGlzIHRoYXQgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBpbiBob3cgdGhl IFBTQVAgcmVzcG9uZHMgdG8gdGhlbS4gIFRoZSBuZXR3b3JrIGRvZXNu4oCZdCBkaWZmZXJlbnRp YXRlLg0KPiANCj4gR2l2ZW4gdGhhdCByZXNvbHZpbmcgdGhlc2Ugd2lsbCBiZSBkaWZmZXJlbnQg ZnJvbSBhbnkgcHVibGlzaGVkIElFVEYgZG9jdW1lbnQgYmFzZWQgb24gdGhlIGN1cnJlbnQgZHJh ZnQgYW5kIG1heSB3ZWxsIGNhdXNlIGRlcGxveW1lbnQgcHJvYmxlbXMgaW4gc29tZSByZWd1bGF0 b3J5IGFyZWFzIGlmIHRoZSBjdXJyZW50IElFVEYgZG9jdW1lbnQgaXMgaW1wbGVtZW50ZWQsIG15 IHByb3Bvc2FsIGlzIHNpbXBsZS4uLg0KPiANCj4gUmVnYXJkcw0KPiANCj4gS2VpdGggRHJhZ2UN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Sat Mar 26 06:58: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 F1C3412D609 for ; Sat, 26 Mar 2016 06:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 agFXxbyle6FO for ; Sat, 26 Mar 2016 06:58:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAFC12D602 for ; Sat, 26 Mar 2016 06:58:56 -0700 (PDT) Received: from [192.168.10.140] ([80.92.115.95]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6P5z-1ZqT9z3J6p-00yRNl; Sat, 26 Mar 2016 14:58:45 +0100 To: Randall Gellens , Dan Banks , James Winterbottom , Brian Rosen References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> <56F04C03.4010105@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56F69593.2000701@gmx.net> Date: Sat, 26 Mar 2016 14:58:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oJK25fxdFloGIrOdoF2bn2NwU08GRRJ9u" X-Provags-ID: V03:K0:x4/JlAhrfM4omaTyslYSgbMaXQ350x91dBROIkHIktThRNGjxkx lt5OVMXHnpJx3xawNvOvSVuLq4x/r1jbvp/VyklwBqbiaMEmIdBZcDE2pkXc2bXZpdSdWKr iGNAtSoXoVy+BJtneGu0DhLdIxuVm+kh29w5CPcn4vO4tNbzsamHhYf2uAQ32TLZI/wFCvJ ClR+E4b8re4XKHVavix+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:dQ6+gRq/meY=:A8R/1oVVZCqaixjpiKWXgq yt+AdwhyvUjj8a12Lta46DI5OCQDQEjxAa3mInmn+SIWNyLyYm3qdBHv8PIJwy4TuGQxcgtQn 0iPa81DBt2vThuhq1is4+eLIDDFIaK/7YwcDIpXJBRbcy6jR94SbFuqIVFBe1flme4xe5T6UE 2rm6uhdLsQQz8Ys9rT+RrxNkx+LcAoa3btWnSUSZETxVj6Nq5EpLSSxaoCRVdOEn99De/0grT 7pPa7kyMfF2+d3EGD0teAU69NdiBQmdMHQYiss3urTcw0fPExMkYkSvJWFGfMMbgGfZKpzNJe UwMiied4rWFOdT0FSaKKDpso54nWNmqZnNGoxgO0qTQwiW9TLGFnx44v2VRTGBeaPYAjILuiN Poy8JtuQhyBqx1pbXNL1hCGY/zeZEN31qU1wihv09ine+l9gVg3PY2nuK0UG+Z60zXurikbaP AeTnCCT7SJQqwh5eUdlLP0qAaLrEuKPeSslxA51MMiOS1Y2iN+Qjlic7sjlIDRMczxLL4oeif MQuDvPDZlsobU33EdAEWHiBNbgg1lwvdgky5CBSyZM2goE5rhHPVVIoYCEWssE3nL4TMi2AJf E4exnWm6w+VLPpuyWZ9QPh9htFRUWGVWQOGReX5KYNSvkYP5TuBAjoegkQvGe+d4Su+YGin0G bDu3xfAmF+IQSif9IyeizMnfPlKPPFp30lUflpWzwSOBalKZFfIutQKiS9PPFrLupfy22lXjB J3qoJxiyChYlZA9dnuYpBaZfbgteNFZa9liPMAp2vPtqSGtr1UzdmzKej94= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 26 Mar 2016 13:58:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oJK25fxdFloGIrOdoF2bn2NwU08GRRJ9u Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Randy, I believe we should reach out to the IESG and ask them a question about their approach regarding formal languages and the use of data definition languages in particular. It seems that we are not particularly lucky in the IETF with the use of formal languages for describing protocol exchanges. While we excessively use them we often get them wrong for a number of reasons. In this specific case it seems that the authors of the XML xcard spec got it wrong and fixed the bug in a way that is also violating the way how these formal language is supposed to work. The correct way IMHO would have been to issue a new schema (+ new namespace + new schema registration). For whatever reason they haven't gone that route. Now, for us the question is why cannot we cheat here as well? Or, to phrase it differently, does anyone even care about these data definition languages at all in IETF documents. Ciao Hannes On 03/22/2016 01:05 AM, Randall Gellens wrote: > So, I think we have three remaining open questions, which are: >=20 > Should we go with -38 as it is (new namespace and schema normative) or >=20 > (1) Revert namespace to original name? > (2) Revert schema to informative? > (3) Do we add to the schema "x-" and "vnd-" tokens as well as IANA toke= ns? >=20 >=20 > At 8:31 PM +0100 3/21/16, Hannes Tschofenig wrote: >=20 >> Hi Dan, >> >> the situation looks a bit tricky. >> >> It seems that accepting the errata wasn't quite the right thing since= it >> changes an XML schema without defining a new namespace and without >> registering the new schema. >> >> In some sense, we could be equally "relaxed" and just change their >> schema again (without changing the namespace). >> >> I believe it ultimately boils down to the question what the value of = the >> XML schema actually is. >> >> I see a couple of different usages: >> >> a) If someone uses the XML schema to generate code then anything othe= r >> than defining our own, corrected XML schema will lead to problems >> >> b) If the XML schema is only used by an implementer to validate insta= nce >> documents than defining our own, corrected XML schema will also be >> needed. >> >> c) If the XML schema is, however, only used as a different way of >> reading the document content then changing the schema within the text= >> (as we had done up to version -37) is fine. >> >> I personally think that most developers don't do (a) and (b) and that= 's >> why most of the XML schemas in technical specifications are actually >> broken (not only in the IETF but also elsewhere). The "most developer= s" >> is important here since we have found developers, such as Philip, who= >> actually produce code based on the schema (which is why he found >> problems). >> >> However, by making these types of "fixes" we are obviously not going = to >> improve the situation. It is also the question what the IESG and the >> area directors think about this situation. In some sense it is not on= ly >> about the use of XML schemas but the issue is a bit more broadly rela= ted >> to the use of formal languages in the IETF in general. There are many= >> other places where we messed things up, such as with ABNF. >> >> Ultimately, it fear it will boil down to a different question, namely= : >> What does it mean if the VCard schema in our spec is different from t= he >> original VCard schema in terms of re-use with existing software. >> >> Ciao >> Hannes >> >> >> On 03/21/2016 05:20 PM, Dan Banks wrote: >>> I'm not entirely sure this is the right way to go. >>> >>> First, if the values can only come from the registry, that still >>> excludes the x-name values (which seems to me to be nearly as big of= >>> an omission as leaving out the iana-token values). >>> >>> Second, is changing the namespace really necessary? Perhaps I don't= >>> understand the errata process correctly, but James' argument that th= e >>> RFC 6351 schema error requires it does not seem persuasive to me in >>> light of the existing errata already being verified status (as >>> opposed to held for update). That suggests to me that any RFC 6351 >>> implementation should take this errata into account. >>> >>> Changing the namespace also brings new complications: the xCards wil= l >>> not be interoperable with an RFC 6351 implementation (even one that >>> considers the errata), and the Appendix A schema would have to be >>> normative. This essentially redefines the entire xCard schema with >>> an XML schema when the previous version was a Relax NG schema. This= >>> doesn't seem like a good idea to me. >>> >>> Dan Banks >>> >>> -----Original Message----- From: Hannes Tschofenig >>> [mailto:hannes.tschofenig@gmx.net] Sent: Sunday, March 20, 2016 9:09= >>> AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew >>> Newton; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data Draft >>> (again) >>> >>> Hi Randy, Hi James, >>> >>> the proposal makes sense to me an I have been working on an update t= o >> > reflect these changes. >>> >>> Here is the link to the work in progress document: >>> >>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additi= onal-data/draft-ietf-ecrit-additional-data-38.txt >>> >>> >>> Ciao Hannes >>> >>> On 03/19/2016 12:20 AM, Randall Gellens wrote: >>>> Thanks for listing the steps, James. >>>> >>>> Hannes, does this sound like the plan to you? >>>> >>>> Brian, do you concur? >>>> >>>> Thanks everyone. >>>> >>>> At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >>>> >>>>> So, just make sure I am clear on what the plan is: 1) Remove the >>>>> enumeration for the schema so all values now come from the >>>>> registry only 2) Add main number to the registry 3) Change the >>>>> namespace 4) Update all examples to use the new namespace 5) >>>>> register the namespace and schema with IANA >>>>> >>>>> Cheers James >>>>> >>>>> >>>>> >>>>>> On 19 Mar 2016, at 8:51 am, Randall Gellens >>>>>> wrote: >>>>>> >>>>>> I'm OK with changing the namespace if we need to. >>>>>> >>>>>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>>>>> >>>>>>> I think that the general approach is okay, I remain >>>>>>> unconvinced that we don't need a new namespace however, >>>>>>> because the schema in RFC 6351 is normative and it has an >>>>>>> error and our solution requires the error be corrected. >>>>>>> >>>>>>> Cheers James >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens >>>>>>>> wrote: >>>>>>>> >>>>>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>>>>> >>>>>>>>> I am not very familiar with the process around updating >>>>>>>>> documents, but to me this suggests: - we should not need >>>>>>>>> to do an update to RFC 6351, - we should fix the >>>>>>>>> informative schema in the additional data document to >>>>>>>>> take into account the verified errata (there are >>>>>>>>> several), - we should seek review of "main-number" as an >>>>>>>>> addition to the registry, and update the additional data >>>>>>>>> draft to formally make that addition. >>>>>>>> >>>>>>>> This sounds reasonable to me. We also won't need to change >>>>>>>> the namespace. >>>>>>>> >>>>>>>> -- Randall Gellens Opinions are personal; facts are >>>>>>>> suspect; I speak for myself only -------------- Randomly >>>>>>>> selected tag: --------------- A list is only as strong as >>>>>>>> its weakest link. --Donald Knuth >>>>>> >>>>>> >>>>>> -- Randall Gellens Opinions are personal; facts are suspect; >>>>>> I speak for myself only -------------- Randomly selected tag: >>>>>> --------------- 640K ought to be enough for anybody. --Bill >>>>>> Gates, 1981 >>>> >>>> >>> >> >> >> >> Content-Type: application/pgp-signature; name=3D"signature.asc" >> Content-Description: OpenPGP digital signature >> Content-Disposition: attachment; filename=3D"signature.asc" >> >> Attachment converted: TiLand:signature 1702.asc ( / ) (0331F6EF= ) >=20 >=20 --oJK25fxdFloGIrOdoF2bn2NwU08GRRJ9u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW9pWUAAoJEGhJURNOOiAtchgH/jBwhJL9m7Fh+4ARD1iiub5L OY1qlvCu26EM0YBkxfUxA8iNkBFZCqMsoJm4x0ictmVNtgnY7V9ZF5XxwY0Wn1sm w/H6bzCVU3fBxK5xIs8jzGv9sO3mlaH5KgHNN2yZDg9zcyKYe9PH+abE2zs28bbA rztQDnGuBR2jBnPN+bwlq2eDlFV15yXmbQaBM9hfEWbG94wPa95Q6GKyGn6nhpAo jeCDcljhtMPPgowDfftIkEtIz2heoB6oG4qfj9Pwq7bPa9dIwNUk1KlH7eL9K3Tn UPyHRlatbjQ/14UnbEpOl7/QPCVcoRRdI1K9QxoYT2A7oxu0BYRkq7LK/RZcKak= =teVl -----END PGP SIGNATURE----- --oJK25fxdFloGIrOdoF2bn2NwU08GRRJ9u-- From nobody Sat Mar 26 12:31: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 BEBE212D172 for ; Sat, 26 Mar 2016 12:31: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: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 J5DTzzKnuIVn for ; Sat, 26 Mar 2016 12:31:23 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFFD12D140 for ; Sat, 26 Mar 2016 12:31:23 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 26 Mar 2016 12:31:22 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <56F69593.2000701@gmx.net> References: <56E03BA4.5080104@gmx.net> <6B0C4B6C-C597-4A83-8BB1-B9C059CEB392@gmail.com> <64464174-A94C-4B2F-8C4E-CAA1BCB4E40F@gmail.com> <56EEA101.6010409@gmx.net> <56F04C03.4010105@gmx.net> <56F69593.2000701@gmx.net> X-Mailer: Eudora for Mac OS X Date: Sat, 26 Mar 2016 12:31:20 -0700 To: Hannes Tschofenig , Dan Banks , James Winterbottom , 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: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data Draft (again) X-BeenThere: ecrit@ietf.org 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, 26 Mar 2016 19:31:27 -0000 Hi Hannes, I agree with you that formal languages have been a problem in our documents for decades. In the particular case of additional-data and xCard, you are right that we already have two schemas using the same namespace, so the question is, should we do one more, or not? I believe Dan has said he sees more problems if we define a new namespace then if we don't, but James disagrees. At 2:58 PM +0100 3/26/16, Hannes Tschofenig wrote: > Hi Randy, > > I believe we should reach out to the IESG and ask them a question about > their approach regarding formal languages and the use of data definition > languages in particular. > > It seems that we are not particularly lucky in the IETF with the use of > formal languages for describing protocol exchanges. While we excessively > use them we often get them wrong for a number of reasons. > > In this specific case it seems that the authors of the XML xcard spec > got it wrong and fixed the bug in a way that is also violating the way > how these formal language is supposed to work. The correct way IMHO > would have been to issue a new schema (+ new namespace + new schema > registration). For whatever reason they haven't gone that route. > > Now, for us the question is why cannot we cheat here as well? > Or, to phrase it differently, does anyone even care about these data > definition languages at all in IETF documents. > > Ciao > Hannes > > > On 03/22/2016 01:05 AM, Randall Gellens wrote: >> So, I think we have three remaining open questions, which are: >> >> Should we go with -38 as it is (new namespace and schema normative) or >> >> (1) Revert namespace to original name? >> (2) Revert schema to informative? >> (3) Do we add to the schema "x-" and "vnd-" tokens as well as IANA tokens? >> >> >> At 8:31 PM +0100 3/21/16, Hannes Tschofenig wrote: >> >>> Hi Dan, >>> >>> the situation looks a bit tricky. >>> >>> It seems that accepting the errata wasn't quite the right thing since it >>> changes an XML schema without defining a new namespace and without >>> registering the new schema. >>> >>> In some sense, we could be equally "relaxed" and just change their >>> schema again (without changing the namespace). >>> >>> I believe it ultimately boils down to the question what the value of the >>> XML schema actually is. >>> >>> I see a couple of different usages: >>> >>> a) If someone uses the XML schema to generate code then anything other >>> than defining our own, corrected XML schema will lead to problems >>> >>> b) If the XML schema is only used by an implementer to validate instance >>> documents than defining our own, corrected XML schema will also be >>> needed. >>> >>> c) If the XML schema is, however, only used as a different way of >>> reading the document content then changing the schema within the text >>> (as we had done up to version -37) is fine. >>> >>> I personally think that most developers don't do (a) and (b) and that's >>> why most of the XML schemas in technical specifications are actually >>> broken (not only in the IETF but also elsewhere). The "most developers" > >> is important here since we have found developers, such as Philip, who >>> actually produce code based on the schema (which is why he found >>> problems). >>> >>> However, by making these types of "fixes" we are obviously not going to >>> improve the situation. It is also the question what the IESG and the >>> area directors think about this situation. In some sense it is not only >>> about the use of XML schemas but the issue is a bit more broadly related >>> to the use of formal languages in the IETF in general. There are many >>> other places where we messed things up, such as with ABNF. >>> >>> Ultimately, it fear it will boil down to a different question, namely: >>> What does it mean if the VCard schema in our spec is different from the > >> original VCard schema in terms of re-use with existing software. >>> >>> Ciao >>> Hannes >>> >>> >>> On 03/21/2016 05:20 PM, Dan Banks wrote: >>>> I'm not entirely sure this is the right way to go. >>>> >>>> First, if the values can only come from the registry, that still >>>> excludes the x-name values (which seems to me to be nearly as big of >>>> an omission as leaving out the iana-token values). >>>> >>>> Second, is changing the namespace really necessary? Perhaps I don't >>>> understand the errata process correctly, but James' argument that the >>>> RFC 6351 schema error requires it does not seem persuasive to me in >>>> light of the existing errata already being verified status (as >>>> opposed to held for update). That suggests to me that any RFC 6351 >>>> implementation should take this errata into account. >>>> >>>> Changing the namespace also brings new complications: the xCards will >>>> not be interoperable with an RFC 6351 implementation (even one that >>>> considers the errata), and the Appendix A schema would have to be >>>> normative. This essentially redefines the entire xCard schema with >>>> an XML schema when the previous version was a Relax NG schema. This >>>> doesn't seem like a good idea to me. >>>> >>>> Dan Banks >>>> >>>> -----Original Message----- From: Hannes Tschofenig >>>> [mailto:hannes.tschofenig@gmx.net] Sent: Sunday, March 20, 2016 9:09 >>>> AM To: Randall Gellens; James Winterbottom Cc: Dan Banks; Andrew >>>> Newton; ecrit@ietf.org Subject: Re: [Ecrit] Additional Data Draft >>>> (again) >>>> >>>> Hi Randy, Hi James, >>>> >>>> the proposal makes sense to me an I have been working on an update to >>> > reflect these changes. >>>> >>>> Here is the link to the work in progress document: >>>> >>>> >>>> https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-38.txt >>>> >>>> >>>> Ciao Hannes >>>> >>>> On 03/19/2016 12:20 AM, Randall Gellens wrote: >>>>> Thanks for listing the steps, James. >>>>> >>>>> Hannes, does this sound like the plan to you? >>>>> >>>>> Brian, do you concur? >>>>> >>>>> Thanks everyone. >>>>> >>>>> At 9:05 AM +1100 3/19/16, James Winterbottom wrote: >>>>> >>>>>> So, just make sure I am clear on what the plan is: 1) Remove the >>>>>> enumeration for the schema so all values now come from the >>>>>> registry only 2) Add main number to the registry 3) Change the >>>>>> namespace 4) Update all examples to use the new namespace 5) >>>>>> register the namespace and schema with IANA >>>>>> >>>>>> Cheers James >>>>>> >>>>>> >>>>>> >>>>>>> On 19 Mar 2016, at 8:51 am, Randall Gellens >>>>>>> wrote: >>>>>>> >>>>>>> I'm OK with changing the namespace if we need to. >>>>>>> >>>>>>> At 6:51 PM +1100 3/17/16, James Winterbottom wrote: >>>>>>> >>>>>>>> I think that the general approach is okay, I remain >>>>>>>> unconvinced that we don't need a new namespace however, >>>>>>>> because the schema in RFC 6351 is normative and it has an >>>>>>>> error and our solution requires the error be corrected. >>>>>>>> >>>>>>>> Cheers James >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 17 Mar 2016, at 5:54 am, Randall Gellens >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> At 3:50 PM +0000 3/16/16, Dan Banks wrote: >>>>>>>>> >>>>>>>>>> I am not very familiar with the process around updating >>>>>>>>>> documents, but to me this suggests: - we should not need > >>>>>>>>> to do an update to RFC 6351, - we should fix the >>>>>>>>>> informative schema in the additional data document to >>>>>>>>>> take into account the verified errata (there are >>>>>>>>>> several), - we should seek review of "main-number" as an >>>>>>>>>> addition to the registry, and update the additional data >>>>>>>>>> draft to formally make that addition. >>>>>>>>> >>>>>>>>> This sounds reasonable to me. We also won't need to change >>>>>>>>> the namespace. >>>>>>>>> >>>>>>>>> -- Randall Gellens Opinions are personal; facts are >>>>>>>>> suspect; I speak for myself only -------------- Randomly >>>>>>>>> selected tag: --------------- A list is only as strong as >>>>>>>>> its weakest link. --Donald Knuth > >>>>>> >>>>>>> >>>>>>> -- Randall Gellens Opinions are personal; facts are suspect; >>>>>>> I speak for myself only -------------- Randomly selected tag: >>>>>>> --------------- 640K ought to be enough for anybody. --Bill >>>>>>> Gates, 1981 >>>>> >>>>> >>>> >>> >>> >>> >>> Content-Type: application/pgp-signature; name="signature.asc" >>> Content-Description: OpenPGP digital signature >>> Content-Disposition: attachment; filename="signature.asc" >>> >>> Attachment converted: TiLand:signature 1702.asc ( / ) (0331F6EF) >> >> > > > > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > Attachment converted: TiLand:signature 1719.asc ( / ) (0336FF14) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Do not condemn the judgement of another because it differs from your own. You may both be wrong. --Dandemis