From internet-drafts@ietf.org Sat Sep 3 05:45:32 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9DA21F8B45; Sat, 3 Sep 2011 05:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtC8t+d5Lydq; Sat, 3 Sep 2011 05:45:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8BE21F8B28; Sat, 3 Sep 2011 05:45:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110903124532.32010.84040.idtracker@ietfa.amsl.com> Date: Sat, 03 Sep 2011 05:45:32 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-phonebcp-19.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 12:45:33 -0000 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 Int= ernet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in sup= port of Emergency Calling Author(s) : Brian Rosen James Polk Filename : draft-ietf-ecrit-phonebcp-19.txt Pages : 26 Date : 2011-09-02 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services using IETF protocols should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-19.txt From brian.rosen@neustar.biz Tue Sep 6 07:56:40 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3321F8ABE for ; Tue, 6 Sep 2011 07:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXWy-8OXxROD for ; Tue, 6 Sep 2011 07:56:39 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 970E821F8A97 for ; Tue, 6 Sep 2011 07:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315321098; x=1630345295; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=5reDACPLii4bVoGl31t2Z WFCg/4/BUyH+V38ZqAXWdE=; b=Fcgqn2FuMRR3FA6Q2frW5zUdkUqwzE4jTM/j4 rkzz9ywtjemtxnmkgs82EUG3SoS2EeAUDGvcPlYsCyDtVRhkg== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.42727588; Tue, 06 Sep 2011 10:58:17 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 6 Sep 2011 10:58:16 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Tue, 6 Sep 2011 10:58:15 -0400 Thread-Topic: phonebcp-19 missing two edits Thread-Index: AcxspWg/YmX8RR72RdiPPkNbDyHYHA== Message-ID: <06155021-FE26-4ED2-90FF-BFE212901894@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3Zf65Pl64TW8zJiFvYxl9w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , Stephen Farrell Subject: [Ecrit] phonebcp-19 missing two edits X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 14:56:40 -0000 I apparently managed to screw up versions and dropped two edits I had made.= A -20 should appear shortly. That will: a) Change ED-1 to meet a DISCUSS raised by Stephen Farrell. ED-1 will read= : ED-1 A device or application that implements SIP calling SHOULD support emergency calling. Some jurisdictions have regulations governing which devices need to support emergency calling and developers are encouraged to ensure that devices they develop meet relevant regulatory requirements. Unfortunately, the natural variation in those regulations also makes it impossible to accurately describe the cases when developers do or do not have to support emergency calling. b) Add some text in front of section 6.5 that talks about the conflicts bet= ween end system measured and access network provided location to address a = concern raised by Pete Resnick: Obtaining location from the access network may be preferable even if the de= vice can measure its own location, especially indoors where most measuremen= t mechanisms are not accurate enough. This sections requirements do not ap= ply to devices that can accurately measure their own location. Brian= From forte@att.com Tue Sep 6 08:50:11 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624A121F8C3D for ; Tue, 6 Sep 2011 08:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjaPGzvYUpJf for ; Tue, 6 Sep 2011 08:50:10 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id D68A421F8BB1 for ; Tue, 6 Sep 2011 08:50:10 -0700 (PDT) X-Env-Sender: forte@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1315324315!17924508!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11066 invoked from network); 6 Sep 2011 15:51:56 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Sep 2011 15:51:56 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p86FqLe1018389; Tue, 6 Sep 2011 11:52:21 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p86FqJeG018371; Tue, 6 Sep 2011 11:52:20 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p86FpqoK008857; Tue, 6 Sep 2011 11:51:53 -0400 Received: from [151.109.8.213] (dn151-109-8-213.dhcpn.ugn.att.com [151.109.8.213]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p86FpkhO008718; Tue, 6 Sep 2011 11:51:47 -0400 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Tue, 06 Sep 2011 11:51:45 -0400 From: "Andrea G. Forte" To: "Rosen, Brian" , "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] phonebcp-19 missing two edits In-Reply-To: <06155021-FE26-4ED2-90FF-BFE212901894@neustar.biz> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Pete Resnick , Stephen Farrell Subject: Re: [Ecrit] phonebcp-19 missing two edits X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 15:50:11 -0000 Brian, Regarding point b, who decides what "accurately measure" means? Is it already discussed somewhere else? Thanks, -Andrea On 9/6/11 10:58 AM, "Rosen, Brian" wrote: >I apparently managed to screw up versions and dropped two edits I had >made. A -20 should appear shortly. That will: >a) Change ED-1 to meet a DISCUSS raised by Stephen Farrell. ED-1 will >read: >ED-1 A device or application that implements SIP calling SHOULD > support emergency calling. Some jurisdictions have regulations > governing which devices need to support emergency calling and > developers are encouraged to ensure that devices they develop > meet relevant regulatory requirements. Unfortunately, the > natural variation in those regulations also makes it impossible > to accurately describe the cases when developers do or do not have > to support emergency calling. > >b) Add some text in front of section 6.5 that talks about the conflicts >between end system measured and access network provided location to >address a concern raised by Pete Resnick: >Obtaining location from the access network may be preferable even if the >device can measure its own location, especially indoors where most >measurement mechanisms are not accurate enough. This sections >requirements do not apply to devices that can accurately measure their >own location. > >Brian >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Tue Sep 6 08:59:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5558D21F8C54 for ; Tue, 6 Sep 2011 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEsloVmRcj-g for ; Tue, 6 Sep 2011 08:59:42 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7501821F8C31 for ; Tue, 6 Sep 2011 08:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315324887; x=1630672852; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=+/gyL/vg5Adz3SCpf6+9+ Ec1VkKRJt4LviqDUTvCPHM=; b=DXQPbXTKWL5UA/N1ij9iRKsmvq0C+HnWsDx4q g4dFvZ2l5H1E7PJtn6eqfLtJpRX0vUCrjSBm7nhhq5kWtJ8MA== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.26653799; Tue, 06 Sep 2011 12:01:26 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 6 Sep 2011 12:01:25 -0400 From: "Rosen, Brian" To: "FORTE, ANDREA G" Date: Tue, 6 Sep 2011 12:01:24 -0400 Thread-Topic: [Ecrit] phonebcp-19 missing two edits Thread-Index: AcxsrjpATPF43wnfTDWdO6rIZbpWew== Message-ID: <58B05802-B48B-4D18-9359-5994268D42DF@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wv89Nu1ttOu5+m78oBbfGA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , "ecrit@ietf.org Org" , Stephen Farrell Subject: Re: [Ecrit] phonebcp-19 missing two edits X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 15:59:43 -0000 In every nation, so far, that is a regulatory matter, and it changes over t= ime as the technology improves. Brian On Sep 6, 2011, at 11:49 AM, FORTE, ANDREA G wrote: > Brian, >=20 > Regarding point b, who decides what "accurately measure" means? Is it > already discussed somewhere else? >=20 > Thanks, > -Andrea >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 9/6/11 10:58 AM, "Rosen, Brian" wrote: >=20 >> I apparently managed to screw up versions and dropped two edits I had >> made. A -20 should appear shortly. That will: >> a) Change ED-1 to meet a DISCUSS raised by Stephen Farrell. ED-1 will >> read: >> ED-1 A device or application that implements SIP calling SHOULD >> support emergency calling. Some jurisdictions have regulations >> governing which devices need to support emergency calling and >> developers are encouraged to ensure that devices they develop >> meet relevant regulatory requirements. Unfortunately, the >> natural variation in those regulations also makes it impossible >> to accurately describe the cases when developers do or do not have >> to support emergency calling. >>=20 >> b) Add some text in front of section 6.5 that talks about the conflicts >> between end system measured and access network provided location to >> address a concern raised by Pete Resnick: >> Obtaining location from the access network may be preferable even if the >> device can measure its own location, especially indoors where most >> measurement mechanisms are not accurate enough. This sections >> requirements do not apply to devices that can accurately measure their >> own location. >>=20 >> Brian >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From internet-drafts@ietf.org Tue Sep 6 16:29:04 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EA21F8E1F; Tue, 6 Sep 2011 16:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoN5JG5WqBh9; Tue, 6 Sep 2011 16:29:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B421F8DDF; Tue, 6 Sep 2011 16:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110906232903.11531.56681.idtracker@ietfa.amsl.com> Date: Tue, 06 Sep 2011 16:29:03 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-phonebcp-20.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 23:29:04 -0000 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 Int= ernet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in sup= port of Emergency Calling Author(s) : Brian Rosen James Polk Filename : draft-ietf-ecrit-phonebcp-20.txt Pages : 26 Date : 2011-09-06 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services using IETF protocols should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-20.txt From brian.rosen@neustar.biz Wed Sep 7 12:37:41 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BFE21F8AD9 for ; Wed, 7 Sep 2011 12:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8QHnNEvAESi for ; Wed, 7 Sep 2011 12:37:41 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B978E21F8AD8 for ; Wed, 7 Sep 2011 12:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1315424369; x=1630660308; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=n4xIF5IFcSXS3kWwO6DFH 1AsJEfgPZ/Maaosfeu9ntY=; b=D5alxGPYKrQx6Yv4GDJhlw6ArtX6qDqp2xvMC u1CghxrR/plIyZMt30EtIdGcu82IUDiw9XlFuN6enbMqpAb2A== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.49289505; Wed, 07 Sep 2011 15:39:28 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 7 Sep 2011 15:39:27 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Wed, 7 Sep 2011 15:39:27 -0400 Thread-Topic: Qualcomm IPR on -framework Thread-Index: Acxtldq/9K7UBE4QS0alKzGjRdqi6w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hlDmyy9evZP2a8zByRgS9Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Qualcomm IPR on -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 19:37:41 -0000 https://datatracker.ietf.org/ipr/1395/ is an IPR claim on -framework. There is little discussion on this, and it = occurred after WG LC. I want to make sure that this announcement doesn't c= ause anyone to want to change anything in -framework. I personally don't want to change anything. Brian= From internet-drafts@ietf.org Wed Sep 7 17:20:38 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1EB21F8DAA; Wed, 7 Sep 2011 17:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH5MLQ2lAAg6; Wed, 7 Sep 2011 17:20:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A439021F8D87; Wed, 7 Sep 2011 17:20:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110908002037.11731.17824.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 17:20:37 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-framework-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 00:20:38 -0000 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 Int= ernet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : Brian Rosen Henning Schulzrinne James Polk Andrew Newton Filename : draft-ietf-ecrit-framework-13.txt Pages : 37 Date : 2011-09-07 The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-framework-13.txt From mlinsner@cisco.com Thu Sep 8 05:32:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465E21F8B1A for ; Thu, 8 Sep 2011 05:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz3mePXesscF for ; Thu, 8 Sep 2011 05:32:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9E21F8B0B for ; Thu, 8 Sep 2011 05:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=861; q=dns/txt; s=iport; t=1315485259; x=1316694859; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=oKIUtBqic0dRrNvgpNL+dnD+zjs+dR3ajzaPuc6Tm2c=; b=K4Bp/sAw9bve5NmG4Wg/cBfshZjqrQFcYU7gb9txng+xj1vx2kNlepzK WfR9OPDlQGtUHQot+Oo3zJgcAmNRF/aDa6BCA+mR++/2YtzAYY5nIFzDs BhzcN/90QLdgIwhR2Z4H12P4guAcQXSLOvIt0foDP0SZfoVkQd8ocOYjg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHO1aE6tJV2d/2dsb2JhbABDp394gUYBAQEBAwEBAQ8BJwIBMRcHCBEDAQJWKAgGEwkZh1eYbIEjAZ4khm0EkzOFEowg X-IronPort-AV: E=Sophos;i="4.68,350,1312156800"; d="scan'208";a="20053938" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 08 Sep 2011 12:34:19 +0000 Received: from [10.116.195.120] (rtp-mlinsner-8717.cisco.com [10.116.195.120]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p88CYFp3016287 for ; Thu, 8 Sep 2011 12:34:17 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 08 Sep 2011 08:34:14 -0400 From: Marc Linsner To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] Qualcomm IPR on -framework In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Qualcomm IPR on -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 12:32:27 -0000 FWIW, this was announced to the list on 8-31-10 with no ensuing discussion. (Of course, this doesn't prevent discussion now). http://www.ietf.org/mail-archive/web/ecrit/current/msg07307.html -Marc- -----Original Message----- From: "Rosen, Brian" Date: Wed, 7 Sep 2011 15:39:27 -0400 To: "ecrit@ietf.org Org" Subject: [Ecrit] Qualcomm IPR on -framework >https://datatracker.ietf.org/ipr/1395/ > >is an IPR claim on -framework. There is little discussion on this, and >it occurred after WG LC. I want to make sure that this announcement >doesn't cause anyone to want to change anything in -framework. > >I personally don't want to change anything. > >Brian >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Thu Sep 8 05:35:07 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35221F8B23 for ; Thu, 8 Sep 2011 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB4U5Abtoq1V for ; Thu, 8 Sep 2011 05:35:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C846121F8B1A for ; Thu, 8 Sep 2011 05:35:05 -0700 (PDT) Received: (qmail invoked by alias); 08 Sep 2011 12:36:56 -0000 Received: from unknown (EHLO [10.255.129.89]) [192.100.123.77] by mail.gmx.net (mp070) with SMTP; 08 Sep 2011 14:36:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+nmAYc59mnTAPwcU2Ql3+vUmphONyAX1SQFXetkU 1Ru+PRfFOTAE5R Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801210F8FCE66@SISPE7MB1.commscope.com> Date: Thu, 8 Sep 2011 15:36:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0062F316-B3D0-4387-A9C7-FC109CBC0E02@gmx.net> References: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@SISPE7MB1.commscope.com> <13946585-11A9-4595-B64C-69AFBE06809C@gmx.net> <5A55A45AE77F5941B18E5457ECAC818801210F8FCE66@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 12:35:07 -0000 Hi James,=20 thank you for your response.=20 On Sep 1, 2011, at 2:43 AM, Winterbottom, James wrote: > Hi Hannes, >=20 > Thanks for the response. Please see comments inline. >=20 > Cheers > James >=20 > James Winterbottom > Global Product Manager > CommScope GeoLENs > IP Location Product Portfolio > Email: james.winterbottom@commscope.com > Phone: +61-2-42-212938 > Mobile: +61-447-773-560 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: Tuesday, 30 August 2011 3:55 AM >> To: Winterbottom, James >> Cc: Hannes Tschofenig; ecrit@ietf.org >> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 >>=20 >> Hey James, >>=20 >> thank you for your timely review. >>=20 >> On Aug 16, 2011, at 9:15 AM, Winterbottom, James wrote: >>=20 >>> Hi All, >>>=20 >>> I have been reading this document closely with an eye to = implementing >> it, and have the following substantial comments: >>>=20 >>> 1) Much of the document describes specific XML elements, but without >> having an up to date schema this becomes very hard follow. I see the >> schema as being a critical update required by this document. If you = need >> or want help in producing the schema please let me know and I will = try to >> help. >>=20 >> While I fully agree that we need to get this document finished I am = not >> sure we really need an XML schema at all. Over the time I have gotten = the >> impression that an XML schema is really a waste of time. It creates = the >> illusion that there is something that provides help (to implementers = and >> to those who read the specification) but in reality it doesn't. >=20 > [AJW] I don't agree with this. I think that this means that we need to = compile ALL examples and make sure that they are valid against the = provided schema. I also think that developers that are hardcoding this = stuff are in for a likely world of hurt when it comes to = interoperability with vendors that do implement against the schema. For = me the schema is the place that I go to see if things are correctly = formatted or not. In most cases, we use XML parsers that require schema = in order to work optimally. Not providing a schema means that there is = no definitive place to look when interoperability issues arise. If there is no schema then you need to validate the examples against the = schema either.=20 In our case the XML schema will not tell a lot anyway given that we have = structures in there that aren't even XML encoded (such as the VCard, as = it is currently specified).=20 Furthermore, the extensibility mechanism of XML would prevent you from = getting any meaningful validation anyway.=20 I would be more in favor of us providing some tools (as reference = implementation) that=20 a) produce a correct XML based on some given input, and b) verify a provided XML document for correctness.=20 This would allow us to verify correctness for all parts of the = specification, including those parts that cannot be covered by the XML = schema itself.=20 I am convinced that this provides much, much more value! >=20 >>=20 >> Working on different specification I later thought that the problem = is >> with the readability and extensibility of the XML schema and then (as = you >> may recall) we switched to Relax NG. That turned to be a mistake as = well. >> When it comes to extensibility a Relax NG schema is equally bad. >=20 > [AJW] I don't know that I agree with this either. My main issue with = specifying schemas in RelaxNG is that there are simply not enough tools = and parser libraries available to just take the schema and use it. In = cases where only a RelaxNG schema is provided we have had to go and = write the equivalent schema in xsd first. For this reason alone I think = agreeing on a single standard is best, and I would prefer that this was = xsd. >=20 > I certainly don't agree that the schema definition language is the = problem when it comes to specifying extension points, this is simply a = matter of good design and deciding how a schema ought to be extended = ahead of time and perhaps documenting the rationale for this decision. >=20 >=20 I don't believe that a real developer actually uses the XML schema. Of = course they will be using XML parsers but that's an independent of the = actual schema description.=20 >>=20 >> So, I believe we are doing fine without XML schema but with lots of >> examples. Implementers just look at examples. Nobody generates codes >> directly from an XML schema. >>=20 >> This may sound a bit revolutionary but what do you think? What this = work >> for us? >=20 > [AJW] I don't agree and I would like to see a formal set of schemas. I = would like to a base schema with the common object definitions, and then = a schema for each of the 3 provider types, owner, access and voice. >=20 >=20 >>=20 >>>=20 >>> 2) Section 3.1.2 in the Note says that this field must be the NENA >> company ID in the US. I think that this text needs to be revised to = say >> something along the lines of "for example in the US this could be the = NENA >> company ID", since this document hasn't been finalized it is not >> appropriate for the IETF to dictate what NENA must do. >>=20 >> Certainly correct. A mistake when we copied the text from the = original >> NENA spec. >>=20 >>>=20 >>> 3) I have argued against the inclusion of vCard into this data = structure >> countless times in multiple forums, and I know that Brian and I are >> unlikely to agree on its applicability here. Having said that, if we = are >> going to include vCard, then the need for the separate elements in >> sections 3.1.3 and 3.1.4 is not apparent to me when they can be = captured >> in 3.1.5 and hence keep all of the operator data together. >>=20 >> Given that we have made the mistake already to blindly copy the CAP >> structure for the data only emergency calls I think we need to = double- >> check very carefully what we need from the vCard structure. >>=20 >> Additionally, we have to consider that the additional data is an XML >> structure at the moment and the vCard encoding is not XML-based, if I >> understood that correctly. I don't believe we want to mash different >> encodings together in a single structure, right? >> Only if we use = http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-1 >> we get the XML encoding of a vCard and I am not sure about the >> availability of existing libraries. So, it seems that one really = starts >> from zero (implementation-wise). >=20 > [AJW] My suggestion would be that you simply import the vcardxml = schema (yes, it is RelaxNG and that is unfortunate), but the defined XML = object coming out the other end should then at least be correct.=20 >=20 Do you know the status of that work? The referenced document is a draft = and I am not sure about the expected completion date (if it will be = completed at all).=20 Mixing a Relax NG schema and an XML schema isn't that easy.... =20 >>=20 >> Currently, we use the vCard in two places: >> - 3.1.5. vCARD of Data Provider >> - 3.5.1. vCARD for Subscriber's Data >>=20 >>=20 >>>=20 >>> 4) The description in 3.1.3 says "If a telephone number is the = contact >> address it should be provided in the form of >> sip:telephonenumber@serviceprovider:user=3Dphone". It seems to me = that this >> would more sensibly be provided as a teluri. >> Sounds OK for me. >>=20 > [AJW] Okay >=20 >>>=20 >>> 5) Operators may provide more than one means for providing 24x7 = support. >> Is this allowed here, because it isn't described in section 3.1.3? >> I believe we have to support more than one means to contact a data >> provider. >>=20 > [AJW] Okay >=20 >=20 >>>=20 >>> 6) I think that a lot more rigor needs to go into the description = and >> definitions for . It seems to conflate the issues = of the >> type of access medium and the notional service-type being provided. = It >> would be much cleaner to have two separate fields as this will make = the >> intent clearer. For example the first registry item listed and the = last >> registry item listed may be mutually inclusive, for this field to = have any >> real value then it needs to be unambiguous. Instead this could be = broken >> up into (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, = ADSL, >> Cable ..) and (VoIP, One way outbound, Pay Phone, MLTS ...) >>>=20 >> I agree with you >>=20 >>> 7) suffers from the same problem that >> does in that the fields are not mutually = exclusive, and >> so this will cause confusion. For example, what is the difference = between >> "Tablet computing device", and "Internet Tablet", or "mobile handset" = and >> "Smart phone"? My recommendation here would be to reduce the number = of >> things in this list substantially so that the general "type" of thing = is >> known (you can provided examples as to what falls in what category). = If >> more information is required in some circumstances then have a >> "description" field in the data type that allows for anything extra = to be >> provided. >>=20 >> Also agree. I don't have an good suggestion for a categorization = either >> nor do I fully understand what call takers could use that data for. I = will >> ask within NENA & EENA. >>=20 > [AJW] Okay this looks like it is an area for further research and = investigation then. This is my view; others may have different opinion.=20 In my discussions I encountered the following problems. If I ask call = takers then they claim that they do not know these new technologies and = have not being using any of them so they cannot provide any feedback = whether information about the different classes would make sense for = them. If we ask those working with the technology I receive the answer = that they do not know what the call takers would want to see. >=20 >=20 >>>=20 >>> 8) 3.5 the use of the term subscriber is problematic and has = particular >> service model connotations that may not be applicable. I would like = to see >> this changed to owner, and for "addCallSub" to be changed to >> "addOwnerData" or "addCallerData" or something like that. >>=20 >> The term "subscriber" fits the text. The term "owner" is a bit funny = in >> the context of a VoIP services without an actual hardware device. >>=20 > [AJW] My concern with the use of the word "subscriber" is its = connotations with voice subscription services, and a voice subscription = service is not required in this calling environment, it is only one = option. I guess if we include subscription to include Internet access = subscription then it is okay, but I would prefer a different term if = possible. I believe we could clarify this specific aspect.=20 >=20 >=20 >>>=20 >>> I have one nit, and that is to do with the version in the document = still >> being shown as -00 when it should be -01. >> Another bug. >>=20 >> A question that I had raised recently was whether we should use XML = as an >> encoding or rather switch to JSON. Of course with all the other XML = stuff >> we already have the benefits may not entirely be there but I still = want to >> raise that issue. >> I wonder whether you have an opinion about this. >=20 > [AJW] I don't really have an opinion either way, if JSON lets us = define schemas with adequate constraint mechanisms then I am okay with = it. What I would like to see some a consistent approach across future = IETF documents though, with one schema definition being the preferred = one, and use of an alternative requiring demonstration that the = preferred mechanism doesn't fit. >=20 Well. We will not be able to define that "policy" in the ECRIT working = group. Ciao Hannes >=20 >>=20 >> Ciao >> Hannes >>=20 >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Thu Sep 8 06:50:36 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC121F8B7F for ; Thu, 8 Sep 2011 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD22yaxyx8dT for ; Thu, 8 Sep 2011 06:50:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6291621F8997 for ; Thu, 8 Sep 2011 06:50:35 -0700 (PDT) Received: from [192.1.255.224] (port=53777 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R1f1m-0004zW-TW; Thu, 08 Sep 2011 09:52:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 8 Sep 2011 09:52:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55E5A93B-0A7A-4A2C-A7D6-0F0B601F85A5@bbn.com> References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Qualcomm IPR on -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:50:36 -0000 I don't see how this group can take any action based on this filing, = given that there's no information about the technical content of the IPR = in question. In light of that, I'm inclined to proceed as before. --Richard On Sep 7, 2011, at 3:39 PM, Rosen, Brian wrote: > https://datatracker.ietf.org/ipr/1395/ >=20 > is an IPR claim on -framework. There is little discussion on this, = and it occurred after WG LC. I want to make sure that this announcement = doesn't cause anyone to want to change anything in -framework. >=20 > I personally don't want to change anything. >=20 > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Thu Sep 8 10:39:02 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61C721F8B88 for ; Thu, 8 Sep 2011 10:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgk3pJLpbUcp for ; Thu, 8 Sep 2011 10:39:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DD36D21F8B6E for ; Thu, 8 Sep 2011 10:39:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p88HerJf026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Sep 2011 19:40:53 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p88HerOl007022 for ; Thu, 8 Sep 2011 19:40:53 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 19:40:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6E4E.74B7E0C8" Date: Thu, 8 Sep 2011 20:40:52 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D89F1B3@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Procedural Questions to the Group Thread-Index: AcxuTnQUOAUy90B8RXydkIPh9z3oZQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 08 Sep 2011 17:40:53.0469 (UTC) FILETIME=[74E6D0D0:01CC6E4E] Subject: [Ecrit] Procedural Questions to the Group X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 17:39:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6E4E.74B7E0C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 During the discussions of the additional data specification we had noticed a couple of issues that are worth bringing to the attention of the group. The topic concerns schema specifications with the work around the additional data work.=20 In various IETF specifications that make use of XML one can find either an XML schema or a Relax NG schema.=20 Strictly speaking a schema is NOT needed. There is, however, the believe that it adds some value although I believe it actually causes more confusion than it helps but we can discuss this.=20 In any case, we have used Relax NG schema in many ECRIT specifications because we thought it provides better extensiblity properties but we were completely wrong. When you extend a Relax NG or a XML schema then the value on gets from validation goes to zero.=20 Now, in the additional data specification we have the issue that we fold-in content from various sources, including a Vcard specification (which, if used as currently specified, does not even use an XML encoding). =20 Furthermore, XML has gotten less favorable over time (because it is very verbose and XML digital signatures are painful) and they have decided to switch to something new, namely JSON. JSON is less verbose and the preferred choice in the Web development community.=20 The question for me is whether we should consider a switch to JSON because the question about the schema then becomes irrelevant or should we stay with XML and make a decision regarding the schema and a way forward with the additional data specification.=20 I personally believe that JSON would be a better choice.=20 Even if we stay with XML then I would prefer to omit the schema altogether and instead work on reference implementations for tools that allow us to create compliant XML instance documents and to verify those. Ciao Hannes ------_=_NextPart_001_01CC6E4E.74B7E0C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Procedural Questions to the Group

Hi all,

During the discussions of the = additional data specification we had noticed a couple of issues that are = worth bringing to the attention of the group. The topic concerns schema = specifications with the work around the additional data work. =

In various IETF specifications that = make use of XML one can find either an XML schema or a Relax NG schema. =

Strictly speaking a schema is NOT = needed. There is, however, the believe that it adds some value although = I believe it actually causes more confusion than it helps but we can = discuss this.

In any case, we have used Relax NG = schema in many ECRIT specifications because we thought it provides = better extensiblity properties but we were completely wrong. When you = extend a Relax NG or a XML schema then the value on gets from validation = goes to zero.

Now, in the additional data = specification we have the issue that we fold-in content from various = sources, including a Vcard specification (which, if used as currently = specified, does not even use an XML encoding). 

Furthermore, XML has gotten less = favorable over time (because it is very verbose and XML digital = signatures are painful) and they have decided to switch to something = new, namely JSON. JSON is less verbose and the preferred choice in the = Web development community.

The question for me is whether we = should consider a switch to JSON because the question about the schema = then becomes irrelevant or should we stay with XML and make a decision = regarding the schema and a way forward with the additional data = specification.

I personally believe that JSON would be = a better choice.

Even if we stay with XML then I would = prefer to omit the schema altogether and instead work on reference = implementations for tools that allow us to create compliant XML instance = documents and to verify those.

Ciao
Hannes


------_=_NextPart_001_01CC6E4E.74B7E0C8-- From James.Winterbottom@commscope.com Thu Sep 8 15:16:49 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E821F8BCB for ; Thu, 8 Sep 2011 15:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Siji6boHhss for ; Thu, 8 Sep 2011 15:16:47 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67421F8AD9 for ; Thu, 8 Sep 2011 15:16:47 -0700 (PDT) X-AuditID: 0a0404e8-b7b6dae00000237b-cd-4e693f40f43a Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 00.87.09083.04F396E4; Thu, 8 Sep 2011 17:18:40 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 8 Sep 2011 17:18:39 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 8 Sep 2011 17:18:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 9 Sep 2011 06:18:36 +0800 From: "Winterbottom, James" To: Hannes Tschofenig Date: Fri, 9 Sep 2011 06:18:34 +0800 Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 Thread-Index: AcxuJAOE3jwB2eN+QKmQjyc3IIw7SAAT6JYQ Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210F8FDA33@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801210D7D8403@SISPE7MB1.commscope.com> <13946585-11A9-4595-B64C-69AFBE06809C@gmx.net> <5A55A45AE77F5941B18E5457ECAC818801210F8FCE66@SISPE7MB1.commscope.com> <0062F316-B3D0-4387-A9C7-FC109CBC0E02@gmx.net> In-Reply-To: <0062F316-B3D0-4387-A9C7-FC109CBC0E02@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 22:16:49 -0000 Hi Hannes, I don't I agree with your general sentiments below. Defining a schema forces you to think about how to structure your data, uns= tructured data has problems with it, not the least of which is the mass sta= te of confusion it causes. I can speak from experience that this a major pr= oblem with the existing additional data document as defined in NENA, and wh= y there are quite a number of very strong objectors to the whole idea of pr= oviding additional data. The more I read the additional-data draft the more I think it is taking the= wrong direction. I am reaching the opinion that it should not define the d= ata structures at all, but only provide the mechanisms to acquire and flag = the "type" of information being passed. This allows the jurisdictional enti= ties to define the actual data structures required, or the equipment vendor= s in the case of device information. My rationale for this approach is that= I don't think a schema definition is possible because there is no clear mo= del being put forward. So the proposal would be: 1) Do not define specific MIME types for the data blobs being transferred, = instead leave this aspect out of scope. 2) Instead of introducing one new Call-Info header parameter, introduce thr= ee, one for each of the data sets of user, voice-provider, access-provider.= If You need more providers introduce more parameters. 3) Allow each URI to be either a CID or an HTTPS URI. Operating in this fashion avoids the problem, and means that the text can b= e descriptive rather than normative when it comes to examples. This then al= lows NENA to go away and define the information that it wants from US provi= ders. My view is still that if you want to provide XML examples then you need a s= chema. Cheers James =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, 8 September 2011 10:37 PM > To: Winterbottom, James > Cc: Hannes Tschofenig; ecrit@ietf.org > Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 >=20 > Hi James, >=20 > thank you for your response. >=20 > On Sep 1, 2011, at 2:43 AM, Winterbottom, James wrote: >=20 > > Hi Hannes, > > > > Thanks for the response. Please see comments inline. > > > > Cheers > > James > > > > James Winterbottom > > Global Product Manager > > CommScope GeoLENs > > IP Location Product Portfolio > > Email: james.winterbottom@commscope.com > > Phone: +61-2-42-212938 > > Mobile: +61-447-773-560 > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > >> Sent: Tuesday, 30 August 2011 3:55 AM > >> To: Winterbottom, James > >> Cc: Hannes Tschofenig; ecrit@ietf.org > >> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-additional-data-01 > >> > >> Hey James, > >> > >> thank you for your timely review. > >> > >> On Aug 16, 2011, at 9:15 AM, Winterbottom, James wrote: > >> > >>> Hi All, > >>> > >>> I have been reading this document closely with an eye to implementing > >> it, and have the following substantial comments: > >>> > >>> 1) Much of the document describes specific XML elements, but without > >> having an up to date schema this becomes very hard follow. I see the > >> schema as being a critical update required by this document. If you > need > >> or want help in producing the schema please let me know and I will try > to > >> help. > >> > >> While I fully agree that we need to get this document finished I am no= t > >> sure we really need an XML schema at all. Over the time I have gotten > the > >> impression that an XML schema is really a waste of time. It creates th= e > >> illusion that there is something that provides help (to implementers > and > >> to those who read the specification) but in reality it doesn't. > > > > [AJW] I don't agree with this. I think that this means that we need to > compile ALL examples and make sure that they are valid against the > provided schema. I also think that developers that are hardcoding this > stuff are in for a likely world of hurt when it comes to interoperability > with vendors that do implement against the schema. For me the schema is > the place that I go to see if things are correctly formatted or not. In > most cases, we use XML parsers that require schema in order to work > optimally. Not providing a schema means that there is no definitive place > to look when interoperability issues arise. >=20 >=20 > If there is no schema then you need to validate the examples against the > schema either. >=20 > In our case the XML schema will not tell a lot anyway given that we have > structures in there that aren't even XML encoded (such as the VCard, as i= t > is currently specified). >=20 > Furthermore, the extensibility mechanism of XML would prevent you from > getting any meaningful validation anyway. >=20 >=20 > I would be more in favor of us providing some tools (as reference > implementation) that > a) produce a correct XML based on some given input, and > b) verify a provided XML document for correctness. >=20 > This would allow us to verify correctness for all parts of the > specification, including those parts that cannot be covered by the XML > schema itself. >=20 > I am convinced that this provides much, much more value! >=20 > > > >> > >> Working on different specification I later thought that the problem is > >> with the readability and extensibility of the XML schema and then (as > you > >> may recall) we switched to Relax NG. That turned to be a mistake as > well. > >> When it comes to extensibility a Relax NG schema is equally bad. > > > > [AJW] I don't know that I agree with this either. My main issue with > specifying schemas in RelaxNG is that there are simply not enough tools > and parser libraries available to just take the schema and use it. In > cases where only a RelaxNG schema is provided we have had to go and write > the equivalent schema in xsd first. For this reason alone I think agreein= g > on a single standard is best, and I would prefer that this was xsd. > > > > I certainly don't agree that the schema definition language is the > problem when it comes to specifying extension points, this is simply a > matter of good design and deciding how a schema ought to be extended ahea= d > of time and perhaps documenting the rationale for this decision. > > > > >=20 > I don't believe that a real developer actually uses the XML schema. Of > course they will be using XML parsers but that's an independent of the > actual schema description. >=20 > >> > >> So, I believe we are doing fine without XML schema but with lots of > >> examples. Implementers just look at examples. Nobody generates codes > >> directly from an XML schema. > >> > >> This may sound a bit revolutionary but what do you think? What this > work > >> for us? > > > > [AJW] I don't agree and I would like to see a formal set of schemas. I > would like to a base schema with the common object definitions, and then = a > schema for each of the 3 provider types, owner, access and voice. > > > > > >> > >>> > >>> 2) Section 3.1.2 in the Note says that this field must be the NENA > >> company ID in the US. I think that this text needs to be revised to sa= y > >> something along the lines of "for example in the US this could be the > NENA > >> company ID", since this document hasn't been finalized it is not > >> appropriate for the IETF to dictate what NENA must do. > >> > >> Certainly correct. A mistake when we copied the text from the original > >> NENA spec. > >> > >>> > >>> 3) I have argued against the inclusion of vCard into this data > structure > >> countless times in multiple forums, and I know that Brian and I are > >> unlikely to agree on its applicability here. Having said that, if we > are > >> going to include vCard, then the need for the separate elements in > >> sections 3.1.3 and 3.1.4 is not apparent to me when they can be > captured > >> in 3.1.5 and hence keep all of the operator data together. > >> > >> Given that we have made the mistake already to blindly copy the CAP > >> structure for the data only emergency calls I think we need to double- > >> check very carefully what we need from the vCard structure. > >> > >> Additionally, we have to consider that the additional data is an XML > >> structure at the moment and the vCard encoding is not XML-based, if I > >> understood that correctly. I don't believe we want to mash different > >> encodings together in a single structure, right? > >> Only if we use http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml= - > 1 > >> we get the XML encoding of a vCard and I am not sure about the > >> availability of existing libraries. So, it seems that one really start= s > >> from zero (implementation-wise). > > > > [AJW] My suggestion would be that you simply import the vcardxml schema > (yes, it is RelaxNG and that is unfortunate), but the defined XML object > coming out the other end should then at least be correct. > > > Do you know the status of that work? The referenced document is a draft > and I am not sure about the expected completion date (if it will be > completed at all). >=20 > Mixing a Relax NG schema and an XML schema isn't that easy.... >=20 > >> > >> Currently, we use the vCard in two places: > >> - 3.1.5. vCARD of Data Provider > >> - 3.5.1. vCARD for Subscriber's Data > >> > >> > >>> > >>> 4) The description in 3.1.3 says "If a telephone number is the contac= t > >> address it should be provided in the form of > >> sip:telephonenumber@serviceprovider:user=3Dphone". It seems to me that > this > >> would more sensibly be provided as a teluri. > >> Sounds OK for me. > >> > > [AJW] Okay > > > >>> > >>> 5) Operators may provide more than one means for providing 24x7 > support. > >> Is this allowed here, because it isn't described in section 3.1.3? > >> I believe we have to support more than one means to contact a data > >> provider. > >> > > [AJW] Okay > > > > > >>> > >>> 6) I think that a lot more rigor needs to go into the description and > >> definitions for . It seems to conflate the issues of > the > >> type of access medium and the notional service-type being provided. It > >> would be much cleaner to have two separate fields as this will make th= e > >> intent clearer. For example the first registry item listed and the las= t > >> registry item listed may be mutually inclusive, for this field to have > any > >> real value then it needs to be unambiguous. Instead this could be > broken > >> up into (WiMAX, LTE, CDMA-2000, GERAN, UTRAN, POTS, ADSL, > >> Cable ..) and (VoIP, One way outbound, Pay Phone, MLTS ...) > >>> > >> I agree with you > >> > >>> 7) suffers from the same problem that > >> does in that the fields are not mutually exclusive, > and > >> so this will cause confusion. For example, what is the difference > between > >> "Tablet computing device", and "Internet Tablet", or "mobile handset" > and > >> "Smart phone"? My recommendation here would be to reduce the number o= f > >> things in this list substantially so that the general "type" of thing > is > >> known (you can provided examples as to what falls in what category). I= f > >> more information is required in some circumstances then have a > >> "description" field in the data type that allows for anything extra to > be > >> provided. > >> > >> Also agree. I don't have an good suggestion for a categorization eithe= r > >> nor do I fully understand what call takers could use that data for. I > will > >> ask within NENA & EENA. > >> > > [AJW] Okay this looks like it is an area for further research and > investigation then. >=20 > This is my view; others may have different opinion. >=20 > In my discussions I encountered the following problems. If I ask call > takers then they claim that they do not know these new technologies and > have not being using any of them so they cannot provide any feedback > whether information about the different classes would make sense for them= . > If we ask those working with the technology I receive the answer that the= y > do not know what the call takers would want to see. >=20 >=20 > > > > > >>> > >>> 8) 3.5 the use of the term subscriber is problematic and has > particular > >> service model connotations that may not be applicable. I would like to > see > >> this changed to owner, and for "addCallSub" to be changed to > >> "addOwnerData" or "addCallerData" or something like that. > >> > >> The term "subscriber" fits the text. The term "owner" is a bit funny i= n > >> the context of a VoIP services without an actual hardware device. > >> > > [AJW] My concern with the use of the word "subscriber" is its > connotations with voice subscription services, and a voice subscription > service is not required in this calling environment, it is only one > option. I guess if we include subscription to include Internet access > subscription then it is okay, but I would prefer a different term if > possible. >=20 > I believe we could clarify this specific aspect. >=20 > > > > > >>> > >>> I have one nit, and that is to do with the version in the document > still > >> being shown as -00 when it should be -01. > >> Another bug. > >> > >> A question that I had raised recently was whether we should use XML as > an > >> encoding or rather switch to JSON. Of course with all the other XML > stuff > >> we already have the benefits may not entirely be there but I still wan= t > to > >> raise that issue. > >> I wonder whether you have an opinion about this. > > > > [AJW] I don't really have an opinion either way, if JSON lets us define > schemas with adequate constraint mechanisms then I am okay with it. What = I > would like to see some a consistent approach across future IETF documents > though, with one schema definition being the preferred one, and use of an > alternative requiring demonstration that the preferred mechanism doesn't > fit. > > > Well. We will not be able to define that "policy" in the ECRIT working > group. >=20 > Ciao > Hannes >=20 > > > >> > >> Ciao > >> Hannes > >> > >>> > >>> Cheers > >>> James > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > > From Martin.Thomson@commscope.com Thu Sep 8 16:38:37 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703C621F8B9E for ; Thu, 8 Sep 2011 16:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RODcY2qbWl66 for ; Thu, 8 Sep 2011 16:38:36 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id C447F21F8B8F for ; Thu, 8 Sep 2011 16:38:36 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-33-4e69526dc224 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id C6.DB.19263.D62596E4; Thu, 8 Sep 2011 18:40:29 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 8 Sep 2011 18:40:29 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 8 Sep 2011 18:40:29 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 9 Sep 2011 07:40:19 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , "Rosen, Brian" Date: Fri, 9 Sep 2011 07:40:17 +0800 Thread-Topic: [Ecrit] Qualcomm IPR on -framework Thread-Index: AcxuLo+PhLs+DvyaRteIkfcPX07iJwAUhJIQ Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609150@SISPE7MB1.commscope.com> References: <55E5A93B-0A7A-4A2C-A7D6-0F0B601F85A5@bbn.com> In-Reply-To: <55E5A93B-0A7A-4A2C-A7D6-0F0B601F85A5@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Qualcomm IPR on -framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 23:38:37 -0000 I concur. On 2011-09-08 at 23:52:25, Richard L. Barnes wrote: > >=20 > I don't see how this group can take any action based on this filing,=20 > given that there's no information about the technical content of the=20 > IPR in question. In light of that, I'm inclined to proceed as before. >=20 > --Richard >=20 >=20 > On Sep 7, 2011, at 3:39 PM, Rosen, Brian wrote: >=20 > > https://datatracker.ietf.org/ipr/1395/ > > > > is an IPR claim on -framework. There is little discussion on this, > and it occurred after WG LC. I want to make sure that this=20 > announcement doesn't cause anyone to want to change anything in -=20 > framework. > > > > I personally don't want to change anything. > > > > Brian From Martin.Thomson@commscope.com Thu Sep 8 17:06:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE7F21F863E for ; Thu, 8 Sep 2011 17:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yuacl2q5n4cA for ; Thu, 8 Sep 2011 17:06:22 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id A6AED21F85EC for ; Thu, 8 Sep 2011 17:06:21 -0700 (PDT) X-AuditID: 0a0404e8-b7b6dae00000237b-7b-4e6958eeefc0 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 38.19.09083.EE8596E4; Thu, 8 Sep 2011 19:08:14 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 8 Sep 2011 19:08:13 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 9 Sep 2011 08:08:11 +0800 From: "Thomson, Martin" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ECRIT Date: Fri, 9 Sep 2011 08:08:08 +0800 Thread-Topic: Procedural Questions to the Group Thread-Index: AcxuTnQUOAUy90B8RXydkIPh9z3oZQALd0zA Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609156@SISPE7MB1.commscope.com> References: <999913AB42CC9341B05A99BBF358718D89F1B3@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D89F1B3@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Procedural Questions to the Group X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 00:06:22 -0000 Having both written and used specifications that use schemas of various for= ms, there are a few key considerations: - A schema provides a formal definition of syntax. When correctly specifi= ed, this is a great aid to interoperability. Often, text descriptions of p= arameters miss key points (cardinality, syntax specifics, ordering concerns= ). Schemas help eliminate a lot of ambiguities. Having ongoing experience= with the most widely used schema language (ASN.1), I'd have to say that it= is an invaluable tool in defining complex protocols. - A good schema is difficult to specify. But that problem doesn't go away= when you remove the schema - it only moves the problem to the text. Usual= ly, that biases the specification toward ambiguity (worse interoperability)= over specificity (worse forward compatibility). - Forward compatibility is the single hardest thing to get right in any pr= otocol. With all the work on extension support in schemas, it's telling th= at the state of the art remains an approximation of type-length-value. - JSON simplifies the problem of definition by limiting the choices availab= le. Its popularity is no mere fad - it beats XML in the same way that XML = beat SGML. However, JSON doesn't do anything to address the central concer= n of rigor of specification. The fact that JSON schema [1] exists would in= dicate that there is at least some desire to make JSON-based specifications= more rigorous. - With respect to implementation, tools support for a schema is extremely i= mportant. A schema can make implementation easier. Relax NG has fewer goo= d tools, or the tools aren't as good as those for XML schemas. Or at least= that is true for the languages I am most familiar with. This is only a se= condary concern, because schemas can be constructed as a programming exerci= se, though that runs the risk of implementation divergence. I have to agree that a schema is a poor substitute for actual interoperabil= ity testing. On the other hand, rejecting the idea outright is not necessa= rily an easier path to follow. --Martin [1] http://tools.ietf.org/html/draft-zyp-json-schema-03 On 2011-09-09 at 03:40:52, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, >=20 > During the discussions of the additional data specification we had=20 > noticed a couple of issues that are worth bringing to the attention of=20 > the group. The topic concerns schema specifications with the work=20 > around the additional data work. >=20 > In various IETF specifications that make use of XML one can find=20 > either an XML schema or a Relax NG schema. >=20 > Strictly speaking a schema is NOT needed. There is, however, the=20 > believe that it adds some value although I believe it actually causes=20 > more confusion than it helps but we can discuss this. >=20 > In any case, we have used Relax NG schema in many ECRIT specifications=20 > because we thought it provides better extensiblity properties but we=20 > were completely wrong. When you extend a Relax NG or a XML schema then=20 > the value on gets from validation goes to zero. >=20 > Now, in the additional data specification we have the issue that we=20 > fold-in content from various sources, including a Vcard specification=20 > (which, if used as currently specified, does not even use an XML=20 > encoding). >=20 > Furthermore, XML has gotten less favorable over time (because it is=20 > very verbose and XML digital signatures are painful) and they have=20 > decided to switch to something new, namely JSON. JSON is less verbose=20 > and the preferred choice in the Web development community. >=20 > The question for me is whether we should consider a switch to JSON=20 > because the question about the schema then becomes irrelevant or=20 > should we stay with XML and make a decision regarding the schema and a=20 > way forward with the additional data specification. >=20 >=20 > I personally believe that JSON would be a better choice. >=20 > Even if we stay with XML then I would prefer to omit the schema=20 > altogether and instead work on reference implementations for tools=20 > that allow us to create compliant XML instance documents and to verify=20 > those. > Ciao > Hannes >=20 From hannes.tschofenig@gmx.net Fri Sep 9 00:01:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C521F8B50 for ; Fri, 9 Sep 2011 00:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.379 X-Spam-Level: X-Spam-Status: No, score=-101.379 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryhJm8ad-rEE for ; Fri, 9 Sep 2011 00:00:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 242F721F8B38 for ; Fri, 9 Sep 2011 00:00:58 -0700 (PDT) Received: (qmail invoked by alias); 09 Sep 2011 07:02:51 -0000 Received: from unknown (EHLO [10.255.135.132]) [192.100.123.77] by mail.gmx.net (mp051) with SMTP; 09 Sep 2011 09:02:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+fD6lZ9pCfG4OjFE6XDkosPf7VX5S1MQBYXvUZAy RlWL2xKlvq68Vg Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609156@SISPE7MB1.commscope.com> Date: Fri, 9 Sep 2011 10:02:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <999913AB42CC9341B05A99BBF358718D89F1B3@FIESEXC035.nsn-intra.net> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609156@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Subject: Re: [Ecrit] Procedural Questions to the Group X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 07:01:00 -0000 Hi Martin,=20 there are two problems with the schema:=20 * You have to provide a verbal description anyway. Those who read = specifications do not only want to look at a bare schema; they want to = read some human readable text. So, you are essentially describing = semantic of the protocol twice (once verbally and then again via the XML = schema). I have seen this many, many times in specifications. Everything = is at least described twice - and often not in sync.=20 * The schema lacks expressiveness so that you have to rely on a verbal = description anyway. If if you could describe everything in a schema for = a given protocol the result would look horrible. Particularly if you add = the proper extension points schemas tend to become unreadable.=20 The schema provides little help in verifying whether a given XML = instance document is correct (valid) because of the extension points and = because of the additional constraints only described in the text, i.e. = constraints not covered in the schema. The latter issue is particularly = problematic since we are often describing complex protocols.=20 I raised the JSON issue particularly because of the size aspects. With = XML we have gone quite far to convey a few bits - think about location = conveyance, for example. We had encountered that problem recently with = CAP (for the data only call in ECRIT) but also in ATOCA with alerts.=20 Why don't we go a route that really helps implementers rather than doing = something just half-way? Ciao Hannes On Sep 9, 2011, at 3:08 AM, Thomson, Martin wrote: > Having both written and used specifications that use schemas of = various forms, there are a few key considerations: >=20 > - A schema provides a formal definition of syntax. When correctly = specified, this is a great aid to interoperability. Often, text = descriptions of parameters miss key points (cardinality, syntax = specifics, ordering concerns). Schemas help eliminate a lot of = ambiguities. Having ongoing experience with the most widely used schema = language (ASN.1), I'd have to say that it is an invaluable tool in = defining complex protocols. >=20 > - A good schema is difficult to specify. But that problem doesn't go = away when you remove the schema - it only moves the problem to the text. = Usually, that biases the specification toward ambiguity (worse = interoperability) over specificity (worse forward compatibility). >=20 > - Forward compatibility is the single hardest thing to get right in = any protocol. With all the work on extension support in schemas, it's = telling that the state of the art remains an approximation of = type-length-value. >=20 > - JSON simplifies the problem of definition by limiting the choices = available. Its popularity is no mere fad - it beats XML in the same way = that XML beat SGML. However, JSON doesn't do anything to address the = central concern of rigor of specification. The fact that JSON schema = [1] exists would indicate that there is at least some desire to make = JSON-based specifications more rigorous. >=20 > - With respect to implementation, tools support for a schema is = extremely important. A schema can make implementation easier. Relax NG = has fewer good tools, or the tools aren't as good as those for XML = schemas. Or at least that is true for the languages I am most familiar = with. This is only a secondary concern, because schemas can be = constructed as a programming exercise, though that runs the risk of = implementation divergence. >=20 > I have to agree that a schema is a poor substitute for actual = interoperability testing. On the other hand, rejecting the idea = outright is not necessarily an easier path to follow. >=20 > --Martin >=20 > [1] http://tools.ietf.org/html/draft-zyp-json-schema-03 >=20 > On 2011-09-09 at 03:40:52, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >>=20 >> During the discussions of the additional data specification we had=20 >> noticed a couple of issues that are worth bringing to the attention = of=20 >> the group. The topic concerns schema specifications with the work=20 >> around the additional data work. >>=20 >> In various IETF specifications that make use of XML one can find=20 >> either an XML schema or a Relax NG schema. >>=20 >> Strictly speaking a schema is NOT needed. There is, however, the=20 >> believe that it adds some value although I believe it actually causes=20= >> more confusion than it helps but we can discuss this. >>=20 >> In any case, we have used Relax NG schema in many ECRIT = specifications=20 >> because we thought it provides better extensiblity properties but we=20= >> were completely wrong. When you extend a Relax NG or a XML schema = then=20 >> the value on gets from validation goes to zero. >>=20 >> Now, in the additional data specification we have the issue that we=20= >> fold-in content from various sources, including a Vcard specification=20= >> (which, if used as currently specified, does not even use an XML=20 >> encoding). >>=20 >> Furthermore, XML has gotten less favorable over time (because it is=20= >> very verbose and XML digital signatures are painful) and they have=20 >> decided to switch to something new, namely JSON. JSON is less verbose=20= >> and the preferred choice in the Web development community. >>=20 >> The question for me is whether we should consider a switch to JSON=20 >> because the question about the schema then becomes irrelevant or=20 >> should we stay with XML and make a decision regarding the schema and = a=20 >> way forward with the additional data specification. >>=20 >>=20 >> I personally believe that JSON would be a better choice. >>=20 >> Even if we stay with XML then I would prefer to omit the schema=20 >> altogether and instead work on reference implementations for tools=20 >> that allow us to create compliant XML instance documents and to = verify=20 >> those. >> Ciao >> Hannes >>=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@commscope.com Fri Sep 9 00:17:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E077821F8669 for ; Fri, 9 Sep 2011 00:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggVAYkn8LKV7 for ; Fri, 9 Sep 2011 00:17:41 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 921A021F863E for ; Fri, 9 Sep 2011 00:17:41 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-07-4e69be07e5eb Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 22.C2.19263.70EB96E4; Fri, 9 Sep 2011 02:19:35 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 9 Sep 2011 02:19:35 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 9 Sep 2011 02:19:35 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 9 Sep 2011 15:19:30 +0800 From: "Thomson, Martin" To: Hannes Tschofenig Date: Fri, 9 Sep 2011 15:19:28 +0800 Thread-Topic: [Ecrit] Procedural Questions to the Group Thread-Index: AcxuvoVHznreiMCDSue5V+vL+Ic0IgAAb0sA Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6091CD@SISPE7MB1.commscope.com> References: <999913AB42CC9341B05A99BBF358718D89F1B3@FIESEXC035.nsn-intra.net> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609156@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ECRIT Subject: Re: [Ecrit] Procedural Questions to the Group X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 07:17:43 -0000 Schemas define syntax only. That does allow you to concentrate your effort= s in prose on the important stuff: semantics. Doubling up is inevitable, but not necessary. TLS, for instance, does a de= cent job of avoiding discussion on cardinality, number of bits, etc... It = uses a schema language of its own devising. I use XML schema to validate messages. It's a little clunky because you ha= ve to use modified schemas so that the extension points don't end up being = "accept junk" points, but it can be done (and I'm happy to share the meagre= tools I use for this purpose if that helps anyone else). Don't misunderstand me about JSON. It think that it's a great idea. But I= don't think that it solves any of the fundamental problems. Nor does it r= eally save many bytes, if that's what you care about. --Martin On 2011-09-09 at 17:02:46, Hannes Tschofenig wrote: > Hi Martin, >=20 > there are two problems with the schema: >=20 > * You have to provide a verbal description anyway. Those who read=20 > specifications do not only want to look at a bare schema; they want to=20 > read some human readable text. So, you are essentially describing=20 > semantic of the protocol twice (once verbally and then again via the=20 > XML schema). I have seen this many, many times in specifications. > Everything is at least described twice - and often not in sync. >=20 > * The schema lacks expressiveness so that you have to rely on a verbal=20 > description anyway. If if you could describe everything in a schema=20 > for a given protocol the result would look horrible. Particularly if=20 > you add the proper extension points schemas tend to become unreadable. >=20 > The schema provides little help in verifying whether a given XML=20 > instance document is correct (valid) because of the extension points=20 > and because of the additional constraints only described in the text,=20 > i.e. constraints not covered in the schema. The latter issue is=20 > particularly problematic since we are often describing complex=20 > protocols. >=20 > I raised the JSON issue particularly because of the size aspects. With=20 > XML we have gone quite far to convey a few bits - think about location=20 > conveyance, for example. We had encountered that problem recently with=20 > CAP (for the data only call in ECRIT) but also in ATOCA with alerts. >=20 > Why don't we go a route that really helps implementers rather than=20 > doing something just half-way? >=20 > Ciao > Hannes >=20 > On Sep 9, 2011, at 3:08 AM, Thomson, Martin wrote: >=20 > > Having both written and used specifications that use schemas of > various forms, there are a few key considerations: > > > > - A schema provides a formal definition of syntax. When correctly > specified, this is a great aid to interoperability. Often, text=20 > descriptions of parameters miss key points (cardinality, syntax=20 > specifics, ordering concerns). Schemas help eliminate a lot of=20 > ambiguities. Having ongoing experience with the most widely used=20 > schema language (ASN.1), I'd have to say that it is an invaluable tool=20 > in defining complex protocols. > > > > - A good schema is difficult to specify. But that problem doesn't=20 > > go > away when you remove the schema - it only moves the problem to the=20 > text. Usually, that biases the specification toward ambiguity (worse > interoperability) over specificity (worse forward compatibility). > > > > - Forward compatibility is the single hardest thing to get right in > any protocol. With all the work on extension support in schemas, it's=20 > telling that the state of the art remains an approximation of type-=20 > length-value. > > > > - JSON simplifies the problem of definition by limiting the choices > available. Its popularity is no mere fad - it beats XML in the same=20 > way that XML beat SGML. However, JSON doesn't do anything to address=20 > the central concern of rigor of specification. The fact that JSON=20 > schema [1] exists would indicate that there is at least some desire to=20 > make JSON-based specifications more rigorous. > > > > - With respect to implementation, tools support for a schema is > extremely important. A schema can make implementation easier. Relax=20 > NG has fewer good tools, or the tools aren't as good as those for XML=20 > schemas. Or at least that is true for the languages I am most=20 > familiar with. This is only a secondary concern, because schemas can=20 > be constructed as a programming exercise, though that runs the risk of=20 > implementation divergence. > > > > I have to agree that a schema is a poor substitute for actual > interoperability testing. On the other hand, rejecting the idea=20 > outright is not necessarily an easier path to follow. > > > > --Martin > > > > [1] http://tools.ietf.org/html/draft-zyp-json-schema-03 > > > > On 2011-09-09 at 03:40:52, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Hi all, > >> > >> During the discussions of the additional data specification we had=20 > >> noticed a couple of issues that are worth bringing to the attention=20 > >> of the group. The topic concerns schema specifications with the=20 > >> work around the additional data work. > >> > >> In various IETF specifications that make use of XML one can find=20 > >> either an XML schema or a Relax NG schema. > >> > >> Strictly speaking a schema is NOT needed. There is, however, the=20 > >> believe that it adds some value although I believe it actually > causes > >> more confusion than it helps but we can discuss this. > >> > >> In any case, we have used Relax NG schema in many ECRIT=20 > >> specifications because we thought it provides better extensiblity=20 > >> properties but we were completely wrong. When you extend a Relax NG=20 > >> or a XML schema then the value on gets from validation goes to zero. > >> > >> Now, in the additional data specification we have the issue that we=20 > >> fold-in content from various sources, including a Vcard > specification > >> (which, if used as currently specified, does not even use an XML=20 > >> encoding). > >> > >> Furthermore, XML has gotten less favorable over time (because it is=20 > >> very verbose and XML digital signatures are painful) and they have=20 > >> decided to switch to something new, namely JSON. JSON is less > verbose > >> and the preferred choice in the Web development community. > >> > >> The question for me is whether we should consider a switch to JSON=20 > >> because the question about the schema then becomes irrelevant or=20 > >> should we stay with XML and make a decision regarding the schema=20 > >> and a way forward with the additional data specification. > >> > >> > >> I personally believe that JSON would be a better choice. > >> > >> Even if we stay with XML then I would prefer to omit the schema=20 > >> altogether and instead work on reference implementations for tools=20 > >> that allow us to create compliant XML instance documents and to=20 > >> verify those. > >> Ciao > >> Hannes > >> > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From iesg-secretary@ietf.org Mon Sep 12 13:28:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BDB21F8D88; Mon, 12 Sep 2011 13:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7CTQOqtvO4H; Mon, 12 Sep 2011 13:28:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AC321F8D86; Mon, 12 Sep 2011 13:28:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912202816.847.62018.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 13:28:16 -0700 Cc: ecrit chair , ecrit mailing list , RFC Editor Subject: [Ecrit] Protocol Action: 'Best Current Practice for Communications Services in support of Emergency Calling' to BCP (draft-ietf-ecrit-phonebcp-20.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 20:28:17 -0000 The IESG has approved the following document: - 'Best Current Practice for Communications Services in support of Emergency Calling' (draft-ietf-ecrit-phonebcp-20.txt) as a BCP This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/ Technical Summary This document describes how access networks, SIP user agents, proxy servers and PSAPs support emergency calling, as outlined in [I-D.ietf-ecrit-framework], which is designed to complement the present document in section headings, numbering and content. This BCP succinctly describes the requirements of end devices and applications, access networks (including enterprise access networks), service providers and PSAPs to achieve globally interoperable emergency calling on the Internet. Working Group Summary While there has been some past controversy around some of the exact wording in this document, there is overall wg consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. There was significant discussion around an Applicability Statement. Text was submitted and rejected by the WG. See: http://www.ietf.org/mail-archive/web/ecrit/current/msg06434.html Document Quality This document has had multiple WG reviews from key WG members. This document was vetted via the Emergency Services Workshop at of it¹s several meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL, NENA, IEEE, EENA, etc. Personnel Robert Sparks is responsible AD. RFC Editor Note (applies to -20) In section 6.6, ED-26/INT-20: OLD: bootstrapping, and does not use it MUST include NEW: bootstrapping, and does not use its own measurement to determine location, it MUST include From rjsparks@nostrum.com Tue Sep 13 11:20:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45BB21F8C63 for ; Tue, 13 Sep 2011 11:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZSswwmGQEuF for ; Tue, 13 Sep 2011 11:20:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46F21F8C60 for ; Tue, 13 Sep 2011 11:20:09 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-46-224.dllstx.fios.verizon.net [173.71.46.224]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8DIMEs9066087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Sep 2011 13:22:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Sep 2011 13:22:14 -0500 Message-Id: To: ecrit@ietf.org, draft-ietf-ecrit-lost-sync@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 173.71.46.224 is authenticated by a trusted mechanism) Subject: [Ecrit] AD review draft-ietf-ecrit-lost-sync-12 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 18:20:09 -0000 AD review: draft-ietf-ecrit-lost-sync-12 Summary: There are some issues to address before moving this draft to IETF LC for Experimental. 1) The last sentence of 4.1 (the section of sync source behavior) seems to talk about sync destination behavior, indicating that an attempt to delete a non-existent mapping will be silently ignored. That is contradicted by the procedures specified in section 4.2. Which was intended? 2) I don't find the types review requests for application/lostsync+xml in the archive. If it's been requested, please send me a link. Otherwise, please request that review now. 3) Does the in the RelaxNG definition stand alone, or should the document call out what lost.rng is and how to find it? 4) Julian's Sep2010 review asked the working group to consider using GET for fetches instead of POST. Was there any subsequent discussion? 5) That review also suggested an update for the xmldsig-core reference that's not reflected here. 6) Has someone verified the XML for this version of the document? Julian explicitly noted in his review that he did not verify the examples. NITS: Section 1 Paragraph 4: s/expect for/except for/ Section 1 just after figure 5 and figure 6: s/issuing the first/issues the first/ Please expand or provide pointers to the definition for PSAP and ESRP on first use. The examples use domain names (particulary in the "source" attribute value) that end in lost-example.com. Can you change those to use lost.example.com to better align with 2606? Section 5 2nd paragraph: s/to HTTP-level/to disable HTTP-level/ (That one is slightly more than a nit - the paragraph does not parse correctly when it is missing that word.) From rjsparks@nostrum.com Wed Sep 14 08:55:23 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268B521F8B91 for ; Wed, 14 Sep 2011 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dhpx0Hukb3Eq for ; Wed, 14 Sep 2011 08:55:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDFE21F8B64 for ; Wed, 14 Sep 2011 08:55:17 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8EFvJec031974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 10:57:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Wed, 14 Sep 2011 10:57:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1220336F-08F3-4B50-A1A8-5AF28944BF8C@nostrum.com> <8B0A9FCBB9832F43971E38010638454F040D45BACF@SISPE7MB1.commscope.com> To: Robert Sparks X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:55:23 -0000 All -=20 This has been outstanding too long. Based on another review of the = thread, I'm going to put this errata into hold for document update and add a pointer to the thread to = its log. We're capturing the crux in the local-civic document. Any update to 5222 itself should be = done through a draft to be sure we're capturing consensus. RjS On Aug 18, 2011, at 4:48 PM, Robert Sparks wrote: > Ted - with this argument, do you still think the errata is = inappropriate? >=20 > Your suggestion for an example in local-civic is something we could do = anyhow - does anybody think that would be a bad idea? >=20 > RjS >=20 > On Aug 7, 2011, at 7:22 PM, Thomson, Martin wrote: >=20 >> On 2011-08-06 at 07:56:26, Ted Hardie wrote: >>> In the examples used in RFC 5222, there was only one namespace, so=20= >>> there was no need for a disambiguation prefix for the elements. Even=20= >>> in your example, the disambiguation occurs with a prefix only on one=20= >>> of the two namespaces; the erratum appears to suggest it is required=20= >>> even when there is a single namespace. I don't think it is. >>=20 >> The problem isn't that the example is ambiguous to you or I. Machine = interpretation of these elements is unable to make the sorts of = inferences you are describing. >>=20 >> The type of each of these elements is clear: >> qnameList =3D list { xsd:QName* } >>=20 >> Say that I implement this in Java with JAXB. The type of each of = these elements (based on the schema) is = java.util.List. When I go looking to see if = the "A3" element is valid, I would use something like: >>=20 >> List valid =3D locationValidation.getValid(); >> for (QName n : valid) { >> if (n.getNamespaceURI().equals("urn:...:civicAddr") >> && n.getLocalPart().equals("A3")) { >> return true; >> } >> } >> return false; >>=20 >> That wouldn't work with the example as it stands, because the value = that my parser reads is {urn:ietf:params:xml:ns:lost1}:A3. >>=20 >> Another secondary benefit of the schema being as it is: noise is = flagged as being in error. The following would be picked up in parsing = and validation unless the "foo" prefix was bound: >>=20 >> foo:bar >>=20 >> --Martin >> _______________________________________________ >> 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 iesg-secretary@ietf.org Wed Sep 14 13:09:32 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1EA21F8C99; Wed, 14 Sep 2011 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GPx2rYAwDNj; Wed, 14 Sep 2011 13:09:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3721F8CA1; Wed, 14 Sep 2011 13:09:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914200931.15097.3379.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 13:09:31 -0700 Cc: ecrit chair , ecrit mailing list , RFC Editor Subject: [Ecrit] Document Action: 'Framework for Emergency Calling using Internet Multimedia' to Informational RFC (draft-ietf-ecrit-framework-13.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 20:09:32 -0000 The IESG has approved the following document: - 'Framework for Emergency Calling using Internet Multimedia' (draft-ietf-ecrit-framework-13.txt) as an Informational RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-framework/ Technical Summary The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. Working Group Summary This document has had multiple WG reviews from key WG members. This document was vetted via the Emergency Services Workshop at several of it¹s meetings. Organizations participating include: 3GPP, 3GPP2, ETSI EMTEL, NENA, IEEE, EENA, etc. Document Quality While there has been some past controversy around some of the exact wording in this document, there is overall WG consensus that this document - in its present form - should be published. The WG as a whole has been working on the document. Personnel Robert Sparks is the responsible AD. From hannes.tschofenig@gmx.net Sat Sep 17 10:58:46 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7021F8A58 for ; Sat, 17 Sep 2011 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHh3n+uR1ahh for ; Sat, 17 Sep 2011 10:58:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6DAF521F89BA for ; Sat, 17 Sep 2011 10:58:45 -0700 (PDT) Received: (qmail invoked by alias); 17 Sep 2011 18:01:02 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp063) with SMTP; 17 Sep 2011 20:01:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19RAkEtVdJRgoBd21mJrEAz4UcrxXZzU7KWw+YasF ZipDRp4+l9dlBe Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 17 Sep 2011 21:00:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Sparks X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Org , draft-ietf-ecrit-lost-sync@tools.ietf.org Subject: Re: [Ecrit] AD review draft-ietf-ecrit-lost-sync-12 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 17:58:46 -0000 Hi Robert,=20 thank you for your review.=20 On Sep 13, 2011, at 9:22 PM, Robert Sparks wrote: > AD review: draft-ietf-ecrit-lost-sync-12 >=20 > Summary: There are some issues to address before moving this draft=20 > to IETF LC for Experimental. >=20 > 1) The last sentence of 4.1 (the section of sync source behavior) = seems > to talk about sync destination behavior, indicating that an attempt > to delete a non-existent mapping will be silently ignored. That=20 > is contradicted by the procedures specified in section 4.2. > Which was intended? Good catch. I suggest to change the text in Section 4.1=20 FROM: To delete a mapping, the content of the mapping is left empty. The node can delete the mapping from its internal mapping database, but has to remember which peers it has distributed this update to. The 'expires' attribute is required, but ignored. If an attempt is made to delete a non-existent mapping, the request is silently ignored. TO: To delete a mapping, the content of the mapping is left empty, i.e. the = element only contains the 'source', 'sourceID', 'lastUpdated', = and 'expires" attribute. Figure 10 shows an example request where the = mapping with the source=3D"nj.us.example", sourceId=3D"123", = lastUpdated=3D"2008-11-01T01:00:00Z", expires=3D"2008-11-01T01:00:00Z" = is requested to be deleted. Note that the 'expires' attribute is = required per schema definition but will be ignored in processing the = request on the receiving side. A sync source may want to delete the = mapping from its internal mapping database, but has to remember which = peers it has distributed this update to unless it has other ways to = ensure that databases do not get out of sync.=20 >=20 > 2) I don't find the types review requests for application/lostsync+xml > in the archive. If it's been requested, please send me a link. > Otherwise, please request that review now. We may have forgotten to send a request. I will do this right now.=20 >=20 > 3) Does the in the RelaxNG definition > stand alone, or should the document call out what lost.rng is > and how to find it? lost.rng refers to the Relax NG schema from RFC 5222. Of course it does = not say so anywhere in the document.=20 It seems that we had made the mistake already in = http://tools.ietf.org/html/rfc6197 I believe we have two choices here:=20 1) We replace the string "lost.rng" with = http://www.iana.org/assignments/xml-registry/schema/lost1.xsd or 2) We add the following text somewhere:=20 " In order to avoid copying pattern definitions from the LoST Relax NG = schema (RFC 5222) to this document we include it as "lost.rng" (XML syntax), or = "lost.rnc" (compact syntax) in the Relax NG schema defined in this document.=20 " What would you prefer?=20 >=20 > 4) Julian's Sep2010 review asked the working group to consider > using GET for fetches instead of POST. Was there any subsequent > discussion? Hmmm. I believe we missed this remark.=20 FYI: I have no problem using GET but I will ask the group whether there = are any objections about changing it to GET.=20 >=20 > 5) That review also suggested an update for the xmldsig-core > reference that's not reflected here. I could definitely replace the current reference=20 [W3C.REC-xmldsig-core-20020212] Solo, D., Eastlake, D., and J. Reagle, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212. with this one: [W3C.REC-xmldsig-core-20020212] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. = Roessler, "XML-Signature Syntax and Processing", World Wide Web Consortium Second Edition, W3C Recommendation, 10. June 2008, http://www.w3.org/TR/xmldsig-core/. >=20 > 6) Has someone verified the XML for this version of the document? > Julian explicitly noted in his review that he did not verify > the examples. I have asked Andy Newton to do such a review. He did it earlier this = year and spotted a couple of bugs.=20 >=20 > NITS: >=20 > Section 1 Paragraph 4: s/expect for/except for/ >=20 > Section 1 just after figure 5 and figure 6:=20 > s/issuing the first/issues the first/ >=20 > Please expand or provide pointers to the definition for PSAP and ESRP > on first use. >=20 > The examples use domain names (particulary in the "source" attribute > value) that end in lost-example.com. Can you change those to use > lost.example.com to better align with 2606?=20 >=20 > Section 5 2nd paragraph: s/to HTTP-level/to disable HTTP-level/ > (That one is slightly more than a nit - the paragraph does not > parse correctly when it is missing that word.) Will make these changes.=20 Ciao Hannes >=20 From hannes.tschofenig@gmx.net Sat Sep 17 10:58:52 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4052221F8AA9 for ; Sat, 17 Sep 2011 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rlYGonC0aEA for ; Sat, 17 Sep 2011 10:58:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6326521F8A95 for ; Sat, 17 Sep 2011 10:58:51 -0700 (PDT) Received: (qmail invoked by alias); 17 Sep 2011 18:01:07 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp063) with SMTP; 17 Sep 2011 20:01:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/GtDU73oHGBK+LZff9rB4hmX8afoyxVWxmvR4V9x Db2Zc7hQ37kESo From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 17 Sep 2011 21:01:07 +0300 Message-Id: To: ietf-types@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ECRIT Org Subject: [Ecrit] Request for review of Media Type 'application/lostsync+xml' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 17:58:52 -0000 Hi all, draft-ietf-ecrit-lost-sync-12.txt is currently in IESG review. Please review its media type registration for application/lostsync+xml. ------ MIME media type name: application MIME subtype name: lostsync+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2. Security considerations: This content type is designed to carry LoST Syncronization protocol payloads. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] Applications which use this media type: Emergency and Location-based Systems Additional information: Magic Number: None File Extension: .lostsyncxml Macintosh file type code: 'TEXT' Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@nsn.com Intended usage: LIMITED USE Author: This specification is a work item of the IETF ECRIT working group, with mailing list address . Change controller: The IESG 9.2. LoST Sync Relax NG Schema Registration URI: urn:ietf:params:xml:schema:lostsync1 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@gmx.net). Relax NG Schema: The Relax NG schema to be registered is contained in Section 6. ----- Please provide any comments by October 1st. Thanks! Ciao Hannes From Hannes.Tschofenig@gmx.net Sun Sep 18 09:29:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F021F8508 for ; Sun, 18 Sep 2011 09:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8j8BMWrH3Sm for ; Sun, 18 Sep 2011 09:29:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3FB8121F84FD for ; Sun, 18 Sep 2011 09:29:49 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2011 16:32:08 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp069) with SMTP; 18 Sep 2011 18:32:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/AUisVh47ACjH3ttRji/XyWUpCu0XSCwzZKBJSV0 2PPwqMjNF2WBXS From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Sep 2011 19:32:07 +0300 Message-Id: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Scope of the Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 16:29:50 -0000 Hi all,=20 in earlier discussions we had always listed the school shooting scenario = as a use case to summarize a cluster of solutions that use existing = protocols, such as XMPP or SIP, to convey the alerts in a point-to-point = fashion (using a subscribe/notify paradigm).=20 A few of us had worked on these solutions, such as = http://xmpp.org/extensions/xep-0127.html or = http://tools.ietf.org/html/draft-rosen-sipping-cap-04. These writeups = should give you more background about the characteristics of the = provided solution (in case the scenario description isn't so good). These solutions are not suitable for mass delivery (aka Tsunami warning = case) but work fine in various other use cases. I had a short writeup of = the scenario in the architecture mail I distributed yesterday.=20 Now, in off-list discussions for the virtual interim meeting the = question was raised whether this use case is something that should not = be dealt with in the group but instead the focus be spent on the mass = delivery. =46rom a requirements point of view these two cases are = obviously quite different and the mass delivery case would make use of = multicast/broadcast delivery instead.=20 I would need feedback from the rest of the group. There are two choices, = I believe: 1) Focus on the mass alert delivery work,=20 2) In addition to the mass delivery work also address the school = shooting scenario (based on how I described it in my architectural = writeup, see = http://www.ietf.org/mail-archive/web/atoca/current/msg00536.html, that = would lead to a point-to-point alert delivery. =20 What would you prefer?=20 Ciao Hannes From Martin.Thomson@commscope.com Sun Sep 18 16:53:57 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00F21F8B59 for ; Sun, 18 Sep 2011 16:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xs1YoeLs+1b for ; Sun, 18 Sep 2011 16:53:56 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D221F8B57 for ; Sun, 18 Sep 2011 16:53:56 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-6a-4e7685213fec Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id EB.A4.19263.125867E4; Sun, 18 Sep 2011 18:56:17 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 18 Sep 2011 18:56:17 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 19 Sep 2011 07:56:13 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , ECRIT Org Date: Mon, 19 Sep 2011 07:56:12 +0800 Thread-Topic: [Ecrit] Scope of the Work Thread-Index: Acx2IJfvP1DLZQtxQpCVE1nUwiTsZgAPb5IQ Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C507@SISPE7MB1.commscope.com> References: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> In-Reply-To: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Scope of the Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 23:53:57 -0000 This is a good question. Sent to the wrong WG :) If anyone has any thoughts on this topic, I'd be interested to hear them. On 2011-09-19 at 02:32:07, Hannes Tschofenig wrote: > Hi all, >=20 > in earlier discussions we had always listed the school shooting=20 > scenario as a use case to summarize a cluster of solutions that use=20 > existing protocols, such as XMPP or SIP, to convey the alerts in a=20 > point-to-point fashion (using a subscribe/notify paradigm). > A few of us had worked on these solutions, such as=20 > http://xmpp.org/extensions/xep-0127.html or=20 > http://tools.ietf.org/html/draft-rosen-sipping-cap-04. These writeups=20 > should give you more background about the characteristics of the=20 > provided solution (in case the scenario description isn't so good). >=20 > These solutions are not suitable for mass delivery (aka Tsunami=20 > warning > case) but work fine in various other use cases. I had a short writeup=20 > of the scenario in the architecture mail I distributed yesterday. >=20 > Now, in off-list discussions for the virtual interim meeting the=20 > question was raised whether this use case is something that should not=20 > be dealt with in the group but instead the focus be spent on the mass=20 > delivery. From a requirements point of view these two cases are=20 > obviously quite different and the mass delivery case would make use of=20 > multicast/broadcast delivery instead. >=20 > I would need feedback from the rest of the group. There are two=20 > choices, I believe: >=20 > 1) Focus on the mass alert delivery work, >=20 > 2) In addition to the mass delivery work also address the school=20 > shooting scenario (based on how I described it in my architectural=20 > writeup, see http://www.ietf.org/mail-=20 > archive/web/atoca/current/msg00536.html, that would lead to a=20 > point-to- point alert delivery. >=20 > What would you prefer? >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ted.ietf@gmail.com Tue Sep 27 11:32:26 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6EF21F8C15 for ; Tue, 27 Sep 2011 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC3q0GGBGx-i for ; Tue, 27 Sep 2011 11:32:26 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E374921F8C00 for ; Tue, 27 Sep 2011 11:32:25 -0700 (PDT) Received: by ywa6 with SMTP id 6so6993690ywa.31 for ; Tue, 27 Sep 2011 11:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=soGvu/XYSNkqSxbKBIhXd14LtUm0Uad88OAoyGRzRZ4=; b=FekJBc0u1IIxtSWdbcn64vEvqKwemXoZZwry5qahSVXczKIW3m7hcHBRXNq0Y1EA33 17krzquI9Xpg+aaBp4xg2kq/FXbM7j1d+VLnb0SDSIMDH4HeWCpse5iBmiyfKdCwJbae eX1pXRuma0y4hj+lcp88/HDMGjcOHedf7mnqQ= MIME-Version: 1.0 Received: by 10.236.127.144 with SMTP id d16mr15971014yhi.40.1317148511992; Tue, 27 Sep 2011 11:35:11 -0700 (PDT) Received: by 10.236.108.35 with HTTP; Tue, 27 Sep 2011 11:35:11 -0700 (PDT) Date: Tue, 27 Sep 2011 11:35:11 -0700 Message-ID: From: Ted Hardie To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=20cf3010e3c52c7a2804adf089c8 Subject: [Ecrit] ED-77 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 18:32:26 -0000 --20cf3010e3c52c7a2804adf089c8 Content-Type: text/plain; charset=ISO-8859-1 Bernard Aboba recently pointed ED-77 out to the RTCWEB working group, which caused me to go back and look at it. It does not seem to specify a particular profile of H.264. For interoperability purposes, should it? Ted --20cf3010e3c52c7a2804adf089c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bernard Aboba recently pointed ED-77 out to the RTCWEB working group, which= caused me to go back and look at it.=A0 It does not seem to specify a part= icular profile of H.264.=A0 For interoperability purposes, should it?
Ted
--20cf3010e3c52c7a2804adf089c8--