From martin.thomson@gmail.com Tue Sep 4 13:54:23 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9B911E80A6 for ; Tue, 4 Sep 2012 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uugBd5cIfwOf for ; Tue, 4 Sep 2012 13:54:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9B11E80A4 for ; Tue, 4 Sep 2012 13:54:22 -0700 (PDT) Received: by lbky2 with SMTP id y2so4298939lbk.31 for ; Tue, 04 Sep 2012 13:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jcyuAM5yPgwehMcsV6mU9yl/VMA5SAFU/YaoGCgtRLc=; b=AZSgSyV0hHizo70hbLC9CEkDC6tPUqkxrUbrlLA9I7IwoftyAcBx650rlQc9YC33xI zVAVLs4FnScERf19cmu8tNWFAPGHlMtq+fbgTILdXhbo5T+6v9GxFXMjwhVtslVEZPjF YWhPbLUomYmKr8cCJxt4wpZscau2EuONwZ2Nl6OUXvS2MqVqoDEai/mydsdrhoucryTW yufgcgo+fuR4yf1WNhp3AAx9QpKoLtO17WF4vD5RP8uvW/iI93hZ5z3iv8ABkv6cKo5H ocS8dPsZIKoabHe1WBuCjsUBHQTNERZkAWjOmVohmUMPawa6fOcJ9Fn/7WRtbRHDrgyI G0+Q== MIME-Version: 1.0 Received: by 10.152.123.140 with SMTP id ma12mr18156874lab.22.1346792061025; Tue, 04 Sep 2012 13:54:21 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Tue, 4 Sep 2012 13:54:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 13:54:20 -0700 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [atoca] Call for submissions: Secure Alert Format X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 20:54:23 -0000 With a little over a week to go, we have so far received the following input: Remember, more time under the noses of your colleagues improves our chances of meeting the next deadline. On 17 August 2012 11:34, Martin Thomson wrote: > The ATOCA WG needs you. > > It has been determined that providing a means of authenticating alerts > is critical to the working group. > > Please submit internet drafts containing proposals that address this > problem before September 12. > > Such a proposal must be able to carry CAP-formatted alerts in such a > way that the source(s) of the alert can be authenticated by > recipients. Attributing trust to that source is not necessarily > within scope, nor is it necessary to describe a protocol or delivery > architecture. > > A submission made earlier than this date will give us more time to > discuss it. That is good if we are to meet our later milestones for > adoption and publication. From rbarnes@bbn.com Tue Sep 4 14:53:29 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBB421E808A for ; Tue, 4 Sep 2012 14:53:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65JEaxCv7BHz for ; Tue, 4 Sep 2012 14:53:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2121E805A for ; Tue, 4 Sep 2012 14:53:28 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:59693) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T913h-0005d3-Vy; Tue, 04 Sep 2012 17:53:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Tue, 4 Sep 2012 17:53:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49ABCA4C-315E-495E-9E62-08D6BEE4ECC4@bbn.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] Call for submissions: Secure Alert Format X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:53:29 -0000 Maybe you need a new mail client? Mine shows several messages in this = thread. On Sep 4, 2012, at 4:54 PM, Martin Thomson wrote: > With a little over a week to go, we have so far received the following = input: >=20 >=20 > Remember, more time under the noses of your colleagues improves our > chances of meeting the next deadline. >=20 > On 17 August 2012 11:34, Martin Thomson = wrote: >> The ATOCA WG needs you. >>=20 >> It has been determined that providing a means of authenticating = alerts >> is critical to the working group. >>=20 >> Please submit internet drafts containing proposals that address this >> problem before September 12. >>=20 >> Such a proposal must be able to carry CAP-formatted alerts in such a >> way that the source(s) of the alert can be authenticated by >> recipients. Attributing trust to that source is not necessarily >> within scope, nor is it necessary to describe a protocol or delivery >> architecture. >>=20 >> A submission made earlier than this date will give us more time to >> discuss it. That is good if we are to meet our later milestones for >> adoption and publication. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From martin.thomson@gmail.com Tue Sep 4 15:13:20 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC0421E80A7 for ; Tue, 4 Sep 2012 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSRXIPE145IB for ; Tue, 4 Sep 2012 15:13:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8551821F84B9 for ; Tue, 4 Sep 2012 15:13:19 -0700 (PDT) Received: by lbky2 with SMTP id y2so4345535lbk.31 for ; Tue, 04 Sep 2012 15:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vm5KjZBm88bjwoDkYFMSh95gd6tgiQvKhODJvWD9/mc=; b=iJFra1r4+9hMFlpoqLarps1XM+LYZUGivsNTFtrsUQqNSohk3TAVEVhmhx+Yf6CnQo sPdF64cLJDjCaAm2N/vHSwajo7bihh7rLhG9uKEHIySlAmzr7mj9QN2OJgkgx/ku0ybR fykHJBiRH4ZRSRJ27zm47+bnl76zgK/Zemeum7RTnPP8y4vDdf/5w4kn1LryozcAFT8Y QY0jtxt1e1Bxw1Yn6itVkeTirYeK5OtJaZqH7ioHJc5XE3+6TcMv2IUtaursZmF2lK9X VezSSbwLlCjSfoITzV2AIhg4hfnWFjOuUhChCH/gzb0N4ZsDJCVwQAnIMkJNJ+WALXYD nJzg== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr18484951lab.2.1346796798514; Tue, 04 Sep 2012 15:13:18 -0700 (PDT) Received: by 10.112.41.193 with HTTP; Tue, 4 Sep 2012 15:13:18 -0700 (PDT) In-Reply-To: <49ABCA4C-315E-495E-9E62-08D6BEE4ECC4@bbn.com> References: <49ABCA4C-315E-495E-9E62-08D6BEE4ECC4@bbn.com> Date: Tue, 4 Sep 2012 15:13:18 -0700 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: atoca@ietf.org Subject: Re: [atoca] Call for submissions: Secure Alert Format X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:13:20 -0000 My apologies, I saw the discussion, but no references to active internet drafts. If you or Matt feel that draft-barnes-atoca-escape is appropriate, then a -01 draft should easily rectify this deficiency. I had assumed that you would be doing this, but had perhaps considered making a few changes prior to doing so. On 4 September 2012 14:53, Richard Barnes wrote: > Maybe you need a new mail client? Mine shows several messages in this thread. > > > On Sep 4, 2012, at 4:54 PM, Martin Thomson wrote: > >> With a little over a week to go, we have so far received the following input: >> >> >> Remember, more time under the noses of your colleagues improves our >> chances of meeting the next deadline. >> >> On 17 August 2012 11:34, Martin Thomson wrote: >>> The ATOCA WG needs you. >>> >>> It has been determined that providing a means of authenticating alerts >>> is critical to the working group. >>> >>> Please submit internet drafts containing proposals that address this >>> problem before September 12. >>> >>> Such a proposal must be able to carry CAP-formatted alerts in such a >>> way that the source(s) of the alert can be authenticated by >>> recipients. Attributing trust to that source is not necessarily >>> within scope, nor is it necessary to describe a protocol or delivery >>> architecture. >>> >>> A submission made earlier than this date will give us more time to >>> discuss it. That is good if we are to meet our later milestones for >>> adoption and publication. >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > From rbarnes@bbn.com Mon Sep 10 20:43:23 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7821F875B for ; Mon, 10 Sep 2012 20:43:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAhsQLhpNYle for ; Mon, 10 Sep 2012 20:43:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D783F21F875A for ; Mon, 10 Sep 2012 20:43:22 -0700 (PDT) Received: from [128.89.255.41] (port=56562) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBHNi-0009dG-2J for atoca@ietf.org; Mon, 10 Sep 2012 23:43:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Richard Barnes In-Reply-To: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 23:43:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 03:43:23 -0000 Dear ATOCA, In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). =20 The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). Comments very welcome. There's even a list of open questions at the = front! Thanks a lot, --Richard On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-barnes-atoca-escape-01.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. >=20 > Filename: draft-barnes-atoca-escape > Revision: 01 > Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) > Creation date: 2012-09-11 > WG ID: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt > Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape > Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >=20 > Abstract: > Recipients of emergency alerts need to be able to verify that an > alert they receive was issued by an authorized source. The Common > Alerting Protocol (CAP) provides a standard way of encoding alert > information, but does not provide any security features that would > support authentication of alert originators. This document = describes > a security wrapper for Common Alerting Protocol objects to allow > alerts to be signed by alert originators. >=20 > Please send feedback to the atoca@ietf.org mailing list. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From artbotterell@gmail.com Mon Sep 10 22:20:20 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1221F861D for ; Mon, 10 Sep 2012 22:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RriUtvJfgYwR for ; Mon, 10 Sep 2012 22:20:19 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6966A21F8619 for ; Mon, 10 Sep 2012 22:20:19 -0700 (PDT) Received: by ieak13 with SMTP id k13so250950iea.31 for ; Mon, 10 Sep 2012 22:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=bgBcpchZdbNv6t/7rfT2wFHeG8WyW3NqXFyNB9P2u1w=; b=N3SRDwrvQ92omxoj9KIo50kR0jPbBHBFZztfPLZtMCvwItljGjRiuuoXRW2AGtPfxy 2gw4GZ3sBUAcL8sK6m6IDG4qJiSjCPhIQxiJNNRpfrDtY7D9MXqiosmuQluHlgyz7h3x WKAZVgdjvLHoyQjdwIRLxNbeeaYtRqQz9abmP1e/iaqYsubfUmQW7X6stdikTe/MfEes pAQFUE2AcVP+xrkDFYiFe5YpnJcXIihr9PJAwsyTxbaqQZ+Ay2ncjMzd4id+khgQwjpY tnXp81+D1KhX5wpu7x6ZkveHd3wHZCNqjGC9yqTgZpOO/YcnCZksxwUwbNAcI0Bj1Irx XiRQ== Received: by 10.50.213.6 with SMTP id no6mr13737861igc.30.1347340818878; Mon, 10 Sep 2012 22:20:18 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id wm7sm1172751igb.6.2012.09.10.22.20.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 22:20:18 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Art Botterell In-Reply-To: <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> Date: Mon, 10 Sep 2012 22:20:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 05:20:20 -0000 Hi Richard - I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." =20 Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . =20 Indeed, XMLSIG has been a feature of every CAP version since 1.0. And = if that's not enough, there's also the existing OASIS EDXL-DE wrapper = specification. So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? - Art On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: > Dear ATOCA, >=20 > In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). =20 >=20 > The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >=20 > Comments very welcome. There's even a list of open questions at the = front! >=20 > Thanks a lot, > --Richard >=20 >=20 >=20 > On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A new version of I-D, draft-barnes-atoca-escape-01.txt >> has been successfully submitted by Richard Barnes and posted to the >> IETF repository. >>=20 >> Filename: draft-barnes-atoca-escape >> Revision: 01 >> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >> Creation date: 2012-09-11 >> WG ID: Individual Submission >> Number of pages: 17 >> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>=20 >> Abstract: >> Recipients of emergency alerts need to be able to verify that an >> alert they receive was issued by an authorized source. The Common >> Alerting Protocol (CAP) provides a standard way of encoding alert >> information, but does not provide any security features that would >> support authentication of alert originators. This document = describes >> a security wrapper for Common Alerting Protocol objects to allow >> alerts to be signed by alert originators. >>=20 >> Please send feedback to the atoca@ietf.org mailing list. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From martin.thomson@gmail.com Tue Sep 11 10:01:44 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D938721F87BF for ; Tue, 11 Sep 2012 10:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz1oItk73RRC for ; Tue, 11 Sep 2012 10:01:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E221F876E for ; Tue, 11 Sep 2012 10:01:43 -0700 (PDT) Received: by lahm15 with SMTP id m15so539595lah.31 for ; Tue, 11 Sep 2012 10:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ixC6GEB7wYyXaMZa4crjrDHkxqtclH7cdW9JVOmNxSM=; b=snashbPRrbpBvtYMc1M/90eENCtvCm7dhQe0F8yo+ZEcVuKV9Ce6j8AFMPttXuIS9x selnYY6pXKt4x6GFB8tqAwVOJW2jNy4fijFWBydCDdeX3duiYZcor9QNZsF1zLbW88Ew 7zH3kG+Q/1bi17ieLdwAY53T/DVwsdCyKgwv+eYV+Db41ycJBvwt+CO9163/W4BgJz7w kO3qruhQ4p2T/gT9Zam+ScRAtuk6l8wfYq5rpVbo8vhAepnUeCFWJo/p7OnJno9lxzFM rVshgq0BiR2EPnqbrNvHJDsj+NIw7IM9d+Qc5aVvMAQkewnh6VrKfCEKsb9xpRVxRqpK 0rDQ== MIME-Version: 1.0 Received: by 10.112.41.161 with SMTP id g1mr6361517lbl.59.1347382902381; Tue, 11 Sep 2012 10:01:42 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Tue, 11 Sep 2012 10:01:42 -0700 (PDT) In-Reply-To: <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> Date: Tue, 11 Sep 2012 10:01:42 -0700 Message-ID: From: Martin Thomson To: Art Botterell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:01:45 -0000 Art, It is generally accepted wisdom (in the IETF at least) that XML DSig [RFC3275] is a recipe for interoperability failure. The primary reason for this is the dependency on XML canonicalization. I'd be interested in hearing a different perspective. I've used the apache library to implement an enveloped signature and it wasn't straightforward. I'm not aware of any other implementation, but it's been a few years since I last looked. Of course, it's a different thing to say the mechanism is broken or unusable rather than "there is no mechanism". The former statement requires greater justification. I'll let Richard explain the token mechanism. It's an optimization. --Martin On 10 September 2012 22:20, Art Botterell wrote: > Hi Richard - > > I'm confused by the claim that CAP "does not provide any security feature= s that would support authentication of alert originators." > > Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The elem= ent of a CAP Alert Message MAY have an Enveloped Signature, as described by= XML-Signature and Syntax Processing," and makes reference to both and . > > Indeed, XMLSIG has been a feature of every CAP version since 1.0. And if= that's not enough, there's also the existing OASIS EDXL-DE wrapper specifi= cation. > > So while I'm a huge supporter of an end-to-end approach to CAP authentica= tion, on the face of it the ESCAPE draft seems duplicative and somewhat ill= -informed. Also I fear I'm missing the point of the added "alert token" me= chanism, other than to add one more maintenance task that nobody is going t= o want to own. > > But possibly you've just leapt ahead too far for me to follow in a single= bound. What am I missing here? > > - Art > > > On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: > >> Dear ATOCA, >> >> In order to respond to the chairs' call for candidate alert format docum= ents, we have put together a revision of draft-barnes-atoca-escape. As you= may recall from earlier versions, ESCAPE uses S/MIME to wrap a CAP documen= t, in order to add authentication for alert originators (digital signature = and "alert token"). >> >> The changes from -00 are largely to add more explanatory text, and clari= fy a few things technically. We haven't translated the whole thing to JOSE = (yet). Mostly, our hope is that in reading the new version, you'll be able= to envision how these secure alerts can be used to build an overall alerti= ng system. For example, they highlight some of the things that a discover = / metadata protocol might need to provide (e.g., public keys for authoritie= s). >> >> Comments very welcome. There's even a list of open questions at the fro= nt! >> >> Thanks a lot, >> --Richard >> >> >> >> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >> >>> >>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>> has been successfully submitted by Richard Barnes and posted to the >>> IETF repository. >>> >>> Filename: draft-barnes-atoca-escape >>> Revision: 01 >>> Title: Encoding of Secure Common Alert Protocol Entities= (ESCAPE) >>> Creation date: 2012-09-11 >>> WG ID: Individual Submission >>> Number of pages: 17 >>> URL: http://www.ietf.org/internet-drafts/draft-barnes-atoca= -escape-01.txt >>> Status: http://datatracker.ietf.org/doc/draft-barnes-atoca-esc= ape >>> Htmlized: http://tools.ietf.org/html/draft-barnes-atoca-escape-0= 1 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-= escape-01 >>> >>> Abstract: >>> Recipients of emergency alerts need to be able to verify that an >>> alert they receive was issued by an authorized source. The Common >>> Alerting Protocol (CAP) provides a standard way of encoding alert >>> information, but does not provide any security features that would >>> support authentication of alert originators. This document describes >>> a security wrapper for Common Alerting Protocol objects to allow >>> alerts to be signed by alert originators. >>> >>> Please send feedback to the atoca@ietf.org mailing list. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Tue Sep 11 11:12:37 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0A21F85B4 for ; Tue, 11 Sep 2012 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWWQH9Xftfhd for ; Tue, 11 Sep 2012 11:12:35 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4459A21F84B5 for ; Tue, 11 Sep 2012 11:12:29 -0700 (PDT) X-ASG-Debug-ID: 1347387121-0491e5109e167cf0001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id et3PkxM6cBoA8G2S; Tue, 11 Sep 2012 11:12:01 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:58652 helo=[192.168.133.177]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TBUwL-001Bgx-Ts; Tue, 11 Sep 2012 11:12:02 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen X-ASG-Orig-Subj: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt In-Reply-To: <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> Date: Tue, 11 Sep 2012 14:11:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1486) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1347387121 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.108251 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:12:37 -0000 I have reviewed this draft and have the following comments: Overall, I think this is a helpful part in solving a large problem. I = do look forward to hearing any fallout from the discussion Art started = on XML DSig, as I was unaware that there were interoperability issues = with it. The mechanism of using S/MIME, and the text describing how it is used = seems clear to me. I'm a fan of re-use, and despite the lack of support = for S/MIME in some protocols that specified its use, I think here it is = used appropriately and intelligently to produce an interoperable way. I = will have to go look at RFC5751to make sure we don't have any possible = holes on preparing the CAP message for this process. I get worried = about trivial things like whether there must be a trailing line end at = the end of the CAP message or not. I am less enthused about the token mechanism. There are a couple of = reasons I think we need more discussion. Let me say up front that the = notion of having a trivial reject mechanism that avoids a DDoS by crypto = of bad messages is a good one, so I'm more interested in finding = solutions that allow us to have something like this token than in = dropping it. Forcing the alert sender to be the token inserter means there is no = opportunity to have any form of transitive trust on message originators. = Using the example in the draft, a recipient would need a token list = from what I expect would be a dozen U.S. federal agencies to cover what = we would generically describe as a "national alert". There is no way to = have a single "U.S. Government aggregator" that could avoid this. The token hashes have to be securely delivered to each endpoint by each = originator. This seems to me to be pretty onerous. Clearly every = endpoint has the same list of token hashes, which makes this tractable, = but it does seem like a lot of mechanism will be needed to deploy. This seems like a problem that has been solved. What this feels like is = a one time password, where the encrypt key and the decrypt keys are = different. Rather than a hash, can we really just securely pass the = decrypt keys around? Still need a hash for message integrity, but=85 = Maybe I'm dreaming. I don't understand the notion (in 3.4) of allowing tokens with no = signatures. =20 I don't understand the notion (in 4.1) of a list of tokens. At first, I = thought that you start with a list, but choose one. Alas, it says = create a header for each of the tokens in the list. What is that doing? If you allow an intermediary to sign, wouldn't you want to include a = token? Would we not get back to the problem the token solves without = that? But, really, why would an intermediary sign? What would that get = us? In the past, when we have talked about intermediaries signing, it = was part of a transitive trust model. The tokens break that model. So, = if we have tokens, what is an intermediary signature used for? Finally, I was reminded, looking at the example, why we need an area = affected mechanism in some form of wrapper -- the CAP one is not = processable by automatons and we need to have successive filtering on = area affected to make the distribution mechanisms work. That got me = thinking of whether that, and possibly also other wrapper data needed to = be protected, and thus how would it affect this mechanism. Brian On Sep 10, 2012, at 11:43 PM, Richard Barnes wrote: > Dear ATOCA, >=20 > In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). =20 >=20 > The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >=20 > Comments very welcome. There's even a list of open questions at the = front! >=20 > Thanks a lot, > --Richard >=20 >=20 >=20 > On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A new version of I-D, draft-barnes-atoca-escape-01.txt >> has been successfully submitted by Richard Barnes and posted to the >> IETF repository. >>=20 >> Filename: draft-barnes-atoca-escape >> Revision: 01 >> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >> Creation date: 2012-09-11 >> WG ID: Individual Submission >> Number of pages: 17 >> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>=20 >> Abstract: >> Recipients of emergency alerts need to be able to verify that an >> alert they receive was issued by an authorized source. The Common >> Alerting Protocol (CAP) provides a standard way of encoding alert >> information, but does not provide any security features that would >> support authentication of alert originators. This document = describes >> a security wrapper for Common Alerting Protocol objects to allow >> alerts to be signed by alert originators. >>=20 >> Please send feedback to the atoca@ietf.org mailing list. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 11 12:36:18 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D0921F8673 for ; Tue, 11 Sep 2012 12:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu8LPwpI8WWu for ; Tue, 11 Sep 2012 12:36:17 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01E7921F865B for ; Tue, 11 Sep 2012 12:36:16 -0700 (PDT) Received: by dadf8 with SMTP id f8so519320dad.31 for ; Tue, 11 Sep 2012 12:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gz3MWCFDTL0cJ31j4sLbiOzLMZ0zC0bzZkqAU/zfssc=; b=NeeS34zEeYVmI0IAnaPm4JdlHCr9S1RlbXUY7Fmvpwqc9hNOc8lTrIPVuLq8Jh0qsc 8d/OPJ13M1LnHx/uGqEyS1ME/jS+PzWQ59qBigKtEjxQ7iy1yUCZOIW/eK1u3OMvve2w l0cBuVbz+RIn4Osf2Z8Z87CIuoz0QCqDuTnT9WQxiGeMAlWPwFOSwr3aoUyMbWhZhiy4 g3vGLOnfx0LIGjb4WouRmNhZSMj5mvWhedOGSiB4DlxrVqc1VEllu5S64n7c7kcnQ2A8 hBZxVXBF5AJNUtMKf2XAuS7TbQjLriHa8WmIHUH/FbxC7B03yjGOl7LbAanH6VY1kpGV ZHaQ== Received: by 10.68.228.98 with SMTP id sh2mr12496788pbc.95.1347392174491; Tue, 11 Sep 2012 12:36:14 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id uh7sm10203897pbc.35.2012.09.11.12.36.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 12:36:13 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: Date: Tue, 11 Sep 2012 12:36:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> To: Martin Thomson X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:36:18 -0000 Hi Martin - Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. - Art On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: > Art, >=20 > It is generally accepted wisdom (in the IETF at least) that XML DSig > [RFC3275] is a recipe for interoperability failure. The primary > reason for this is the dependency on XML canonicalization. >=20 > I'd be interested in hearing a different perspective. I've used the > apache library to implement an enveloped signature and it wasn't > straightforward. I'm not aware of any other implementation, but it's > been a few years since I last looked. >=20 > Of course, it's a different thing to say the mechanism is broken or > unusable rather than "there is no mechanism". The former statement > requires greater justification. >=20 > I'll let Richard explain the token mechanism. It's an optimization. >=20 > --Martin >=20 > On 10 September 2012 22:20, Art Botterell wrote: >> Hi Richard - >>=20 >> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>=20 >> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . >>=20 >> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>=20 >> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>=20 >> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>=20 >> - Art >>=20 >>=20 >> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>=20 >>> Dear ATOCA, >>>=20 >>> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). >>>=20 >>> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>>=20 >>> Comments very welcome. There's even a list of open questions at the = front! >>>=20 >>> Thanks a lot, >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>> has been successfully submitted by Richard Barnes and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-barnes-atoca-escape >>>> Revision: 01 >>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>> Creation date: 2012-09-11 >>>> WG ID: Individual Submission >>>> Number of pages: 17 >>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>=20 >>>> Abstract: >>>> Recipients of emergency alerts need to be able to verify that an >>>> alert they receive was issued by an authorized source. The Common >>>> Alerting Protocol (CAP) provides a standard way of encoding alert >>>> information, but does not provide any security features that would >>>> support authentication of alert originators. This document = describes >>>> a security wrapper for Common Alerting Protocol objects to allow >>>> alerts to be signed by alert originators. >>>>=20 >>>> Please send feedback to the atoca@ietf.org mailing list. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Tue Sep 11 13:22:28 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22721F84E2 for ; Tue, 11 Sep 2012 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD7vh7+1V3Iv for ; Tue, 11 Sep 2012 13:22:27 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id E3ADC21F846D for ; Tue, 11 Sep 2012 13:22:26 -0700 (PDT) X-ASG-Debug-ID: 1347394945-0538de10339fb3b0001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id KKBemuB4vMjIVhnD; Tue, 11 Sep 2012 13:22:25 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:23709 helo=[192.168.133.189]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TBWyX-001PSx-Cj; Tue, 11 Sep 2012 13:22:25 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen X-ASG-Orig-Subj: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt In-Reply-To: <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> Date: Tue, 11 Sep 2012 16:22:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1347394945 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.108258 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:22:28 -0000 Art I think I can explain it. Verifying a digital signature that uses public key crypto is expensive. = A convenient DoS attack on a client would be to forge a set of alerts = that are just nonsense, but appear to be valid. The client has to check = the signature to discover that it's bad, using lots of cycles to do = that. The token provides a short cut to checking the signature that uses far = fewer cycles. Both ends have the token hash. The sender includes the = token value, which prior to sending it, was known only to the sender. = The recipient runs the hash algorithm on the value to see if it matches = one of the hashes it knows. The tokens are one time use, so a replay is = not possible. The token scheme is not foolproof because an attacker might be able to = forge a token value that matches the hash (it could know all the hashes, = since it might be a recipient too). Thus, you use the hash test to do = trivial discard, and then if you have something that the token check = says is valid, then you do the real public key signature check to make = sure it's valid. Brian On Sep 11, 2012, at 3:36 PM, Art Botterell wrote: > Hi Martin - >=20 > Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >=20 > I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >=20 > And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >=20 > - Art >=20 >=20 > On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >=20 >> Art, >>=20 >> It is generally accepted wisdom (in the IETF at least) that XML DSig >> [RFC3275] is a recipe for interoperability failure. The primary >> reason for this is the dependency on XML canonicalization. >>=20 >> I'd be interested in hearing a different perspective. I've used the >> apache library to implement an enveloped signature and it wasn't >> straightforward. I'm not aware of any other implementation, but it's >> been a few years since I last looked. >>=20 >> Of course, it's a different thing to say the mechanism is broken or >> unusable rather than "there is no mechanism". The former statement >> requires greater justification. >>=20 >> I'll let Richard explain the token mechanism. It's an optimization. >>=20 >> --Martin >>=20 >> On 10 September 2012 22:20, Art Botterell wrote: >>> Hi Richard - >>>=20 >>> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>>=20 >>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . >>>=20 >>> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>=20 >>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>=20 >>> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>>=20 >>> - Art >>>=20 >>>=20 >>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>=20 >>>> Dear ATOCA, >>>>=20 >>>> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). >>>>=20 >>>> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>>>=20 >>>> Comments very welcome. There's even a list of open questions at = the front! >>>>=20 >>>> Thanks a lot, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>> has been successfully submitted by Richard Barnes and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-barnes-atoca-escape >>>>> Revision: 01 >>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 17 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>=20 >>>>> Abstract: >>>>> Recipients of emergency alerts need to be able to verify that an >>>>> alert they receive was issued by an authorized source. The Common >>>>> Alerting Protocol (CAP) provides a standard way of encoding alert >>>>> information, but does not provide any security features that would >>>>> support authentication of alert originators. This document = describes >>>>> a security wrapper for Common Alerting Protocol objects to allow >>>>> alerts to be signed by alert originators. >>>>>=20 >>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 11 13:42:48 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8EA21F8484 for ; Tue, 11 Sep 2012 13:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGeEHt3+OZM3 for ; Tue, 11 Sep 2012 13:42:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE5E521F848F for ; Tue, 11 Sep 2012 13:42:46 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1328084pbb.31 for ; Tue, 11 Sep 2012 13:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=CmUOVTSUAO0VRqDAU+dYP2sYkjIu5C7oYVSqjD2fY3k=; b=dwpKWmfzsG/MCTl2WQLaFfJ4i0QZxmUMIzNKlTnwzqqFcD1B9ZlubhpDqaRUpye9lM qoYuc4Q7rOJnQ4U9qEcZc848TV94YgQzk5ZlkEVaK9jiIINaenpYfQKQ02Ej7Kh7Rwtl OVJSFt7Xqft727SJum1uXBZZNAWFMF3ko9Ghwe3FzMv3b/Sg4pPFSzuXrSA1p/w5QztL PPJPF4/i/f7os8aG6zdyNPEz0s9b1l70OOqgzdBDgyaGf6ESklit6+zljxMG/cv1f68u PgR/SuCUD4fd8yJAx0AIX4Dr1u06Zp4BLlOQ8w6VolKbu9XXkjte9hK+AS7hjyxE9ACW e9Gw== Received: by 10.68.228.100 with SMTP id sh4mr12713994pbc.45.1347396166475; Tue, 11 Sep 2012 13:42:46 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id gh7sm10288804pbc.29.2012.09.11.13.42.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 13:42:45 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Art Botterell In-Reply-To: Date: Tue, 11 Sep 2012 13:42:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:42:48 -0000 Thanks, Brian, that's helpful. Sounds like it might require a bit of = infrastructure to pre-distribute the hashes... is this actually the most = efficient way to defend against DDoS attacks involving digital = signatures? If so, I'm thinking CAP alerts might not be the most likely or even the = most critical place where this mechanism might be needed. Isn't this a = general vulnerability of any system that uses signatures? =20 If so, might a defensive mechanism be worth developing on its own, as an = extension or adjunct to RFC3275, rather than associating it narrowly = with a particular application? - Art On Sep 11, 2012, at 1:22 PM, Brian Rosen wrote: > Art >=20 > I think I can explain it. >=20 > Verifying a digital signature that uses public key crypto is = expensive. A convenient DoS attack on a client would be to forge a set = of alerts that are just nonsense, but appear to be valid. The client = has to check the signature to discover that it's bad, using lots of = cycles to do that. >=20 > The token provides a short cut to checking the signature that uses far = fewer cycles. Both ends have the token hash. The sender includes the = token value, which prior to sending it, was known only to the sender. = The recipient runs the hash algorithm on the value to see if it matches = one of the hashes it knows. The tokens are one time use, so a replay is = not possible. >=20 > The token scheme is not foolproof because an attacker might be able to = forge a token value that matches the hash (it could know all the hashes, = since it might be a recipient too). Thus, you use the hash test to do = trivial discard, and then if you have something that the token check = says is valid, then you do the real public key signature check to make = sure it's valid. >=20 > Brian >=20 > On Sep 11, 2012, at 3:36 PM, Art Botterell wrote: >=20 >> Hi Martin - >>=20 >> Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >>=20 >> I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >>=20 >> And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >>=20 >> - Art >>=20 >>=20 >> On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >>=20 >>> Art, >>>=20 >>> It is generally accepted wisdom (in the IETF at least) that XML DSig >>> [RFC3275] is a recipe for interoperability failure. The primary >>> reason for this is the dependency on XML canonicalization. >>>=20 >>> I'd be interested in hearing a different perspective. I've used the >>> apache library to implement an enveloped signature and it wasn't >>> straightforward. I'm not aware of any other implementation, but = it's >>> been a few years since I last looked. >>>=20 >>> Of course, it's a different thing to say the mechanism is broken or >>> unusable rather than "there is no mechanism". The former statement >>> requires greater justification. >>>=20 >>> I'll let Richard explain the token mechanism. It's an optimization. >>>=20 >>> --Martin >>>=20 >>> On 10 September 2012 22:20, Art Botterell wrote: >>>> Hi Richard - >>>>=20 >>>> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>>>=20 >>>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, = as described by XML-Signature and Syntax Processing," and makes = reference to both and . >>>>=20 >>>> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>>=20 >>>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>>=20 >>>> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>>>=20 >>>> - Art >>>>=20 >>>>=20 >>>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>>=20 >>>>> Dear ATOCA, >>>>>=20 >>>>> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). >>>>>=20 >>>>> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>>>>=20 >>>>> Comments very welcome. There's even a list of open questions at = the front! >>>>>=20 >>>>> Thanks a lot, >>>>> --Richard >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>>> has been successfully submitted by Richard Barnes and posted to = the >>>>>> IETF repository. >>>>>>=20 >>>>>> Filename: draft-barnes-atoca-escape >>>>>> Revision: 01 >>>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>>> Creation date: 2012-09-11 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 17 >>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>>=20 >>>>>> Abstract: >>>>>> Recipients of emergency alerts need to be able to verify that an >>>>>> alert they receive was issued by an authorized source. The = Common >>>>>> Alerting Protocol (CAP) provides a standard way of encoding alert >>>>>> information, but does not provide any security features that = would >>>>>> support authentication of alert originators. This document = describes >>>>>> a security wrapper for Common Alerting Protocol objects to allow >>>>>> alerts to be signed by alert originators. >>>>>>=20 >>>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From achi@bbn.com Wed Sep 12 08:27:38 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AACE21F8512 for ; Wed, 12 Sep 2012 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbSzydsL4NLm for ; Wed, 12 Sep 2012 08:27:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EF9C721F84E6 for ; Wed, 12 Sep 2012 08:27:37 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:60574 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBoqj-0008TZ-Q5; Wed, 12 Sep 2012 11:27:33 -0400 Message-ID: <5050A9C5.1090800@bbn.com> Date: Wed, 12 Sep 2012 11:27:01 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Rosen References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:27:38 -0000 On 9/11/2012 4:22 PM, Brian Rosen wrote: > The token scheme is not foolproof because an attacker might be able to forge a token value that matches the hash (it could know all the hashes, since it might be a recipient too). Thus, you use the hash test to do trivial discard, and then if you have something that the token check says is valid, then you do the real public key signature check to make sure it's valid. Slight fix to this statement: forging a token value won't happen since that requires computing a pre-image to a cryptographic hash function. What *could* happen is that an active MITM could intercept a message that already contains a legitimate token, and modify the body while leaving the token. So IMO we still need a signature. From achi@bbn.com Wed Sep 12 08:41:52 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F5121F8535 for ; Wed, 12 Sep 2012 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB+WfSX356LP for ; Wed, 12 Sep 2012 08:41:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C51F621F8534 for ; Wed, 12 Sep 2012 08:41:51 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:62691 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBp4S-000CQD-DL; Wed, 12 Sep 2012 11:41:44 -0400 Message-ID: <5050AD37.2020302@bbn.com> Date: Wed, 12 Sep 2012 11:41:43 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Rosen References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:41:52 -0000 On 9/11/2012 2:11 PM, Brian Rosen wrote: > I am less enthused about the token mechanism... What this feels like is a one time password Yep, I agree with Brian that the token system needs some work, both in terms of distribution as well as figuring out what to do with intermediaries (perhaps they don't participate in the token system?). Distribution might be made a little simpler by using a system akin to Leslie Lamport's One-Time-Password (OTP) scheme (RFC2289) where each successive token is the hash-preimage of the previous token. This would enable recipients to store only a single hash per originator (i.e. government agency). -Andrew From martin.thomson@gmail.com Wed Sep 12 10:02:50 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8861E21F861B for ; Wed, 12 Sep 2012 10:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv82Oq-MV0F2 for ; Wed, 12 Sep 2012 10:02:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7FF521F853F for ; Wed, 12 Sep 2012 10:02:49 -0700 (PDT) Received: by lbky2 with SMTP id y2so1427704lbk.31 for ; Wed, 12 Sep 2012 10:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CgGhNXqxpXKeH8MI/T8FeMasdKJbdb+w42YmmsEBRdw=; b=AKNUhq679Htz4q/4hRV0Zcd+4DM7C1Ml/pI5KzPzZka8DY6fziZXXU5yRlXF6QXetC zLX6JbLq4FZ67T80ad4rxDGtsTZ0qCM5EWZeTnPx8G0Xn7ClVe6JwlF2ulm5jtPSVNQY UdmHkt6tLmY7S9cpDl9wPZf5XBXWqcJbz3wagX4Z0D7HvKEtkLoQQFeCImDoqokR8E+e 97ktMI4HMmDMzH59/Z/8tZEol/rJDDhX2L8N90Z/gYusbzJVPz8eQFA31mcrBeiB2oAm 2bcOhUqqaheB5G41zURCxfgqt4yjyZADG7hAL9IYXihXs8A3nXTrzOTJIsaYEtVTMzrg MdYg== MIME-Version: 1.0 Received: by 10.152.123.140 with SMTP id ma12mr19756506lab.22.1347469368582; Wed, 12 Sep 2012 10:02:48 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 10:02:48 -0700 (PDT) In-Reply-To: <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> Date: Wed, 12 Sep 2012 10:02:48 -0700 Message-ID: From: Martin Thomson To: Art Botterell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:02:50 -0000 On 11 September 2012 12:36, Art Botterell wrote: > Hi Martin - > > Not sure how one might implement digital signatures of XML without canoni= calization, really, but if that "accepted wisdom" is correct, wouldn't that= better be addressed by refinement or replacement of RFC3275 rather than ve= ctoring off into development of a "splinter" specification? That's precisely the problem. I can digitally sign a serialization of XML relatively trivially, but to truly sign the XML then you need to canonicalize the content. JOSE are dealing with signing in a completely different fashion for this exact reason: they only deal with the serialization. That simplifies implementation greatly. > I do observe that all the various implementers of IPAWS-compatible system= s in the US have had to implement XML signatures and seem to have managed w= ithout undue difficulty. Perhaps the available libraries have improved. Perhaps they have. Though I note that it's a different matter to implement this sort of canonicalization in millions of devices with a wide range of capabilities. Last I checked, XML canonicalization libraries weren't small either. > And I'm not clear on what it is that tokens would optimize, but hopefully= Richard can explain that. Checking a signature is expensive. Proving that you have access to the pre-image for a prearranged hash allows clients to filter out bogus alerts quickly. From rbarnes@bbn.com Wed Sep 12 11:30:03 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C0121F853D for ; Wed, 12 Sep 2012 11:30:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id varSV0Jy4CpY for ; Wed, 12 Sep 2012 11:30:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB821F8557 for ; Wed, 12 Sep 2012 11:30:02 -0700 (PDT) Received: from [128.89.255.13] (port=59870) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBrhD-000EOF-SU; Wed, 12 Sep 2012 14:29:55 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> Date: Wed, 12 Sep 2012 14:29:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:30:03 -0000 Hey Art, I apologize for that line. I had forgotten about the use of XML-DSig in = CAP, probably because, as Martin notes, it's broadly viewed in the IETF = as not very interoperable. In general, it seems like we have a choice to make as to what security = container we want to specify here: -- XML-DSig -- S/MIME / CMS -- JOSE We (the authors) chose to go with S/MIME because in our view it was = simpler to implement than XML-DSig and more mature than JOSE. As Martin = noted, the simplicity compared to XML-DSig is largely due to the fact = that S/MIME just signs the serialized octets, so that the signing layer = doesn't need any knowledge of XML. In the long run, I think JOSE is = probably the way to go, because it's likely to be even easier to = implement than S/MIME, but that's still developing. Could you provide any data on how much actual implementation / usage of = XML-DSig with CAP? =20 Thanks, --Richard On Sep 11, 2012, at 1:20 AM, Art Botterell wrote: > Hi Richard - >=20 > I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." =20 >=20 > Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . =20 >=20 > Indeed, XMLSIG has been a feature of every CAP version since 1.0. And = if that's not enough, there's also the existing OASIS EDXL-DE wrapper = specification. >=20 > So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >=20 > But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >=20 > - Art >=20 >=20 > On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >=20 >> Dear ATOCA, >>=20 >> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). =20 >>=20 >> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>=20 >> Comments very welcome. There's even a list of open questions at the = front! >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >>=20 >> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>> has been successfully submitted by Richard Barnes and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-barnes-atoca-escape >>> Revision: 01 >>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>> Creation date: 2012-09-11 >>> WG ID: Individual Submission >>> Number of pages: 17 >>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>=20 >>> Abstract: >>> Recipients of emergency alerts need to be able to verify that an >>> alert they receive was issued by an authorized source. The Common >>> Alerting Protocol (CAP) provides a standard way of encoding alert >>> information, but does not provide any security features that would >>> support authentication of alert originators. This document = describes >>> a security wrapper for Common Alerting Protocol objects to allow >>> alerts to be signed by alert originators. >>>=20 >>> Please send feedback to the atoca@ietf.org mailing list. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Wed Sep 12 11:32:03 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFA21F852D for ; Wed, 12 Sep 2012 11:32:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2czzlajjpbn for ; Wed, 12 Sep 2012 11:32:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAF21F851B for ; Wed, 12 Sep 2012 11:32:02 -0700 (PDT) Received: from [128.89.255.13] (port=59883) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBrjF-000COC-GH; Wed, 12 Sep 2012 14:32:01 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> Date: Wed, 12 Sep 2012 14:32:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:32:04 -0000 Hi Art, Could you say more about how IPAWS uses XML signature? =20 It does seem like compatibility with IPAWS (and similar systems = elsewhere) might be a desirable feature for the overall ATOCA framework. --Richard On Sep 11, 2012, at 3:36 PM, Art Botterell wrote: > Hi Martin - >=20 > Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >=20 > I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >=20 > And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >=20 > - Art >=20 >=20 > On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >=20 >> Art, >>=20 >> It is generally accepted wisdom (in the IETF at least) that XML DSig >> [RFC3275] is a recipe for interoperability failure. The primary >> reason for this is the dependency on XML canonicalization. >>=20 >> I'd be interested in hearing a different perspective. I've used the >> apache library to implement an enveloped signature and it wasn't >> straightforward. I'm not aware of any other implementation, but it's >> been a few years since I last looked. >>=20 >> Of course, it's a different thing to say the mechanism is broken or >> unusable rather than "there is no mechanism". The former statement >> requires greater justification. >>=20 >> I'll let Richard explain the token mechanism. It's an optimization. >>=20 >> --Martin >>=20 >> On 10 September 2012 22:20, Art Botterell wrote: >>> Hi Richard - >>>=20 >>> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>>=20 >>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . >>>=20 >>> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>=20 >>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>=20 >>> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>>=20 >>> - Art >>>=20 >>>=20 >>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>=20 >>>> Dear ATOCA, >>>>=20 >>>> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). >>>>=20 >>>> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>>>=20 >>>> Comments very welcome. There's even a list of open questions at = the front! >>>>=20 >>>> Thanks a lot, >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>> has been successfully submitted by Richard Barnes and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-barnes-atoca-escape >>>>> Revision: 01 >>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>> Creation date: 2012-09-11 >>>>> WG ID: Individual Submission >>>>> Number of pages: 17 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>=20 >>>>> Abstract: >>>>> Recipients of emergency alerts need to be able to verify that an >>>>> alert they receive was issued by an authorized source. The Common >>>>> Alerting Protocol (CAP) provides a standard way of encoding alert >>>>> information, but does not provide any security features that would >>>>> support authentication of alert originators. This document = describes >>>>> a security wrapper for Common Alerting Protocol objects to allow >>>>> alerts to be signed by alert originators. >>>>>=20 >>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Wed Sep 12 11:45:21 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77221F8709 for ; Wed, 12 Sep 2012 11:45:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74XtqKO7h4y9 for ; Wed, 12 Sep 2012 11:45:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDB521F86B9 for ; Wed, 12 Sep 2012 11:45:20 -0700 (PDT) Received: from [128.89.255.13] (port=59932) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBrw1-000Cex-7e; Wed, 12 Sep 2012 14:45:13 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> Date: Wed, 12 Sep 2012 14:45:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:45:21 -0000 Keep in mind that even for full public-key signatures, there are things = to be pre-distributed. Namely, you need to know which public keys = correspond to trusted signers -- what's the public key for FEMA? This = can be partly addressed with PKI concepts, i.e., by distributing a CA = certificate under which authority certificates are issued. But there's = still a process of pre-distributing some public keys. Plus, as Andrew = pointed out, using the One Time Password scheme from RFC 2289 would mean = that an endpoint would only need to store one hash value per signer.=20 --Richard On Sep 11, 2012, at 4:42 PM, Art Botterell wrote: > Thanks, Brian, that's helpful. Sounds like it might require a bit of = infrastructure to pre-distribute the hashes... is this actually the most = efficient way to defend against DDoS attacks involving digital = signatures? >=20 > If so, I'm thinking CAP alerts might not be the most likely or even = the most critical place where this mechanism might be needed. Isn't = this a general vulnerability of any system that uses signatures? =20 >=20 > If so, might a defensive mechanism be worth developing on its own, as = an extension or adjunct to RFC3275, rather than associating it narrowly = with a particular application? >=20 > - Art >=20 > On Sep 11, 2012, at 1:22 PM, Brian Rosen wrote: >=20 >> Art >>=20 >> I think I can explain it. >>=20 >> Verifying a digital signature that uses public key crypto is = expensive. A convenient DoS attack on a client would be to forge a set = of alerts that are just nonsense, but appear to be valid. The client = has to check the signature to discover that it's bad, using lots of = cycles to do that. >>=20 >> The token provides a short cut to checking the signature that uses = far fewer cycles. Both ends have the token hash. The sender includes = the token value, which prior to sending it, was known only to the = sender. The recipient runs the hash algorithm on the value to see if it = matches one of the hashes it knows. The tokens are one time use, so a = replay is not possible. >>=20 >> The token scheme is not foolproof because an attacker might be able = to forge a token value that matches the hash (it could know all the = hashes, since it might be a recipient too). Thus, you use the hash test = to do trivial discard, and then if you have something that the token = check says is valid, then you do the real public key signature check to = make sure it's valid. >>=20 >> Brian >>=20 >> On Sep 11, 2012, at 3:36 PM, Art Botterell wrote: >>=20 >>> Hi Martin - >>>=20 >>> Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >>>=20 >>> I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >>>=20 >>> And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >>>=20 >>> - Art >>>=20 >>>=20 >>> On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >>>=20 >>>> Art, >>>>=20 >>>> It is generally accepted wisdom (in the IETF at least) that XML = DSig >>>> [RFC3275] is a recipe for interoperability failure. The primary >>>> reason for this is the dependency on XML canonicalization. >>>>=20 >>>> I'd be interested in hearing a different perspective. I've used = the >>>> apache library to implement an enveloped signature and it wasn't >>>> straightforward. I'm not aware of any other implementation, but = it's >>>> been a few years since I last looked. >>>>=20 >>>> Of course, it's a different thing to say the mechanism is broken or >>>> unusable rather than "there is no mechanism". The former statement >>>> requires greater justification. >>>>=20 >>>> I'll let Richard explain the token mechanism. It's an = optimization. >>>>=20 >>>> --Martin >>>>=20 >>>> On 10 September 2012 22:20, Art Botterell wrote: >>>>> Hi Richard - >>>>>=20 >>>>> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>>>>=20 >>>>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, = as described by XML-Signature and Syntax Processing," and makes = reference to both and . >>>>>=20 >>>>> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>>>=20 >>>>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>>>=20 >>>>> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>>>>=20 >>>>> - Art >>>>>=20 >>>>>=20 >>>>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>>>=20 >>>>>> Dear ATOCA, >>>>>>=20 >>>>>> In order to respond to the chairs' call for candidate alert = format documents, we have put together a revision of = draft-barnes-atoca-escape. As you may recall from earlier versions, = ESCAPE uses S/MIME to wrap a CAP document, in order to add = authentication for alert originators (digital signature and "alert = token"). >>>>>>=20 >>>>>> The changes from -00 are largely to add more explanatory text, = and clarify a few things technically. We haven't translated the whole = thing to JOSE (yet). Mostly, our hope is that in reading the new = version, you'll be able to envision how these secure alerts can be used = to build an overall alerting system. For example, they highlight some = of the things that a discover / metadata protocol might need to provide = (e.g., public keys for authorities). >>>>>>=20 >>>>>> Comments very welcome. There's even a list of open questions at = the front! >>>>>>=20 >>>>>> Thanks a lot, >>>>>> --Richard >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>>>> has been successfully submitted by Richard Barnes and posted to = the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-barnes-atoca-escape >>>>>>> Revision: 01 >>>>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>>>> Creation date: 2012-09-11 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 17 >>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> Recipients of emergency alerts need to be able to verify that an >>>>>>> alert they receive was issued by an authorized source. The = Common >>>>>>> Alerting Protocol (CAP) provides a standard way of encoding = alert >>>>>>> information, but does not provide any security features that = would >>>>>>> support authentication of alert originators. This document = describes >>>>>>> a security wrapper for Common Alerting Protocol objects to allow >>>>>>> alerts to be signed by alert originators. >>>>>>>=20 >>>>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>=20 >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Wed Sep 12 12:07:13 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166BC21F8717 for ; Wed, 12 Sep 2012 12:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYf+d9jbcy2E for ; Wed, 12 Sep 2012 12:07:12 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 22CA021F870F for ; Wed, 12 Sep 2012 12:07:12 -0700 (PDT) X-ASG-Debug-ID: 1347476746-0538de1033a92600001-FTS53d Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id 9rXy8f8PbNFgaba0; Wed, 12 Sep 2012 12:05:46 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:44729 helo=[192.168.133.194]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TBsFu-000HJF-Fn; Wed, 12 Sep 2012 12:05:46 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen X-ASG-Orig-Subj: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt In-Reply-To: <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com> Date: Wed, 12 Sep 2012 15:05:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1486) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1347476746 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.108350 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:07:13 -0000 I don't think you can use any of the OTP schemes that rely on either a = sequence (usually time based) or a challenge. Sequence doesn't work = because there isn't a good way to maintain sync with zillions of = recipients. Challenge doesn't work because we can't have the client = challenge the server for scalability reasons. PKI does need some pre-distribution, but it's also hierarchical, so we = don't need ALL the keys - if we trust a root, we only need to = pre-distribute the root cert. We can also use transitive trust. Brian On Sep 12, 2012, at 2:45 PM, Richard Barnes wrote: > Keep in mind that even for full public-key signatures, there are = things to be pre-distributed. Namely, you need to know which public = keys correspond to trusted signers -- what's the public key for FEMA? = This can be partly addressed with PKI concepts, i.e., by distributing a = CA certificate under which authority certificates are issued. But = there's still a process of pre-distributing some public keys. Plus, as = Andrew pointed out, using the One Time Password scheme from RFC 2289 = would mean that an endpoint would only need to store one hash value per = signer.=20 >=20 > --Richard >=20 >=20 >=20 >=20 > On Sep 11, 2012, at 4:42 PM, Art Botterell wrote: >=20 >> Thanks, Brian, that's helpful. Sounds like it might require a bit of = infrastructure to pre-distribute the hashes... is this actually the most = efficient way to defend against DDoS attacks involving digital = signatures? >>=20 >> If so, I'm thinking CAP alerts might not be the most likely or even = the most critical place where this mechanism might be needed. Isn't = this a general vulnerability of any system that uses signatures? =20 >>=20 >> If so, might a defensive mechanism be worth developing on its own, as = an extension or adjunct to RFC3275, rather than associating it narrowly = with a particular application? >>=20 >> - Art >>=20 >> On Sep 11, 2012, at 1:22 PM, Brian Rosen wrote: >>=20 >>> Art >>>=20 >>> I think I can explain it. >>>=20 >>> Verifying a digital signature that uses public key crypto is = expensive. A convenient DoS attack on a client would be to forge a set = of alerts that are just nonsense, but appear to be valid. The client = has to check the signature to discover that it's bad, using lots of = cycles to do that. >>>=20 >>> The token provides a short cut to checking the signature that uses = far fewer cycles. Both ends have the token hash. The sender includes = the token value, which prior to sending it, was known only to the = sender. The recipient runs the hash algorithm on the value to see if it = matches one of the hashes it knows. The tokens are one time use, so a = replay is not possible. >>>=20 >>> The token scheme is not foolproof because an attacker might be able = to forge a token value that matches the hash (it could know all the = hashes, since it might be a recipient too). Thus, you use the hash test = to do trivial discard, and then if you have something that the token = check says is valid, then you do the real public key signature check to = make sure it's valid. >>>=20 >>> Brian >>>=20 >>> On Sep 11, 2012, at 3:36 PM, Art Botterell wrote: >>>=20 >>>> Hi Martin - >>>>=20 >>>> Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >>>>=20 >>>> I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >>>>=20 >>>> And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >>>>=20 >>>> - Art >>>>=20 >>>>=20 >>>> On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >>>>=20 >>>>> Art, >>>>>=20 >>>>> It is generally accepted wisdom (in the IETF at least) that XML = DSig >>>>> [RFC3275] is a recipe for interoperability failure. The primary >>>>> reason for this is the dependency on XML canonicalization. >>>>>=20 >>>>> I'd be interested in hearing a different perspective. I've used = the >>>>> apache library to implement an enveloped signature and it wasn't >>>>> straightforward. I'm not aware of any other implementation, but = it's >>>>> been a few years since I last looked. >>>>>=20 >>>>> Of course, it's a different thing to say the mechanism is broken = or >>>>> unusable rather than "there is no mechanism". The former = statement >>>>> requires greater justification. >>>>>=20 >>>>> I'll let Richard explain the token mechanism. It's an = optimization. >>>>>=20 >>>>> --Martin >>>>>=20 >>>>> On 10 September 2012 22:20, Art Botterell = wrote: >>>>>> Hi Richard - >>>>>>=20 >>>>>> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." >>>>>>=20 >>>>>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, = as described by XML-Signature and Syntax Processing," and makes = reference to both and . >>>>>>=20 >>>>>> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>>>>=20 >>>>>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>>>>=20 >>>>>> But possibly you've just leapt ahead too far for me to follow in = a single bound. What am I missing here? >>>>>>=20 >>>>>> - Art >>>>>>=20 >>>>>>=20 >>>>>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>>>>=20 >>>>>>> Dear ATOCA, >>>>>>>=20 >>>>>>> In order to respond to the chairs' call for candidate alert = format documents, we have put together a revision of = draft-barnes-atoca-escape. As you may recall from earlier versions, = ESCAPE uses S/MIME to wrap a CAP document, in order to add = authentication for alert originators (digital signature and "alert = token"). >>>>>>>=20 >>>>>>> The changes from -00 are largely to add more explanatory text, = and clarify a few things technically. We haven't translated the whole = thing to JOSE (yet). Mostly, our hope is that in reading the new = version, you'll be able to envision how these secure alerts can be used = to build an overall alerting system. For example, they highlight some = of the things that a discover / metadata protocol might need to provide = (e.g., public keys for authorities). >>>>>>>=20 >>>>>>> Comments very welcome. There's even a list of open questions at = the front! >>>>>>>=20 >>>>>>> Thanks a lot, >>>>>>> --Richard >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>>>>> has been successfully submitted by Richard Barnes and posted to = the >>>>>>>> IETF repository. >>>>>>>>=20 >>>>>>>> Filename: draft-barnes-atoca-escape >>>>>>>> Revision: 01 >>>>>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>>>>> Creation date: 2012-09-11 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 17 >>>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> Recipients of emergency alerts need to be able to verify that = an >>>>>>>> alert they receive was issued by an authorized source. The = Common >>>>>>>> Alerting Protocol (CAP) provides a standard way of encoding = alert >>>>>>>> information, but does not provide any security features that = would >>>>>>>> support authentication of alert originators. This document = describes >>>>>>>> a security wrapper for Common Alerting Protocol objects to = allow >>>>>>>> alerts to be signed by alert originators. >>>>>>>>=20 >>>>>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The IETF Secretariat >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>=20 >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Wed Sep 12 12:27:10 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D721F86EE for ; Wed, 12 Sep 2012 12:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LR2CuB1mWKG for ; Wed, 12 Sep 2012 12:27:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4966D21F864A for ; Wed, 12 Sep 2012 12:27:08 -0700 (PDT) Received: from [128.89.255.13] (port=60053) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TBsaM-000DZt-Qq; Wed, 12 Sep 2012 15:26:54 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Wed, 12 Sep 2012 15:26:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com> To: Brian Rosen X-Mailer: Apple Mail (2.1278) Cc: atoca@ietf.org Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:27:10 -0000 When Andrew first pointed me to RFC 2289, I had the same reaction. But = you actually don't need everyone to get the message in order for it to = be useful. Suppose we have a hash chain=20 secret, h(secret), h^2(secret), ..., h^(n-1)(secret), h^n(secret) =3D = public The thing that gets published is h^n(secret) (along with n). The = authority has to use the tokens in sequence (h^(n-1), then h^(n-2), = ...), because once a token is public, so are all of the ones after it. =20= Clients don't have any dependency on the sequence. Whenever a client = receives a candidate hash, he hashes it until he gets the public value = (up to n times). So if the authority uses h^(n-2), a client will hash = it twice to get h^n, even if it hasn't seen h^(n-1). =20 Actually, clients can *benefit* from the sequencing: Since the next = token used will before a published token in the sequence, the client = just needs to cache the earliest token he's seen.=20 --Richard On Sep 12, 2012, at 3:05 PM, Brian Rosen wrote: > I don't think you can use any of the OTP schemes that rely on either a = sequence (usually time based) or a challenge. Sequence doesn't work = because there isn't a good way to maintain sync with zillions of = recipients. Challenge doesn't work because we can't have the client = challenge the server for scalability reasons. >=20 > PKI does need some pre-distribution, but it's also hierarchical, so we = don't need ALL the keys - if we trust a root, we only need to = pre-distribute the root cert. We can also use transitive trust. >=20 > Brian >=20 > On Sep 12, 2012, at 2:45 PM, Richard Barnes wrote: >=20 >> Keep in mind that even for full public-key signatures, there are = things to be pre-distributed. Namely, you need to know which public = keys correspond to trusted signers -- what's the public key for FEMA? = This can be partly addressed with PKI concepts, i.e., by distributing a = CA certificate under which authority certificates are issued. But = there's still a process of pre-distributing some public keys. Plus, as = Andrew pointed out, using the One Time Password scheme from RFC 2289 = would mean that an endpoint would only need to store one hash value per = signer.=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >> On Sep 11, 2012, at 4:42 PM, Art Botterell wrote: >>=20 >>> Thanks, Brian, that's helpful. Sounds like it might require a bit = of infrastructure to pre-distribute the hashes... is this actually the = most efficient way to defend against DDoS attacks involving digital = signatures? >>>=20 >>> If so, I'm thinking CAP alerts might not be the most likely or even = the most critical place where this mechanism might be needed. Isn't = this a general vulnerability of any system that uses signatures? =20 >>>=20 >>> If so, might a defensive mechanism be worth developing on its own, = as an extension or adjunct to RFC3275, rather than associating it = narrowly with a particular application? >>>=20 >>> - Art >>>=20 >>> On Sep 11, 2012, at 1:22 PM, Brian Rosen wrote: >>>=20 >>>> Art >>>>=20 >>>> I think I can explain it. >>>>=20 >>>> Verifying a digital signature that uses public key crypto is = expensive. A convenient DoS attack on a client would be to forge a set = of alerts that are just nonsense, but appear to be valid. The client = has to check the signature to discover that it's bad, using lots of = cycles to do that. >>>>=20 >>>> The token provides a short cut to checking the signature that uses = far fewer cycles. Both ends have the token hash. The sender includes = the token value, which prior to sending it, was known only to the = sender. The recipient runs the hash algorithm on the value to see if it = matches one of the hashes it knows. The tokens are one time use, so a = replay is not possible. >>>>=20 >>>> The token scheme is not foolproof because an attacker might be able = to forge a token value that matches the hash (it could know all the = hashes, since it might be a recipient too). Thus, you use the hash test = to do trivial discard, and then if you have something that the token = check says is valid, then you do the real public key signature check to = make sure it's valid. >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 11, 2012, at 3:36 PM, Art Botterell = wrote: >>>>=20 >>>>> Hi Martin - >>>>>=20 >>>>> Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >>>>>=20 >>>>> I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >>>>>=20 >>>>> And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >>>>>=20 >>>>> - Art >>>>>=20 >>>>>=20 >>>>> On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote: >>>>>=20 >>>>>> Art, >>>>>>=20 >>>>>> It is generally accepted wisdom (in the IETF at least) that XML = DSig >>>>>> [RFC3275] is a recipe for interoperability failure. The primary >>>>>> reason for this is the dependency on XML canonicalization. >>>>>>=20 >>>>>> I'd be interested in hearing a different perspective. I've used = the >>>>>> apache library to implement an enveloped signature and it wasn't >>>>>> straightforward. I'm not aware of any other implementation, but = it's >>>>>> been a few years since I last looked. >>>>>>=20 >>>>>> Of course, it's a different thing to say the mechanism is broken = or >>>>>> unusable rather than "there is no mechanism". The former = statement >>>>>> requires greater justification. >>>>>>=20 >>>>>> I'll let Richard explain the token mechanism. It's an = optimization. >>>>>>=20 >>>>>> --Martin >>>>>>=20 >>>>>> On 10 September 2012 22:20, Art Botterell = wrote: >>>>>>> Hi Richard - >>>>>>>=20 >>>>>>> I'm confused by the claim that CAP "does not provide any = security features that would support authentication of alert = originators." >>>>>>>=20 >>>>>>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, = as described by XML-Signature and Syntax Processing," and makes = reference to both and . >>>>>>>=20 >>>>>>> Indeed, XMLSIG has been a feature of every CAP version since = 1.0. And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>>>>>>=20 >>>>>>> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>>>>>>=20 >>>>>>> But possibly you've just leapt ahead too far for me to follow in = a single bound. What am I missing here? >>>>>>>=20 >>>>>>> - Art >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>>>>>>=20 >>>>>>>> Dear ATOCA, >>>>>>>>=20 >>>>>>>> In order to respond to the chairs' call for candidate alert = format documents, we have put together a revision of = draft-barnes-atoca-escape. As you may recall from earlier versions, = ESCAPE uses S/MIME to wrap a CAP document, in order to add = authentication for alert originators (digital signature and "alert = token"). >>>>>>>>=20 >>>>>>>> The changes from -00 are largely to add more explanatory text, = and clarify a few things technically. We haven't translated the whole = thing to JOSE (yet). Mostly, our hope is that in reading the new = version, you'll be able to envision how these secure alerts can be used = to build an overall alerting system. For example, they highlight some = of the things that a discover / metadata protocol might need to provide = (e.g., public keys for authorities). >>>>>>>>=20 >>>>>>>> Comments very welcome. There's even a list of open questions = at the front! >>>>>>>>=20 >>>>>>>> Thanks a lot, >>>>>>>> --Richard >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>>>>>>> has been successfully submitted by Richard Barnes and posted = to the >>>>>>>>> IETF repository. >>>>>>>>>=20 >>>>>>>>> Filename: draft-barnes-atoca-escape >>>>>>>>> Revision: 01 >>>>>>>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>>>>>>> Creation date: 2012-09-11 >>>>>>>>> WG ID: Individual Submission >>>>>>>>> Number of pages: 17 >>>>>>>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>>>>>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>>>>>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>>>>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> Recipients of emergency alerts need to be able to verify that = an >>>>>>>>> alert they receive was issued by an authorized source. The = Common >>>>>>>>> Alerting Protocol (CAP) provides a standard way of encoding = alert >>>>>>>>> information, but does not provide any security features that = would >>>>>>>>> support authentication of alert originators. This document = describes >>>>>>>>> a security wrapper for Common Alerting Protocol objects to = allow >>>>>>>>> alerts to be signed by alert originators. >>>>>>>>>=20 >>>>>>>>> Please send feedback to the atoca@ietf.org mailing list. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF Secretariat >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> atoca mailing list >>>>>>>> atoca@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>=20 >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>=20 >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From artbotterell@gmail.com Wed Sep 12 21:32:12 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0315121F8440 for ; Wed, 12 Sep 2012 21:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjpsFgaBaFBM for ; Wed, 12 Sep 2012 21:32:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4948D21F845A for ; Wed, 12 Sep 2012 21:32:10 -0700 (PDT) Received: by iabz21 with SMTP id z21so2069701iab.31 for ; Wed, 12 Sep 2012 21:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=+khwibDSgrvsYVQTu4Wg8nM0AImRYiBRLx8HIxLQ8nk=; b=r0sm0fERby+CHrZ4FETXWuW0cANHZSfFCM519Lb5bguFvJ/OecieA6SnnE7hIqqUDq sBwLRVT24/ew2Yg9r/yYoCzEzo7UM+48s+kGq0twjFJ3MVDs64PfSBSJgng7ArOLtDei eiABdXdBCRx0HNUt1wKAl4cmZximr8Cw2zOGY4E5Wdl9BvxdpTGTgs3a3thb+aduFEw+ cO//Qtxo0xEkGNXq2AM/olxEW+SrJKGfj5OvglPZ3ZunMTNw18VpMKxRs8y+3kJdHyx7 oLtfec7oBmAGH/qbNXvNxSFZC7fT2vTfoZNF+CX0vCQG14Rgx+zcVW3UJrfEQmKiWdNm aVDw== Received: by 10.50.202.73 with SMTP id kg9mr666332igc.42.1347510729684; Wed, 12 Sep 2012 21:32:09 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id ng5sm6739189igc.0.2012.09.12.21.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Sep 2012 21:32:04 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Art Botterell In-Reply-To: Date: Wed, 12 Sep 2012 21:31:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45D805F9-6DCC-4C66-9554-7007CC5F7F69@incident.com> References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 04:32:12 -0000 Hi Richard / All - Again it sounds like we might be trying to address a general problem = with end-to-end authentication... or perhaps with XML... that's in no = way particular to the alerting domain. A worthy undertaking, so far as = I can tell, but is this really the best venue for it? Re your questions about IPAWS, all providers of software compatible with = IPAWS, CMAS and/or EAS in the U.S. have had to demonstrate their = products' ability to apply or verify signed XML CAP messages. The list = of IPAWS-certified vendors ran to several dozen last time I looked. And = since each IPAWS message must be signed I infer that FEMA has = bought-or-built a PKI to support the thousands or tens-of-thousands of = potential IPAWS, although I haven't looked into the details lately. Another system recently deployed by the UN Development Program in the = Caribbean also uses signed-XML CAP, so implementation of the existing = standard isn't limited to IPAWS or the US. - Art On Sep 12, 2012, at 11:29 AM, Richard Barnes wrote: > Hey Art, >=20 > I apologize for that line. I had forgotten about the use of XML-DSig = in CAP, probably because, as Martin notes, it's broadly viewed in the = IETF as not very interoperable. >=20 > In general, it seems like we have a choice to make as to what security = container we want to specify here: > -- XML-DSig > -- S/MIME / CMS > -- JOSE >=20 > We (the authors) chose to go with S/MIME because in our view it was = simpler to implement than XML-DSig and more mature than JOSE. As Martin = noted, the simplicity compared to XML-DSig is largely due to the fact = that S/MIME just signs the serialized octets, so that the signing layer = doesn't need any knowledge of XML. In the long run, I think JOSE is = probably the way to go, because it's likely to be even easier to = implement than S/MIME, but that's still developing. >=20 > Could you provide any data on how much actual implementation / usage = of XML-DSig with CAP? =20 >=20 > Thanks, > --Richard >=20 >=20 >=20 > On Sep 11, 2012, at 1:20 AM, Art Botterell wrote: >=20 >> Hi Richard - >>=20 >> I'm confused by the claim that CAP "does not provide any security = features that would support authentication of alert originators." =20 >>=20 >> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The = element of a CAP Alert Message MAY have an Enveloped Signature, as = described by XML-Signature and Syntax Processing," and makes reference = to both and = . =20 >>=20 >> Indeed, XMLSIG has been a feature of every CAP version since 1.0. = And if that's not enough, there's also the existing OASIS EDXL-DE = wrapper specification. >>=20 >> So while I'm a huge supporter of an end-to-end approach to CAP = authentication, on the face of it the ESCAPE draft seems duplicative and = somewhat ill-informed. Also I fear I'm missing the point of the added = "alert token" mechanism, other than to add one more maintenance task = that nobody is going to want to own. >>=20 >> But possibly you've just leapt ahead too far for me to follow in a = single bound. What am I missing here? >>=20 >> - Art >>=20 >>=20 >> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote: >>=20 >>> Dear ATOCA, >>>=20 >>> In order to respond to the chairs' call for candidate alert format = documents, we have put together a revision of draft-barnes-atoca-escape. = As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a = CAP document, in order to add authentication for alert originators = (digital signature and "alert token"). =20 >>>=20 >>> The changes from -00 are largely to add more explanatory text, and = clarify a few things technically. We haven't translated the whole thing = to JOSE (yet). Mostly, our hope is that in reading the new version, = you'll be able to envision how these secure alerts can be used to build = an overall alerting system. For example, they highlight some of the = things that a discover / metadata protocol might need to provide (e.g., = public keys for authorities). >>>=20 >>> Comments very welcome. There's even a list of open questions at the = front! >>>=20 >>> Thanks a lot, >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote: >>>=20 >>>>=20 >>>> A new version of I-D, draft-barnes-atoca-escape-01.txt >>>> has been successfully submitted by Richard Barnes and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-barnes-atoca-escape >>>> Revision: 01 >>>> Title: Encoding of Secure Common Alert Protocol = Entities (ESCAPE) >>>> Creation date: 2012-09-11 >>>> WG ID: Individual Submission >>>> Number of pages: 17 >>>> URL: = http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-barnes-atoca-escape >>>> Htmlized: = http://tools.ietf.org/html/draft-barnes-atoca-escape-01 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-atoca-escape-01 >>>>=20 >>>> Abstract: >>>> Recipients of emergency alerts need to be able to verify that an >>>> alert they receive was issued by an authorized source. The Common >>>> Alerting Protocol (CAP) provides a standard way of encoding alert >>>> information, but does not provide any security features that would >>>> support authentication of alert originators. This document = describes >>>> a security wrapper for Common Alerting Protocol objects to allow >>>> alerts to be signed by alert originators. >>>>=20 >>>> Please send feedback to the atoca@ietf.org mailing list. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From brian.rosen@neustar.biz Thu Sep 13 06:58:03 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503A421F8564 for ; Thu, 13 Sep 2012 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.362 X-Spam-Level: X-Spam-Status: No, score=-5.362 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXWMLTN-iegQ for ; Thu, 13 Sep 2012 06:58:02 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4643B21F8557 for ; Thu, 13 Sep 2012 06:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347544796; x=1662904447; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=CSPsHP1DxSQOv8FLht0qh 2wVWTwUZMoDpPOXQ5fD440=; b=YE5x9MpiPNwQ9sJjEVZNbfc3lR4PPPX8QPLnq 4Zj1DyV2lKnsGYW9/Wnjhu6ZdPjufd7D5inDnoqG9vqz+FwlQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.13663878; Thu, 13 Sep 2012 09:59:55 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 13 Sep 2012 09:57:59 -0400 From: "Rosen, Brian" To: "atoca@ietf.org" Date: Thu, 13 Sep 2012 09:57:58 -0400 Thread-Topic: What is the scope of "Secure Alerting Format" Thread-Index: Ac2Rt8gkNW3bHJurTtidRvhJpElIrg== Message-ID: <5619B668-E739-4B26-A6E9-A8A69BED49D5@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: qvwzHRrK2/DxtRhF40Wgyg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [atoca] What is the scope of "Secure Alerting Format" X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 13:58:03 -0000 In the revised plan, we're supposed to be concentrating on a "Secure Alerti= ng Format" But what is the scope of that? I raised, for example, the issue of "area of interest" where the typical CA= P message content is not machine actionable to filter messages to the right= devices. The polygon for "continental United States" is not practical to = send, and many alerts just have the description. Is the thing that gets us= the area of interest we can route on in scope or not? Is identity of the originator in scope? A lot of this depends on the line between "transport" and "format", and I d= on't understand where we are drawing that line. Brian= From martin.thomson@gmail.com Thu Sep 13 10:27:36 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30221F84EA for ; Thu, 13 Sep 2012 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD19cK7H1OMy for ; Thu, 13 Sep 2012 10:27:36 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE621F84E2 for ; Thu, 13 Sep 2012 10:27:35 -0700 (PDT) Received: by lahm15 with SMTP id m15so2245808lah.31 for ; Thu, 13 Sep 2012 10:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QHpE4XZEvZ3lwd4bn1/3haFzfmZFJ+m2nn/oLVcb6P4=; b=COMCbqqvrEnYNZzzt1YU9q9MZIcjAMYTggQ69YTNrtfBQBZuu/BRJ4cD8De1YVWYF0 KnrVBQ2KlS7AH8bJwIjRb1O/4oXg1pOU+umXuo6y82sG212cydi5Ih5s48mJ37s33nLf 5IcOmEIL5/6BelMSpPJg5k4AD94dshiCO6rAkSp6ULSDopWnRA81vXhwfULzBTifxwRu FjnRInmbECcaWEFTxmGXK3hKufdc+hR4DlfyTGHzRQ+ZhvAc1O1Vgm2/Lp2RA1nF5rJx Mc2eChsLvlY1MbOM0CxXi1eqX/h2yr7qJLuQB23zhSzO0a/HTfIKY+XX/4gYymIDj0eC UtZg== MIME-Version: 1.0 Received: by 10.112.27.69 with SMTP id r5mr136524lbg.91.1347557254627; Thu, 13 Sep 2012 10:27:34 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Thu, 13 Sep 2012 10:27:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Sep 2012 10:27:34 -0700 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [atoca] ATOCA Milestones X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:27:36 -0000 Thanks to Richard, we have met the first milestone. On 17 August 2012 11:25, Martin Thomson wrote: > Based on the discussion at the last meeting, the chairs and > responsible AD have formulated the following milestones. > > These milestones replace all existing working group milestones. If we > are fortunate enough to complete these, then there shouldn't be any > problem in coming up with more. > > The understanding is that if these milestones are not met, then the > working group will be closed. > > -- > August 17, 2012 - Call for proposals for Secure Alerting Format > > September 12, 2012 - Individual contribution(s) made for Secure > Alerting Format draft > > October 1, 2012 - Call for WG consensus on adopting a Secure Alerting Format > draft into the WG > > October 15, 2012 - First WG draft of Secure Alerting Format > > February 20, 2013 - Submit Secure Alerting Format draft to the IESG as > Proposed Standard > -- > > The chairs request that the working group concentrate efforts on these > milestones. The following work is potentially of interest, but we may > request that discussion be curtailed if is deemed to be affecting > progress toward these milestones: > - alert delivery mechanisms > - discovery of alert sources > - discovery of trust anchors > If this experiment succeeds we can discuss proceeding with these. From mamille2@cisco.com Mon Sep 17 13:30:01 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6D21E804A for ; Mon, 17 Sep 2012 13:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dge6VoQl52Yp for ; Mon, 17 Sep 2012 13:30:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 604FC21E8047 for ; Mon, 17 Sep 2012 13:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6615; q=dns/txt; s=iport; t=1347913800; x=1349123400; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YTg19Jbxs/gJsc2HXgJ7T0fUY07zWaau2sewu3BUM1E=; b=QkrBMUa/+yHdzwK4nR1gr243SjOV3L+sreBEBZko5N3s9B1hQQdV1jwk up1QjBqm6FWgkie+e16phuNCJ/a2ioJMbu7YSyJhJGbeIZJkmw8Yst6NO 20kUWwMf48OWhrMKjj1zxamic0eW61HNPXzy9UKL10V8+g+U3ORP9nUfP g=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG6HV1CtJXG9/2dsb2JhbABEvCGBB4IgAQEBAwEBAQEPAVsJAgULAgEIGC4CJQslAgQOBQ4UhW+BaQYLmkGgBQSLIYYIYAOOaYEghVmOOIFpgmaBYzQ X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="sig'?p7s'?scan'208";a="122487310" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 17 Sep 2012 20:30:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8HKTvi6015185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 20:29:59 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 15:29:47 -0500 From: "Matt Miller (mamille2)" To: Martin Thomson Thread-Topic: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt Thread-Index: AQHNj8+aghIRaVxQhU+adlTN6rgv+JeE7m+AgADD/gCAACsiAIABZ4IAgAgVfgA= Date: Mon, 17 Sep 2012 20:29:47 +0000 Message-ID: References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.40] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004 x-tm-as-result: No--35.135800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-239401199" MIME-Version: 1.0 Cc: "" Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:30:01 -0000 --Apple-Mail-4-239401199 Content-Type: multipart/signed; boundary=Apple-Mail-3-239401190; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-3-239401190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Martin's and Richard's sentiments on this. The vast = majority of XML or XML-like implementations I am aware of cannot = properly verify or generate XML canonicalization. I also have concern = of transporting XMLDSig things over transports that look an awful lot = like XML, and the potential for incompatibility because of the lack of = XML canonicalization support. In my opinion, using a serialized method such as ESCAPE would mitigate = most of that concern. - m&m Matt Miller - Cisco Systems, Inc. On Sep 12, 2012, at 11:02, Martin Thomson wrote: > On 11 September 2012 12:36, Art Botterell wrote: >> Hi Martin - >>=20 >> Not sure how one might implement digital signatures of XML without = canonicalization, really, but if that "accepted wisdom" is correct, = wouldn't that better be addressed by refinement or replacement of = RFC3275 rather than vectoring off into development of a "splinter" = specification? >=20 > That's precisely the problem. I can digitally sign a serialization of > XML relatively trivially, but to truly sign the XML then you need to > canonicalize the content. JOSE are dealing with signing in a > completely different fashion for this exact reason: they only deal > with the serialization. That simplifies implementation greatly. >=20 >> I do observe that all the various implementers of IPAWS-compatible = systems in the US have had to implement XML signatures and seem to have = managed without undue difficulty. Perhaps the available libraries have = improved. >=20 > Perhaps they have. Though I note that it's a different matter to > implement this sort of canonicalization in millions of devices with a > wide range of capabilities. Last I checked, XML canonicalization > libraries weren't small either. >=20 >> And I'm not clear on what it is that tokens would optimize, but = hopefully Richard can explain that. >=20 > Checking a signature is expensive. Proving that you have access to > the pre-image for a prearranged hash allows clients to filter out > bogus alerts quickly. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca --Apple-Mail-3-239401190 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDkxNzIwMjk0 OFowIwYJKoZIhvcNAQkEMRYEFCLGRTYoMheVYkGezByNDgNT9uqfMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCwN+hCWCKsGZhmROosj0WLloTa9N380kCSs1kch6vUrG+yEqqD7XT+pQ3i kvAbCp5U0by/Ity6BSRh8H20GLiF9t7KYyZZEDMR0wW0lLmmZjzesNfRIwxDb5gd1O/zSD0E++1R emDxGk3H0mNgwf31xb4YgSUH4ZyFtMHd6LyGvl/cbP8wsLXLxqEl2Dp3+KSjpivxc+oTrtcQ2PLP SKLPqDNizeyQnoI6Fu0TTJJ9FpvSsW1FTRlWyFlHjxhaNsikceavbiujjdzwT60kAVytNhtl8yVM WZizgmjI3iyY7of+zfvBFn4EARyQZlDE9ZPELsx4KpLp2RinySKwm1V2AAAAAAAA --Apple-Mail-3-239401190-- --Apple-Mail-4-239401199 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQV4g8AAoJEJq6Ou0cgrSP2TcIANmYDXaKpdnEMLOJd0AhJz2x vhtaSnCQ4GRd2a+z+DNalnm78887FRf2FMD4oBdX/zM5m+rVsP7soJEYllJi044H 0so1q6luI/gUmWli+Hb9DmxNrx8eb2W4ZA6k3FUHzfvqXURiFWdFSiOzMqvLFB2w GuFc2Zidew7YHHgNwrth5b3KCkxi4od2ofnMAkH8hDzUihltk96iT3m7/ualH0dY RqYIBw0Tn9cdYTDLeJvD485xsCwep6iJuemQiKW6sFTI9HzV2SkoGYoILXj1A/UM rl8sHmPBb8t5nfFY3q7Wh5oLDNBlS9ageSwYGaduWbqwsWdTXEwG6gEzyr2k/Lw= =CEkj -----END PGP SIGNATURE----- --Apple-Mail-4-239401199-- From rbarnes@bbn.com Thu Sep 20 18:58:20 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7154A21F8540 for ; Thu, 20 Sep 2012 18:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZrlSmH9oIb9 for ; Thu, 20 Sep 2012 18:58:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60721F85C6 for ; Thu, 20 Sep 2012 18:58:19 -0700 (PDT) Received: from [128.89.255.200] (port=64398) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TEsVW-0009Sd-Ok; Thu, 20 Sep 2012 21:58:18 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <5619B668-E739-4B26-A6E9-A8A69BED49D5@neustar.biz> Date: Thu, 20 Sep 2012 21:58:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5619B668-E739-4B26-A6E9-A8A69BED49D5@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1278) Cc: "atoca@ietf.org" Subject: Re: [atoca] What is the scope of "Secure Alerting Format" X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 01:58:20 -0000 In general, I would say that the "Secure Alerting Format" is something = that=20 1. Represents the alert using CAP or a profile of CAP (=3D=3D "Alerting = Format") 2. Allows the recipient to verify the identity of the originator and/or = relay(s) So the areas for discussion are (1) whether we want to just incorporate = CAP by reference, or add some constraints, and (2) how we want to enable = originator/relay authentication. Couple of questions inline. On Sep 13, 2012, at 9:57 AM, Rosen, Brian wrote: > In the revised plan, we're supposed to be concentrating on a "Secure = Alerting Format" >=20 > But what is the scope of that? >=20 > I raised, for example, the issue of "area of interest" where the = typical CAP message content is not machine actionable to filter messages = to the right devices. The polygon for "continental United States" is = not practical to send, and many alerts just have the description. Is = the thing that gets us the area of interest we can route on in scope or = not? I don't really know enough about CAP to comment in depth here, but this = sounds at a high level like a CAP profiling problem. "Alert originators = SHOULD embed enough information in the CAP message so that the device = receiving the alert can determine automatically whether it is in the = area of interest or not." It seems like a good question for the group whether profiling CAP is in = scope here, since that might cause compatibility issues with legacy = systems. If we suppose that we might take a more "system-scale" view in = the future, we could also kick the can down the road. (Analogy: SIP = allows codec negotiation; phonebcp says what codecs you MUST support.) > Is identity of the originator in scope? I would say that the question of which originators are authorized (i.e., = which originators a recipient will accept) is out of scope; that's a = provisioning/metadata question. The techniques for associating the = alert with one or more verified originator identities is in scope. =20 In other words, the S/MIME might include a certificate chain that shows = that the alert was signed by an entity with CN=3DFEMA, but if I'm in = Bolivia I might choose to reject that because FEMA isn't an authority = there. > A lot of this depends on the line between "transport" and "format", = and I don't understand where we are drawing that line. >=20 > Brian > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From martin.thomson@gmail.com Tue Sep 25 10:09:46 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43D01F0C82 for ; Tue, 25 Sep 2012 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.743 X-Spam-Level: X-Spam-Status: No, score=-3.743 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O37TDEd0XpU2 for ; Tue, 25 Sep 2012 10:09:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 321BE1F0CA2 for ; Tue, 25 Sep 2012 10:09:44 -0700 (PDT) Received: by lbok13 with SMTP id k13so491096lbo.31 for ; Tue, 25 Sep 2012 10:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ojVuWdzox+OeNi+j4WE8v4WsLkIzLiRJeJ0GEoJ+mhI=; b=s7uK/NeOzLKmAU0Dk8CKK266D1gccwHFRzt+69hyRIQsoQ5VVrFj4goMDtqz//Yy6U zGh4WhvdnfX6Q7Uu6gUmmrFpvAruvIpCtL4SgqwQRUn7WHUzxjd5b0W5psfU7cjFP/lK Flqd4GiIInmu4UZTmKmpfkKE8hhwnJuHzo3nNXt51GDd4/0xUfKIKqE9fu5SxYB2qrez kQtM/Oi1c7RAEn9VhKh2qRw7QZUaObufrInCdZD5lgbQ3PJ5OsZedkbWxsw4cUzf0DeD 6Vw4RIeJr6XoZiD2qifUTk80hZTF9O2ZaQivUazSCXSFUfsEIPu8ur0WqTCvaUChQBNM SRSw== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr14052537lab.22.1348592983929; Tue, 25 Sep 2012 10:09:43 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Tue, 25 Sep 2012 10:09:43 -0700 (PDT) Date: Tue, 25 Sep 2012 10:09:43 -0700 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:09:47 -0000 There isn't a lot of time before the Atlanta meeting. These are our upcoming milestones: *1st* Oct 2012 - Call for WG consensus on adopting a Secure Alerting Format draft into the WG *15th* Oct 2012 - First WG draft of Secure Alerting Format We've had some discussion on draft-barnes-atoca-escape. >From my reading of the discussion, these are the major issues with the draft: 1. The use of CMS duplicates the capabilities provided by CAP, which uses XML digital signature. 2. The usefulness of Alert Tokens. I'd like to hear what people feel would resolve these issues, or if these represent irreconcilable differences. From br@brianrosen.net Tue Sep 25 10:30:48 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C374C21F881B for ; Tue, 25 Sep 2012 10:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.274 X-Spam-Level: X-Spam-Status: No, score=-101.274 tagged_above=-999 required=5 tests=[AWL=-2.325, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VWyFx8HvQt5 for ; Tue, 25 Sep 2012 10:30:48 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 24C9021F8448 for ; Tue, 25 Sep 2012 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=cgyR9cw8xg+A051aJhZrn4vDLZbyG+0ypi0kzTlSA68=; b=B/koJfSE+b7/o++PPnNHCsYQysX/FO571M/m6wPxkV0o/O9Kr8d3boYkU1XvwnvMD/wGvvwEUeCmO8gtAiY9xGit83IUdR2Nag3rBnlY1kRHIhAXpp4euFEPkAQEJH1d; Received: from neustargw.va.neustar.com ([209.173.53.233]:12495 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGYy6-0005Yg-VY; Tue, 25 Sep 2012 13:30:47 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen In-Reply-To: Date: Tue, 25 Sep 2012 13:30:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> References: To: Martin Thomson X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:30:48 -0000 I think this draft is helpful, but I'm still not sure how it's going to = fit in the scheme of things. I guess I am unsure of how many wrappings there will be. This has something to do with transport, and includes my concerns about = automated geotargeting. It would seem to me that we either have to extend or profile the current = field in CAP to get what we want, or we need a wrapper that has some = more standardized representation of area affected (something like = PIDF-LO). For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? I like the idea of Alert-Tokens quite a bit (low cost filter on = authenticity). I'm still unsure about the details. I do think we're having difficulty on the signature thing. On the one = hand, we have existence proof that the CAP mechanism works well enough. = On the other hand, we have the generic "dSig has problems, especially = with respect to canonicalization" statements. Somehow, we're talking = past each other, and we need to find out why CAP users have not had the = problems the nay sayers say they should be having. On Sep 25, 2012, at 1:09 PM, Martin Thomson = wrote: > There isn't a lot of time before the Atlanta meeting. These are our > upcoming milestones: >=20 > *1st* Oct 2012 - Call for WG consensus on adopting a Secure Alerting > Format draft into the WG > *15th* Oct 2012 - First WG draft of Secure Alerting Format >=20 > We've had some discussion on draft-barnes-atoca-escape. >=20 > =46rom my reading of the discussion, these are the major issues with = the draft: > 1. The use of CMS duplicates the capabilities provided by CAP, which > uses XML digital signature. > 2. The usefulness of Alert Tokens. >=20 > I'd like to hear what people feel would resolve these issues, or if > these represent irreconcilable differences. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 25 11:15:01 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2721F8827 for ; Tue, 25 Sep 2012 11:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdO77NNOrsBT for ; Tue, 25 Sep 2012 11:15:00 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61A9921F861E for ; Tue, 25 Sep 2012 11:15:00 -0700 (PDT) Received: by padfb11 with SMTP id fb11so2404071pad.31 for ; Tue, 25 Sep 2012 11:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=/IV8IFccwFtQgI71iU21yK7WsD1qy33Qczf9Ua1SF2M=; b=yOYykeoWIRODbyhMGZl2mCy02FFeDG6f7k0BYLM5yFFlHC4dkww81XJzFWBlJm7Rb5 8xS8Ddwkn2MpEf6VnDaEJ7F8lA6aOcf+M3HVci4fkHZcINhv8OhGlZTF8cXmXZ5ZQmeu FswbjhMoSAjBpO7q+jo9lhh22hnTqZEBhoeNezRE+JtUSj2L6B+MidnM2gteasMAdXFl /YLWx9FocZSMb1025mYEa5SbegDTFfznct/2bvOHCWBn9QfBKNaW4+X31A4bf3aXra+E 6FvHBGDvAPrDt1SJfpIBoyVI7Fcx9Vayh7S+7j0Czh/CFCDJVcQb4Lhoa/gFm/eBW4XH t5MQ== Received: by 10.68.222.37 with SMTP id qj5mr47741216pbc.132.1348596900161; Tue, 25 Sep 2012 11:15:00 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id wn1sm666935pbc.57.2012.09.25.11.14.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 11:14:59 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Art Botterell In-Reply-To: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> Date: Tue, 25 Sep 2012 11:14:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> To: atoca@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:15:01 -0000 On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: > For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? In CAP the recommended presentation would be a polygon, a line of text = that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). There are a few subtleties here. First, most hazard footprints don't = align very well with political boundaries, so it's actually considered = best practice NOT to address an alert to everyone in a political = jurisdiction if better resolution is available, which increasingly often = is the case. (This is probably the biggest challenges in the transition = from the legacy EAS and Weather Radio systems in the States and the = newer CAP-based IPAWS framework.) Second, but related to the first... there is at present no strict limit = on the number of vertices in a polygon in CAP. Generally this hasn't = been a problem, as both manual and model-derived (e.g., from a hazardous = materials "plume model" software) polygons tend to be relatively simple. = However, if one uses a political jurisdiction as the target area and = if, as often is the case, that jurisdiction is defined at least in part = by a waterway or water body, then at least part of the "true" polygon = will be fractal in nature and the number of vertices used to represent = it becomes an implementation decision. =20 In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. And third, of course, there's quite a bit of variety in how polygons get = represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between = the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. And the text areaDescription field is defined merely as "human readable" = so it can be as concise or as extensive as circumstances dictate. = However, where multi-lingual alerting is required it tends to be kept = short to facilitate translation. - Art= From br@brianrosen.net Tue Sep 25 11:25:07 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2621F87DF for ; Tue, 25 Sep 2012 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.604 X-Spam-Level: X-Spam-Status: No, score=-100.604 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl3H0+VL-iOM for ; Tue, 25 Sep 2012 11:25:06 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8032321F87DB for ; Tue, 25 Sep 2012 11:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=vu/1xYWdEwwEY33pKKWs1Bo3Alj+2VElQrUIDD/vPW0=; b=m/suJKy4S0a/RVROhnbcbir8K/IE1y2lwsPX3FA70VNhK32/XF97MBWBiaYQNM09TXD+0YwDqkLsLDJki8jZ+bvq/l3af9ys7qZjv1ZBT0LRUeSk6obQnfKxYD0VXpSB; Received: from neustargw.va.neustar.com ([209.173.53.233]:19321 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGZof-00014u-68; Tue, 25 Sep 2012 14:25:05 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen In-Reply-To: <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> Date: Tue, 25 Sep 2012 14:25:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:25:07 -0000 I guess that's my point. Without more spec, we have interoperability = issues. When you have limited CAP deployment, these can be dealt with = by prior arrangement. We probably can't do that. I would prefer that a = polygon be encoded with GML, which is precise, interoperable and an = accepted global standard. That can be wrapped in a PIDF (an IETF = standard) or not, but we need something very interoperable. Forcing polygons may work in a forward looking sense. I'm probably = convincible that a jurisdictional areas aren't needed, but so many of = the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. Brian On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: > On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >> For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? >=20 >=20 > In CAP the recommended presentation would be a polygon, a line of text = that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >=20 > There are a few subtleties here. First, most hazard footprints don't = align very well with political boundaries, so it's actually considered = best practice NOT to address an alert to everyone in a political = jurisdiction if better resolution is available, which increasingly often = is the case. (This is probably the biggest challenges in the transition = from the legacy EAS and Weather Radio systems in the States and the = newer CAP-based IPAWS framework.) >=20 > Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. =20 >=20 > In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >=20 > And third, of course, there's quite a bit of variety in how polygons = get represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between = the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >=20 > The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >=20 > And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >=20 > - Art > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 25 11:52:07 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213C11E8091 for ; Tue, 25 Sep 2012 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fhlBWUaMRxJ for ; Tue, 25 Sep 2012 11:52:06 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3635521F8830 for ; Tue, 25 Sep 2012 11:52:06 -0700 (PDT) Received: by padfb11 with SMTP id fb11so2426550pad.31 for ; Tue, 25 Sep 2012 11:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ybmta5fCbCZcGy/1PeU1UQqcjZI1ICsCRJNt3Fnke54=; b=gG+OCpYLw7CYsE53lYmUPPyKc1ftUM9E83mYT2JyEzxxfj4kxiSUQU3GqXrurKwWTN rfNTHbFvYawdhKcozb9pHkFqMx4FnnDGt3p+AED2vQWoCx9SrEzDVYfaUeLIWYs3qPaV 4mKMnRmUs9qp74dY6S9P7DxOuk4uVYi0KRPIQHa1bGzfOamlRNswj/PjNqU255cXOuP2 Uzpo42SbORpDuJr9L1iCHhghIM7MG/h+fm2rekrksGw8lsKxALhW9GUzZXyezI2IDlFR BFyZDi2uMDDKJsvPdy+yfTzu15uVdtj4z93Yilo1HVIVnM/6BjMiihMouhjIHcfew78d fSEQ== Received: by 10.68.203.195 with SMTP id ks3mr48388280pbc.79.1348599125937; Tue, 25 Sep 2012 11:52:05 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id qb2sm715623pbb.15.2012.09.25.11.52.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 11:52:02 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: Date: Tue, 25 Sep 2012 11:51:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> To: Brian Rosen X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:52:07 -0000 Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. Yes, ultimately any geocode is really just a shorthand for some polygon. = Different jurisdictions around the world will have different geocoding = schemes, and it's hard to assume that every receiving device will be = familiar with them all... but geometry is universal... or at least = planet-wide. - Art On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: > I guess that's my point. Without more spec, we have interoperability = issues. When you have limited CAP deployment, these can be dealt with = by prior arrangement. We probably can't do that. I would prefer that a = polygon be encoded with GML, which is precise, interoperable and an = accepted global standard. That can be wrapped in a PIDF (an IETF = standard) or not, but we need something very interoperable. >=20 > Forcing polygons may work in a forward looking sense. I'm probably = convincible that a jurisdictional areas aren't needed, but so many of = the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >=20 > Brian >=20 >=20 > On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: >=20 >> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>> For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? >>=20 >>=20 >> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>=20 >> There are a few subtleties here. First, most hazard footprints don't = align very well with political boundaries, so it's actually considered = best practice NOT to address an alert to everyone in a political = jurisdiction if better resolution is available, which increasingly often = is the case. (This is probably the biggest challenges in the transition = from the legacy EAS and Weather Radio systems in the States and the = newer CAP-based IPAWS framework.) >>=20 >> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. =20 >>=20 >> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>=20 >> And third, of course, there's quite a bit of variety in how polygons = get represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between = the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>=20 >> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>=20 >> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>=20 >> - Art >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From mark.wood@engineer.com Tue Sep 25 12:17:55 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94521F87E7 for ; Tue, 25 Sep 2012 12:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5p5vb9uGwAb for ; Tue, 25 Sep 2012 12:17:54 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBB21F84CE for ; Tue, 25 Sep 2012 12:17:47 -0700 (PDT) X-Trace: 616517013/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4KAJkCYlBRVitW/2dsb2JhbABFvVUBA4EMgQmCIAEBAQMBAQEBBTIcCAgIEAcBBAEGAxEEAQEBCR4gDgwGDQkIAQEEEwuHdAoHl3CQfpBqix4UASgyhE6BBQONaIQUOYh/iH6BXIJogVkB X-IronPort-AV: E=Sophos;i="4.80,485,1344207600"; d="scan'208";a="616517013" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Sep 2012 20:17:41 +0100 From: "Mark Wood" Sender: "Mark" To: In-Reply-To: <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> Date: Tue, 25 Sep 2012 20:17:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac2bTt9R2Tt5p+4DQ+2IWifkuzboJAAAf1cA X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120925191748.29FBB21F84CE@ietfa.amsl.com> Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:17:55 -0000 Hi Guys, I agree that sticking to a polygon description is best, and that the WGS84 protocol as used in CAP is most appropriate. This is because while the USA does indeed have FIPS codes to tag political polygons as 'geocodes', many countries do not, will not, or have completely different methods of geocoding political polygons. For example Canada has been creating its own interpretation of CAP, in which the FIPS codes and SAME codes are not at all the same, but the WGS84 seems to be universal. I have not so far spoken to any client other than the USA that will adopt FIPS, but I have not spoken to any that will not use WGS84. Actually the only component that really needs to translate from FIPS to WGS84 is the Aggregator/Gateway system. This is because it needs to apply policy to the proposed message on the basis of sovereignty of the territory under the polygon. This in turn is politically based, so the gateway needs to be able to parse a polygon into its underlying political geocodes to police the applicable policy. If you don't do this, then you are restricted to producing polygons only within certain geocodes that have allowed the sender to transmit. Administering this would become very clumsy! However assuming the gateway has done this, any systems upstream (data input) or downstream (participating networks of any sort), don't need to have any awareness of 'political' geocodes. Therefore provided that there is an approved gateway, only WGS84 is actually needed. Remember that the only operational CAP model at the moment is the USA version, but that this will very soon change as other counties adopt their own variation of CAP. Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Art Botterell Sent: 25 September 2012 19:52 To: Brian Rosen Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone Funny thing, that... we tried to make the CAP geometries align with GML... even has a representative from OGC (Carl Reed) on the OASIS committee when we were' specifying it... but then GML changed directions and the CAP spec wound up different. Personally I'd suggest using the CAP syntax, for consistency, as that can be switched into GML, KML or whatever easily and precisely an application requires. Yes, ultimately any geocode is really just a shorthand for some polygon. Different jurisdictions around the world will have different geocoding schemes, and it's hard to assume that every receiving device will be familiar with them all... but geometry is universal... or at least planet-wide. - Art On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: > I guess that's my point. Without more spec, we have interoperability issues. When you have limited CAP deployment, these can be dealt with by prior arrangement. We probably can't do that. I would prefer that a polygon be encoded with GML, which is precise, interoperable and an accepted global standard. That can be wrapped in a PIDF (an IETF standard) or not, but we need something very interoperable. > > Forcing polygons may work in a forward looking sense. I'm probably convincible that a jurisdictional areas aren't needed, but so many of the alert sources I'm interested in supporting are based on jurisdictions. I guess just telling them they need to come up with a relatively simple polygon is okay. Since increasingly, device location is GPS (or equivalent) based, we probably need geo always. > > Brian > > > On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: > >> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>> For example, how do you target "Allegheny County, PA, US"? A text line? With what syntax? A polygon? >> >> >> In CAP the recommended presentation would be a polygon, a line of text that might well read "Allegheny County, PA, US" and optionally a value, which in the US would typically be a FIPS-based code conforming to the old Emergency Alert System standard (in this case, "042003"). >> >> There are a few subtleties here. First, most hazard footprints don't align very well with political boundaries, so it's actually considered best practice NOT to address an alert to everyone in a political jurisdiction if better resolution is available, which increasingly often is the case. (This is probably the biggest challenges in the transition from the legacy EAS and Weather Radio systems in the States and the newer CAP-based IPAWS framework.) >> >> Second, but related to the first... there is at present no strict limit on the number of vertices in a polygon in CAP. Generally this hasn't been a problem, as both manual and model-derived (e.g., from a hazardous materials "plume model" software) polygons tend to be relatively simple. However, if one uses a political jurisdiction as the target area and if, as often is the case, that jurisdiction is defined at least in part by a waterway or water body, then at least part of the "true" polygon will be fractal in nature and the number of vertices used to represent it becomes an implementation decision. >> >> In such cases conversion from GIS geometries developed for other purposes can, at least in theory, produce very lengthy polygon description strings. Some degree of polygon simplification, manually or by means of a "convex hull" calculation, may be helpful in such situations; fortunately those can be calculated ahead of time. A common guideline and a requirement of the IPAWS profile in the U.S. is that a polygon be limited to 100 vertices. Again, this is largely a theoretical concern, and I'm not aware of any case where this has actually been a problem. >> >> And third, of course, there's quite a bit of variety in how polygons get represented as strings. Latitude first and then longitude, or the reverse "x,y" order? Commas between the coordinates and spaces between the pairs, or vice versa, or some other delimiters? All such representations are ultimately equivalent (at least until we drill down to the level of whether we're using the increasingly common GPS-standard WGS84 datum or some model of the precise shape of the Earth.) But it's important to be clear which format is being used and to remember of convert as necessary, e.g., between CAP and KML. >> >> The CAP spec deprecates the use of geocodes (arbitrary string designators) without also providing the corresponding geometry (polygon), since to do otherwise is to assume that the receiving device knows every possible geocoding scheme it might ever encounter, which in an open global system is probably infeasible. Indeed, ideally we might have done without geocodes entirely, but back-compatibility with legacy systems (and the comfort of some non-GIS-savvy programmers who understood string-matching but were uncomfortable with things like point-in-polygon algorithms) dictated their inclusion. >> >> And the text areaDescription field is defined merely as "human readable" so it can be as concise or as extensive as circumstances dictate. However, where multi-lingual alerting is required it tends to be kept short to facilitate translation. >> >> - Art >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From creed@opengeospatial.org Tue Sep 25 12:31:14 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043FA21F897D for ; Tue, 25 Sep 2012 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SARE_FWDLOOK=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb-aI7JEecVG for ; Tue, 25 Sep 2012 12:31:13 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3170421F8979 for ; Tue, 25 Sep 2012 12:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 471C99416A; Tue, 25 Sep 2012 15:31:12 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGqOJeuZ8orE; Tue, 25 Sep 2012 15:31:11 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 0BC049413D; Tue, 25 Sep 2012 15:31:10 -0400 (EDT) Message-ID: From: "Carl Reed" To: "Art Botterell" , "Brian Rosen" References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> In-Reply-To: <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> Date: Tue, 25 Sep 2012 13:28:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:31:14 -0000 Art GML changed directions? Not sure what you mean. There is now an OASIS GML profile for use in OASIS EM standards. Being referenced in HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) Cheers Carl -----Original Message----- From: Art Botterell Sent: Tuesday, September 25, 2012 12:51 PM To: Brian Rosen Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone Funny thing, that... we tried to make the CAP geometries align with GML... even has a representative from OGC (Carl Reed) on the OASIS committee when we were' specifying it... but then GML changed directions and the CAP spec wound up different. Personally I'd suggest using the CAP syntax, for consistency, as that can be switched into GML, KML or whatever easily and precisely an application requires. Yes, ultimately any geocode is really just a shorthand for some polygon. Different jurisdictions around the world will have different geocoding schemes, and it's hard to assume that every receiving device will be familiar with them all... but geometry is universal... or at least planet-wide. - Art On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: > I guess that's my point. Without more spec, we have interoperability > issues. When you have limited CAP deployment, these can be dealt with by > prior arrangement. We probably can't do that. I would prefer that a > polygon be encoded with GML, which is precise, interoperable and an > accepted global standard. That can be wrapped in a PIDF (an IETF > standard) or not, but we need something very interoperable. > > Forcing polygons may work in a forward looking sense. I'm probably > convincible that a jurisdictional areas aren't needed, but so many of the > alert sources I'm interested in supporting are based on jurisdictions. I > guess just telling them they need to come up with a relatively simple > polygon is okay. Since increasingly, device location is GPS (or > equivalent) based, we probably need geo always. > > Brian > > > On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: > >> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>> For example, how do you target "Allegheny County, PA, US"? A text line? >>> With what syntax? A polygon? >> >> >> In CAP the recommended presentation would be a polygon, a line of text >> that might well read "Allegheny County, PA, US" and optionally a >> value, which in the US would typically be a FIPS-based code >> conforming to the old Emergency Alert System standard (in this case, >> "042003"). >> >> There are a few subtleties here. First, most hazard footprints don't >> align very well with political boundaries, so it's actually considered >> best practice NOT to address an alert to everyone in a political >> jurisdiction if better resolution is available, which increasingly often >> is the case. (This is probably the biggest challenges in the transition >> from the legacy EAS and Weather Radio systems in the States and the newer >> CAP-based IPAWS framework.) >> >> Second, but related to the first... there is at present no strict limit >> on the number of vertices in a polygon in CAP. Generally this hasn't >> been a problem, as both manual and model-derived (e.g., from a hazardous >> materials "plume model" software) polygons tend to be relatively simple. >> However, if one uses a political jurisdiction as the target area and if, >> as often is the case, that jurisdiction is defined at least in part by a >> waterway or water body, then at least part of the "true" polygon will be >> fractal in nature and the number of vertices used to represent it becomes >> an implementation decision. >> >> In such cases conversion from GIS geometries developed for other purposes >> can, at least in theory, produce very lengthy polygon description >> strings. Some degree of polygon simplification, manually or by means of >> a "convex hull" calculation, may be helpful in such situations; >> fortunately those can be calculated ahead of time. A common guideline >> and a requirement of the IPAWS profile in the U.S. is that a polygon be >> limited to 100 vertices. Again, this is largely a theoretical concern, >> and I'm not aware of any case where this has actually been a problem. >> >> And third, of course, there's quite a bit of variety in how polygons get >> represented as strings. Latitude first and then longitude, or the >> reverse "x,y" order? Commas between the coordinates and spaces between >> the pairs, or vice versa, or some other delimiters? All such >> representations are ultimately equivalent (at least until we drill down >> to the level of whether we're using the increasingly common GPS-standard >> WGS84 datum or some model of the precise shape of the Earth.) But it's >> important to be clear which format is being used and to remember of >> convert as necessary, e.g., between CAP and KML. >> >> The CAP spec deprecates the use of geocodes (arbitrary string >> designators) without also providing the corresponding geometry (polygon), >> since to do otherwise is to assume that the receiving device knows every >> possible geocoding scheme it might ever encounter, which in an open >> global system is probably infeasible. Indeed, ideally we might have done >> without geocodes entirely, but back-compatibility with legacy systems >> (and the comfort of some non-GIS-savvy programmers who understood >> string-matching but were uncomfortable with things like point-in-polygon >> algorithms) dictated their inclusion. >> >> And the text areaDescription field is defined merely as "human readable" >> so it can be as concise or as extensive as circumstances dictate. >> However, where multi-lingual alerting is required it tends to be kept >> short to facilitate translation. >> >> - Art >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From creed@opengeospatial.org Tue Sep 25 12:31:14 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059B721F897E for ; Tue, 25 Sep 2012 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SARE_FWDLOOK=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqVupUVPGfO6 for ; Tue, 25 Sep 2012 12:31:13 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3173A21F897A for ; Tue, 25 Sep 2012 12:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 95DCE9413D; Tue, 25 Sep 2012 15:31:12 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbLiXs4ySrE6; Tue, 25 Sep 2012 15:31:11 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 8A04D9415F; Tue, 25 Sep 2012 15:31:11 -0400 (EDT) Message-ID: <57613BF6D8F244BE9B12221EB8F7029F@OfficeHP> From: "Carl Reed" To: "Brian Rosen" , "Art Botterell" References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> In-Reply-To: Date: Tue, 25 Sep 2012 13:31:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:31:14 -0000 Brian - Your observation WRT polygons and jurisdictions is one reason the Taiwanese went with GeoRSS and Open GeoSMS for their national debris flow alerting system. They needed to specify areas of interest, ranging from hydrological basins to city boundaries. They are hoping to use CAP in the future. Cheers Carl -----Original Message----- From: Brian Rosen Sent: Tuesday, September 25, 2012 12:25 PM To: Art Botterell Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone I guess that's my point. Without more spec, we have interoperability issues. When you have limited CAP deployment, these can be dealt with by prior arrangement. We probably can't do that. I would prefer that a polygon be encoded with GML, which is precise, interoperable and an accepted global standard. That can be wrapped in a PIDF (an IETF standard) or not, but we need something very interoperable. Forcing polygons may work in a forward looking sense. I'm probably convincible that a jurisdictional areas aren't needed, but so many of the alert sources I'm interested in supporting are based on jurisdictions. I guess just telling them they need to come up with a relatively simple polygon is okay. Since increasingly, device location is GPS (or equivalent) based, we probably need geo always. Brian On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: > On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >> For example, how do you target "Allegheny County, PA, US"? A text line? >> With what syntax? A polygon? > > > In CAP the recommended presentation would be a polygon, a line of text > that might well read "Allegheny County, PA, US" and optionally a > value, which in the US would typically be a FIPS-based code conforming to > the old Emergency Alert System standard (in this case, "042003"). > > There are a few subtleties here. First, most hazard footprints don't > align very well with political boundaries, so it's actually considered > best practice NOT to address an alert to everyone in a political > jurisdiction if better resolution is available, which increasingly often > is the case. (This is probably the biggest challenges in the transition > from the legacy EAS and Weather Radio systems in the States and the newer > CAP-based IPAWS framework.) > > Second, but related to the first... there is at present no strict limit on > the number of vertices in a polygon in CAP. Generally this hasn't been a > problem, as both manual and model-derived (e.g., from a hazardous > materials "plume model" software) polygons tend to be relatively simple. > However, if one uses a political jurisdiction as the target area and if, > as often is the case, that jurisdiction is defined at least in part by a > waterway or water body, then at least part of the "true" polygon will be > fractal in nature and the number of vertices used to represent it becomes > an implementation decision. > > In such cases conversion from GIS geometries developed for other purposes > can, at least in theory, produce very lengthy polygon description strings. > Some degree of polygon simplification, manually or by means of a "convex > hull" calculation, may be helpful in such situations; fortunately those > can be calculated ahead of time. A common guideline and a requirement of > the IPAWS profile in the U.S. is that a polygon be limited to 100 > vertices. Again, this is largely a theoretical concern, and I'm not aware > of any case where this has actually been a problem. > > And third, of course, there's quite a bit of variety in how polygons get > represented as strings. Latitude first and then longitude, or the reverse > "x,y" order? Commas between the coordinates and spaces between the pairs, > or vice versa, or some other delimiters? All such representations are > ultimately equivalent (at least until we drill down to the level of > whether we're using the increasingly common GPS-standard WGS84 datum or > some model of the precise shape of the Earth.) But it's important to be > clear which format is being used and to remember of convert as necessary, > e.g., between CAP and KML. > > The CAP spec deprecates the use of geocodes (arbitrary string designators) > without also providing the corresponding geometry (polygon), since to do > otherwise is to assume that the receiving device knows every possible > geocoding scheme it might ever encounter, which in an open global system > is probably infeasible. Indeed, ideally we might have done without > geocodes entirely, but back-compatibility with legacy systems (and the > comfort of some non-GIS-savvy programmers who understood string-matching > but were uncomfortable with things like point-in-polygon algorithms) > dictated their inclusion. > > And the text areaDescription field is defined merely as "human readable" > so it can be as concise or as extensive as circumstances dictate. > However, where multi-lingual alerting is required it tends to be kept > short to facilitate translation. > > - Art > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Tue Sep 25 12:57:02 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608D71F0CD9 for ; Tue, 25 Sep 2012 12:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.237 X-Spam-Level: X-Spam-Status: No, score=-100.237 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deeJOeNNSYdH for ; Tue, 25 Sep 2012 12:57:01 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9841F0CD7 for ; Tue, 25 Sep 2012 12:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=5fpV+NOfC26SnUgkGlvY+O++pJP+PyGU9XrReGAF5p4=; b=s+Q40JDqeQwrBWmwXfgm084j4m3jS+1XILCQGR14lw6XQ0et8pMsyL/zwTg5Y5ovdPS7Kcy7ofw/wuV0+7hVXutuTW1QKtHUb2JQ2JM96bdASisa84kAZV8D0CX7Q/PH; Received: from neustargw.va.neustar.com ([209.173.53.233]:12918 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGbFc-0003JO-6S; Tue, 25 Sep 2012 15:57:00 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 15:56:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <661BC1A8-6D0E-4B48-BCD3-195FE9BD8414@brianrosen.net> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> To: Carl Reed X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:57:02 -0000 We can always hope! Brian On Sep 25, 2012, at 3:28 PM, Carl Reed wrote: > Art >=20 > GML changed directions? Not sure what you mean. There is now an OASIS = GML profile for use in OASIS EM standards. Being referenced in HAVE, = xAL, and EDXL. Perhaps in the next version of CAP? :-) >=20 > Cheers >=20 > Carl >=20 >=20 > -----Original Message----- From: Art Botterell > Sent: Tuesday, September 25, 2012 12:51 PM > To: Brian Rosen > Cc: atoca@ietf.org > Subject: Re: [atoca] Next milestone >=20 > Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >=20 > Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >=20 > - Art >=20 >=20 > On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >=20 >> I guess that's my point. Without more spec, we have interoperability = issues. When you have limited CAP deployment, these can be dealt with = by prior arrangement. We probably can't do that. I would prefer that a = polygon be encoded with GML, which is precise, interoperable and an = accepted global standard. That can be wrapped in a PIDF (an IETF = standard) or not, but we need something very interoperable. >>=20 >> Forcing polygons may work in a forward looking sense. I'm probably = convincible that a jurisdictional areas aren't needed, but so many of = the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>=20 >> Brian >>=20 >>=20 >> On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: >>=20 >>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>> For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? >>>=20 >>>=20 >>> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>=20 >>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>=20 >>> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>=20 >>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>=20 >>> And third, of course, there's quite a bit of variety in how polygons = get represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between = the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>=20 >>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>=20 >>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>=20 >>> - Art >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca=20 From artbotterell@gmail.com Tue Sep 25 12:58:42 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E31F0CDB for ; Tue, 25 Sep 2012 12:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRKDNca5n5vV for ; Tue, 25 Sep 2012 12:58:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B91F0CD9 for ; Tue, 25 Sep 2012 12:58:42 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so665659pbb.31 for ; Tue, 25 Sep 2012 12:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=Ma/fXYsjlT8xH3yoGAwYRrQENCsDaBu21yRiNsskcfw=; b=Sc7GAe6EjzYb8g75BM9K045dSRkf45rVGqUKgAJBYW3dO6N5HpUsRiLavnJN1rgAvr oE8GzLG8aceKnOfq5QL56xJDcJpRM8DvwclkJJvZVAbZY6kxRc0Jgy2aSuB3674KMQB7 1owN26hCUAiL/3dN4QA/wR7HC6DbZBHmPU7qrDw9b18kbV+76WAbY8kvNqKhiaGXfoxe SztUBHBgHPzBgwdCHb0GP670vnympfbX2nITU8+w7ikT5JiCfLawN+M77bL5JG8miPp5 OECgrPwW0vN3TWnxIZdvjj6emsHk6aXtgw3/ArgQQtvo4UO706d5TJ7ZL7UtWX0e/RxR eXaA== Received: by 10.68.236.67 with SMTP id us3mr23181742pbc.28.1348603121956; Tue, 25 Sep 2012 12:58:41 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id gf3sm766267pbc.74.2012.09.25.12.58.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 12:58:40 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Art Botterell X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 12:58:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:58:43 -0000 Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 - Art On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: > Art >=20 > GML changed directions? Not sure what you mean. There is now an OASIS = GML profile for use in OASIS EM standards. Being referenced in HAVE, = xAL, and EDXL. Perhaps in the next version of CAP? :-) >=20 > Cheers >=20 > Carl >=20 >=20 > -----Original Message----- From: Art Botterell > Sent: Tuesday, September 25, 2012 12:51 PM > To: Brian Rosen > Cc: atoca@ietf.org > Subject: Re: [atoca] Next milestone >=20 > Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >=20 > Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >=20 > - Art >=20 >=20 > On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >=20 >> I guess that's my point. Without more spec, we have interoperability = issues. When you have limited CAP deployment, these can be dealt with = by prior arrangement. We probably can't do that. I would prefer that a = polygon be encoded with GML, which is precise, interoperable and an = accepted global standard. That can be wrapped in a PIDF (an IETF = standard) or not, but we need something very interoperable. >>=20 >> Forcing polygons may work in a forward looking sense. I'm probably = convincible that a jurisdictional areas aren't needed, but so many of = the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>=20 >> Brian >>=20 >>=20 >> On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: >>=20 >>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>> For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? >>>=20 >>>=20 >>> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>=20 >>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>=20 >>> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>=20 >>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>=20 >>> And third, of course, there's quite a bit of variety in how polygons = get represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between = the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>=20 >>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>=20 >>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>=20 >>> - Art >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca=20 From br@brianrosen.net Tue Sep 25 13:04:36 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2C41F0CE9 for ; Tue, 25 Sep 2012 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.993 X-Spam-Level: X-Spam-Status: No, score=-99.993 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1+BtzbdncAy for ; Tue, 25 Sep 2012 13:04:28 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 30C411F0CE6 for ; Tue, 25 Sep 2012 13:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=xWSmKRrC6Yib4HEAe2vZegIVfUo2i+rUiHGAuExywZA=; b=kAwVbaqD2csFbJsQ3P4Ff9P8jgBoRz8uGlTAYZ8DKSBZWS4+Pg8VxT2NpjsGQqJdLlLGrGob4t8llfgaTcOMaTucYoQTwlkIRroQJuC2q3wPpyAi5sdgWM2y0vGR8SwV; Received: from neustargw.va.neustar.com ([209.173.53.233]:14499 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGbMp-0004qm-6o; Tue, 25 Sep 2012 16:04:27 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 16:04:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:04:36 -0000 Right, but what do we do here? In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 What should we do? We need interoperability. We could try to profile = it so we get interoperability, and describe how that would be converted = to GML I suppose. Brian On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: > Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >=20 > - Art >=20 > On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >=20 >> Art >>=20 >> GML changed directions? Not sure what you mean. There is now an OASIS = GML profile for use in OASIS EM standards. Being referenced in HAVE, = xAL, and EDXL. Perhaps in the next version of CAP? :-) >>=20 >> Cheers >>=20 >> Carl >>=20 >>=20 >> -----Original Message----- From: Art Botterell >> Sent: Tuesday, September 25, 2012 12:51 PM >> To: Brian Rosen >> Cc: atoca@ietf.org >> Subject: Re: [atoca] Next milestone >>=20 >> Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>=20 >> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>=20 >> - Art >>=20 >>=20 >> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>=20 >>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>=20 >>> Forcing polygons may work in a forward looking sense. I'm probably = convincible that a jurisdictional areas aren't needed, but so many of = the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>=20 >>> Brian >>>=20 >>>=20 >>> On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: >>>=20 >>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>> For example, how do you target "Allegheny County, PA, US"? A text = line? With what syntax? A polygon? >>>>=20 >>>>=20 >>>> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>=20 >>>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>=20 >>>> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>=20 >>>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>=20 >>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>=20 >>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>=20 >>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>=20 >>>> - Art >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 25 13:15:43 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB71D1F0CB7 for ; Tue, 25 Sep 2012 13:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkFc0DCErPnZ for ; Tue, 25 Sep 2012 13:15:42 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5211F0417 for ; Tue, 25 Sep 2012 13:15:42 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so688591pbb.31 for ; Tue, 25 Sep 2012 13:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=K7HvJmLY2FmTT76f6WmqNLe2uamkPL0SGGl/ABo6eR8=; b=EHYH8RX+LiC8+B05aXG0nbUwU27HEKWEJZhYZ5CMR84p4lAY+7YjT8PFYf6CC9PAOh 7lXdaiUbGrbbi/ktu8vJK/QJrDqgUMVv2JsJK2Sg6x7n4eWidFw0HYYUZOs3/i6+lkaA ex7jwQYfXIWzmbkF/0OQHbCt2OoaNJT2en0zIf4YyhcYmVlkHAjXJbd1lmOV+dSGaMsq MAyjrqGJFJhJyGyFk2dlfgRJiFzFJrNyLGPiVUuYdKXCm9NS5BpAkG7WgaAng7ETpIjA Ju9P+ExH5oXtGKyT/dHBz1S5l0NYthcD/ahdUGa8A2dx+XW2rd9nWp81ISjfILdvl+Ph 7lhQ== Received: by 10.68.195.195 with SMTP id ig3mr49713262pbc.108.1348604142262; Tue, 25 Sep 2012 13:15:42 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id to6sm803247pbc.12.2012.09.25.13.15.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 13:15:41 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Art Botterell X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 13:15:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> To: Brian Rosen X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:15:43 -0000 Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. (And again, the underlying question is whether the world actually needs = yet another "wrapper" for alerts, considering that we already have both = SOAP and the OASIS EDXL-DE.) But I do have to question your assertion that the CAP format is either = "ill-defined" or "subject to interpretation." Have you actually read = the CAP spec? If so, what exactly do you mean? - Art On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: > Right, but what do we do here? >=20 > In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >=20 > What should we do? We need interoperability. We could try to profile = it so we get interoperability, and describe how that would be converted = to GML I suppose. >=20 > Brian >=20 > On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: >=20 >> Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>=20 >> - Art >>=20 >> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>=20 >>> Art >>>=20 >>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>=20 >>> Cheers >>>=20 >>> Carl >>>=20 >>>=20 >>> -----Original Message----- From: Art Botterell >>> Sent: Tuesday, September 25, 2012 12:51 PM >>> To: Brian Rosen >>> Cc: atoca@ietf.org >>> Subject: Re: [atoca] Next milestone >>>=20 >>> Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>=20 >>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>=20 >>> - Art >>>=20 >>>=20 >>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>=20 >>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>=20 >>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>=20 >>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>> For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? >>>>>=20 >>>>>=20 >>>>> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>>=20 >>>>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>=20 >>>>> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>=20 >>>>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>=20 >>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>=20 >>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>=20 >>>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>>=20 >>>>> - Art >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>=20 >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From br@brianrosen.net Tue Sep 25 13:33:34 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89621F8699 for ; Tue, 25 Sep 2012 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.818 X-Spam-Level: X-Spam-Status: No, score=-99.818 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCNtGPYoR-Ei for ; Tue, 25 Sep 2012 13:33:33 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id CA44921F8647 for ; Tue, 25 Sep 2012 13:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=KZWD12sZAklfiFiYmKnoqFxGIUAW4oEXEB2e7R3A9oU=; b=nAeuAgjy8RkcqqvNCP4AD/Qsn4AuFOnRFwatHL0kOwUm9HDfHM7ywKNgVWPud2e5BjpDxogtInBUGyJKY7rfrwtUC2C8ULCEI6uoE9U4g6icR6lu2+FgcD5CDbmS/636; Received: from neustargw.va.neustar.com ([209.173.53.233]:23097 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGbor-0001r2-Eh; Tue, 25 Sep 2012 16:33:25 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Brian Rosen X-Priority: 3 In-Reply-To: <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> Date: Tue, 25 Sep 2012 16:33:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:33:34 -0000 How are the pairs separated? What whitespace is acceptable? Is whitespace allowed between the coordinates, before or after the = comma? Stuff like that. Brian On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: > Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >=20 > (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >=20 > But I do have to question your assertion that the CAP format is either = "ill-defined" or "subject to interpretation." Have you actually read = the CAP spec? If so, what exactly do you mean? >=20 > - Art >=20 >=20 > On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >=20 >> Right, but what do we do here? >>=20 >> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >>=20 >> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>=20 >> Brian >>=20 >> On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: >>=20 >>> Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>>=20 >>> - Art >>>=20 >>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>=20 >>>> Art >>>>=20 >>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>=20 >>>> Cheers >>>>=20 >>>> Carl >>>>=20 >>>>=20 >>>> -----Original Message----- From: Art Botterell >>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>> To: Brian Rosen >>>> Cc: atoca@ietf.org >>>> Subject: Re: [atoca] Next milestone >>>>=20 >>>> Funny thing, that... we tried to make the CAP geometries align with = GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>=20 >>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>=20 >>>> - Art >>>>=20 >>>>=20 >>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>=20 >>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>=20 >>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>=20 >>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>> For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? >>>>>>=20 >>>>>>=20 >>>>>> In CAP the recommended presentation would be a polygon, a line of = text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>>>=20 >>>>>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>=20 >>>>>> Second, but related to the first... there is at present no strict = limit on the number of vertices in a polygon in CAP. Generally this = hasn't been a problem, as both manual and model-derived (e.g., from a = hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>=20 >>>>>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>=20 >>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>=20 >>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>=20 >>>>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>>>=20 >>>>>> - Art >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca=20 >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >=20 From artbotterell@gmail.com Tue Sep 25 13:36:27 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0649021F87CA for ; Tue, 25 Sep 2012 13:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+gxC7YwJl3P for ; Tue, 25 Sep 2012 13:36:26 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06821F86A0 for ; Tue, 25 Sep 2012 13:36:26 -0700 (PDT) Received: by padfb11 with SMTP id fb11so2489550pad.31 for ; Tue, 25 Sep 2012 13:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=gwBi3vxo2qeKBddFyn0ob4V75kSRlIyatw0I36gg5lM=; b=FCFZ9fh/vGFnioA6TSdn7CR9L9LUwxfITx22+WJvFn2XJjaI3CKsUOA00ph8DLZ4DU xL6KrHRrAG9KzLh6IXrecqP7TL3AEkMIDSsJX0LXyqKUDavp3k7CEwEUAkyBVNYOIfV2 udv5hsU+DATO4Yej3aDWVFvEh+VFwMkPpNZUjirVqmU7AMtYWkfFj1wg7yDGY08tzql1 Dpw7uXP+D9aeMjFGx5rd0ftCsSOhWag57O0EaXmozavnJV9FyXnRQgtE5sk3SE0d4DZG n/Pd35l7JJ588PMVnKon8XN+mbDP4KidXgnN9Idm6KAR24ANAyUgnxk7dIJmhCivaQtt LnRA== Received: by 10.66.78.195 with SMTP id d3mr43646838pax.17.1348605385821; Tue, 25 Sep 2012 13:36:25 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id gv1sm817769pbc.38.2012.09.25.13.36.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 13:36:24 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Art Botterell X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 13:36:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> To: Brian Rosen X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:36:27 -0000 Please, Brian, look at the spec before generalizing about it. All those = questions are precisely answered. The answers are different than those = for either GML or KML, but no less detailed. On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: > How are the pairs separated? > What whitespace is acceptable? > Is whitespace allowed between the coordinates, before or after the = comma? >=20 > Stuff like that. >=20 > Brian > On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: >=20 >> Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >>=20 >> (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >>=20 >> But I do have to question your assertion that the CAP format is = either "ill-defined" or "subject to interpretation." Have you actually = read the CAP spec? If so, what exactly do you mean? >>=20 >> - Art >>=20 >>=20 >> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>=20 >>> Right, but what do we do here? >>>=20 >>> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >>>=20 >>> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>>=20 >>> Brian >>>=20 >>> On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: >>>=20 >>>> Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>>>=20 >>>> - Art >>>>=20 >>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>=20 >>>>> Art >>>>>=20 >>>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>>=20 >>>>> Cheers >>>>>=20 >>>>> Carl >>>>>=20 >>>>>=20 >>>>> -----Original Message----- From: Art Botterell >>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>> To: Brian Rosen >>>>> Cc: atoca@ietf.org >>>>> Subject: Re: [atoca] Next milestone >>>>>=20 >>>>> Funny thing, that... we tried to make the CAP geometries align = with GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>>=20 >>>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>>=20 >>>>> - Art >>>>>=20 >>>>>=20 >>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>=20 >>>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>>=20 >>>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>>=20 >>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>> For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? >>>>>>>=20 >>>>>>>=20 >>>>>>> In CAP the recommended presentation would be a polygon, a line = of text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>>>>=20 >>>>>>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>>=20 >>>>>>> Second, but related to the first... there is at present no = strict limit on the number of vertices in a polygon in CAP. Generally = this hasn't been a problem, as both manual and model-derived (e.g., from = a hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>>=20 >>>>>>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>>=20 >>>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>>=20 >>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>>=20 >>>>>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>>>>=20 >>>>>>> - Art >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca=20 >>>>=20 >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>=20 >=20 From artbotterell@gmail.com Tue Sep 25 13:47:00 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6944F1F0CE0 for ; Tue, 25 Sep 2012 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bidfylbOGRED for ; Tue, 25 Sep 2012 13:46:59 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA40D1F0C67 for ; Tue, 25 Sep 2012 13:46:59 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so728967pbb.31 for ; Tue, 25 Sep 2012 13:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rFQZZsk8EuNwl9sPvR5Q5s45LaYYmjzCkyjJyBC3gGM=; b=tRwh1mXeO7HiCDJPRYzD0UNQ3F4O/2AOiAlzLb/hTFHCGCaHsrCz3D+utOyBup8rlu oRtDcmv2n36cZVjh7Zz1Jbvz3ZUtVJh4btUvTd/rXXnSYdA1jM92z8DytpRJL2V82m/9 XyDkSjpLWjhiIJmrwpurI3C4gEW2RqgR2gwOaWjZq23TdpuL3WwNakYHXVcGeaKwXcEU t5S+KIig004YtmabFSOKdzGglA0JNpDHIjvtNZ/Lm6tr0WjSogcpHNxEg8OvQ1NB57kL IiED9AKfdhiuwmKHag3vpZw7/2l4C9441AJcNAHjHmCqmmSP5yW0tLKJpo6WvW7vsuv2 Lmlg== Received: by 10.68.138.198 with SMTP id qs6mr29508802pbb.151.1348606019678; Tue, 25 Sep 2012 13:46:59 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id y11sm821872pbv.66.2012.09.25.13.46.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 13:46:56 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: <20120925191748.29FBB21F84CE@ietfa.amsl.com> Date: Tue, 25 Sep 2012 13:46:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <929000B5-1ED9-4C7E-B2F0-7CD83D3FC019@incident.com> References: <20120925191748.29FBB21F84CE@ietfa.amsl.com> To: "Mark Wood" X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:47:00 -0000 On Sep 25, 2012, at 12:17 PM, Mark Wood wrote: >=20 > Actually the only component that really needs to translate from FIPS = to > WGS84 is the Aggregator/Gateway system. This is because it needs to = apply > policy to the proposed message on the basis of sovereignty of the = territory > under the polygon.=20 This is another interesting and somewhat subtle point. To what = extent... and to what end... is it appropriate and/or necessary to = "clip" warning geometries to reflect political boundaries? I'd suggest = that that's a political consideration, not a technical necessity nor a = universal requirement. =46rom the perspective of public service it might actually be more = useful to convert the other way... given a hazard polygon, compute the = list of jurisdictions (in this case, U.S. counties represented as = FIPS-based strings) than the other way around. That could provide = support for legacy systems that can't target any more precisely than the = county level, and also provide notification of all jurisdictions touched = by an alert, even if the alert came from a different source (an = adjoining jurisdiction, say, or a national meteorological agency.) The arguments for limiting alerts to the originating jurisdiction strike = me as possibly less noble. Certainly government agencies tend to be = jealous and exclusive about their privileges, but hazards don't care. = And am I not entitled to prompt warning of a nearby hazard just because = there happens to be an administrative boundary in-between? Will the = county line protect me somehow? Indeed, mechanisms aimed at political turf protection were one of the = major sources of delay and warning failure in the 2004 Indian Ocean = tsunami. So... how to strike the balance between the privileges of authority and = those of citizenship? The answer is that it's not actually up to us = Different countries and different cultures will have different values = and legal frameworks. So we probably want to be cautious about trying = to instantiate any particular value system in technology. - Art From br@brianrosen.net Tue Sep 25 14:04:31 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D91F0424 for ; Tue, 25 Sep 2012 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.687 X-Spam-Level: X-Spam-Status: No, score=-99.687 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtQpSFTDgj2V for ; Tue, 25 Sep 2012 14:04:30 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 97C2521F8685 for ; Tue, 25 Sep 2012 14:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=J+tlDMbreYgX5D9J5cAcOubVsLCMC4BLOXPurcuFhe4=; b=VlknfFII2YZ4ocj0u4tTYNkZk0Q4RIUWa8XpWcoKQ/vvyeoUZKBgqLDJB9ncJjRgffTqhm8QUhNSwZhx9NzANAQVOcwdoDWpeNp1ggkyocb0IZleNaRmIB7cajvuysiq; Received: from neustargw.va.neustar.com ([209.173.53.233]:10286 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGcIv-0007gE-UW; Tue, 25 Sep 2012 17:04:30 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=windows-1252 From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 17:04:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:04:31 -0000 I did. All I see is: =95 The term =93coordinate pair=94 is used in this document to = refer to a comma-delimited pair of decimal values describing a = geospatial location in degrees, unprojected, in the form = =93[latitude],[longitude]=94. Latitudes in the Southern Hemisphere and = longitudes in the Western Hemisphere are signed negative by means of a = leading dash. and Code Values: The geographic polygon is represented by a = whitespace-delimited list of [WGS 84] coordinate pairs. (See WGS- 84 = Note at end of this section.) There is no definition of whitespace. There is no text specifying if = whitespace is permitted around the comma that delimits the coordinate = pairs. Brian On Sep 25, 2012, at 4:36 PM, Art Botterell wrote: > Please, Brian, look at the spec before generalizing about it. All = those questions are precisely answered. The answers are different than = those for either GML or KML, but no less detailed. >=20 >=20 > On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: >=20 >> How are the pairs separated? >> What whitespace is acceptable? >> Is whitespace allowed between the coordinates, before or after the = comma? >>=20 >> Stuff like that. >>=20 >> Brian >> On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: >>=20 >>> Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >>>=20 >>> (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >>>=20 >>> But I do have to question your assertion that the CAP format is = either "ill-defined" or "subject to interpretation." Have you actually = read the CAP spec? If so, what exactly do you mean? >>>=20 >>> - Art >>>=20 >>>=20 >>> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>>=20 >>>> Right, but what do we do here? >>>>=20 >>>> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >>>>=20 >>>> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 25, 2012, at 3:58 PM, Art Botterell = wrote: >>>>=20 >>>>> Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>>>>=20 >>>>> - Art >>>>>=20 >>>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>>=20 >>>>>> Art >>>>>>=20 >>>>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>>>=20 >>>>>> Cheers >>>>>>=20 >>>>>> Carl >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- From: Art Botterell >>>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>>> To: Brian Rosen >>>>>> Cc: atoca@ietf.org >>>>>> Subject: Re: [atoca] Next milestone >>>>>>=20 >>>>>> Funny thing, that... we tried to make the CAP geometries align = with GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>>>=20 >>>>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>>>=20 >>>>>> - Art >>>>>>=20 >>>>>>=20 >>>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>>=20 >>>>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>>>=20 >>>>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>>>=20 >>>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>>> For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> In CAP the recommended presentation would be a polygon, a line = of text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>>>>>=20 >>>>>>>> There are a few subtleties here. First, most hazard footprints = don't align very well with political boundaries, so it's actually = considered best practice NOT to address an alert to everyone in a = political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>>>=20 >>>>>>>> Second, but related to the first... there is at present no = strict limit on the number of vertices in a polygon in CAP. Generally = this hasn't been a problem, as both manual and model-derived (e.g., from = a hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>>>=20 >>>>>>>> In such cases conversion from GIS geometries developed for = other purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>>>=20 >>>>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>>>=20 >>>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>>>=20 >>>>>>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>>>>>=20 >>>>>>>> - Art >>>>>>>> _______________________________________________ >>>>>>>> atoca mailing list >>>>>>>> atoca@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca=20 >>>>>=20 >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>=20 >>>=20 >>=20 >=20 From creed@opengeospatial.org Tue Sep 25 14:23:21 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FEE21F869D for ; Tue, 25 Sep 2012 14:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SARE_FWDLOOK=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bsMt0hCnNSt for ; Tue, 25 Sep 2012 14:23:17 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5CB21F867A for ; Tue, 25 Sep 2012 14:23:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id D6D9994162; Tue, 25 Sep 2012 17:23:13 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OWSzY-dmwZ8; Tue, 25 Sep 2012 17:23:13 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 7619294141; Tue, 25 Sep 2012 17:23:12 -0400 (EDT) Message-ID: <3DF5430D69FC4F6A936F45A1F6805E08@OfficeHP> From: "Carl Reed" To: "Art Botterell" , "Brian Rosen" References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com><783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com><5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> In-Reply-To: Date: Tue, 25 Sep 2012 15:23:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:23:21 -0000 A side note. KML (formally Keyhole Markup Language) was originally defined as part of a contract Keyhole had with the EUSC. The EUSC suggested that keyhole look at GML 2.1.2, which they did. The underlying geometry model for KML and GML are the same. Both are based on ISO 19107 (as are many other geometry encoding patterns, such as GeoJSON and SQL-MM). Unfortunately, Keyhole decided to deviate in a few definitions, such as coordinate pairs are coded long-lat instead of lat-long (which is the geodetic tradition). They were trying to be consistent with some GIS technology back in the late 1990s - to bad. Should have followed the standards and not some vendor specific approach to defining polygons and coordinate strings. Anyway, if one looks at the definition of KML polygon: A Polygon is defined by an outer boundary and 0 or more inner boundaries. The boundaries, in turn, are defined by LinearRings. And LinearRings is also defined - identical to GML LinearRing. Apologies for deviating from the discussion. Cheers Carl -----Original Message----- From: Art Botterell Sent: Tuesday, September 25, 2012 2:36 PM To: Brian Rosen Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone Please, Brian, look at the spec before generalizing about it. All those questions are precisely answered. The answers are different than those for either GML or KML, but no less detailed. On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: > How are the pairs separated? > What whitespace is acceptable? > Is whitespace allowed between the coordinates, before or after the comma? > > Stuff like that. > > Brian > On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: > >> Personally I'd have no objection to using a simple GML-based >> representation, although that would mean that the "wrapper" would have a >> different serialization of a geometry than the enclosed CAP message, >> which some might find confusing or inconsistent even though the two would >> be semantically equivalent. >> >> (And again, the underlying question is whether the world actually needs >> yet another "wrapper" for alerts, considering that we already have both >> SOAP and the OASIS EDXL-DE.) >> >> But I do have to question your assertion that the CAP format is either >> "ill-defined" or "subject to interpretation." Have you actually read the >> CAP spec? If so, what exactly do you mean? >> >> - Art >> >> >> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >> >>> Right, but what do we do here? >>> >>> In general, in the IETF, we use GML. CAP doesn't, and has an >>> ill-defined, subject to interpretation, representation, as you said >>> below. >>> >>> What should we do? We need interoperability. We could try to profile >>> it so we get interoperability, and describe how that would be converted >>> to GML I suppose. >>> >>> Brian >>> >>> On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: >>> >>>> Dunno, Carl... certainly we were glad to have you there on the TC >>>> representing OGC... and yet somehow, despite all our best intentions, >>>> the coordinate order wound up reversed in CAP vs GML. And then, of >>>> course, KML came into play, different yet again. But >>>> standards-political history isn't the topic here. The practical point >>>> is that there are a variety of ways out there to say what's ultimately >>>> the exact same thing. >>>> >>>> - Art >>>> >>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>> >>>>> Art >>>>> >>>>> GML changed directions? Not sure what you mean. There is now an OASIS >>>>> GML profile for use in OASIS EM standards. Being referenced in HAVE, >>>>> xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>> >>>>> Cheers >>>>> >>>>> Carl >>>>> >>>>> >>>>> -----Original Message----- From: Art Botterell >>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>> To: Brian Rosen >>>>> Cc: atoca@ietf.org >>>>> Subject: Re: [atoca] Next milestone >>>>> >>>>> Funny thing, that... we tried to make the CAP geometries align with >>>>> GML... even has a representative from OGC (Carl Reed) on the OASIS >>>>> committee when we were' specifying it... but then GML changed >>>>> directions and the CAP spec wound up different. Personally I'd >>>>> suggest using the CAP syntax, for consistency, as that can be switched >>>>> into GML, KML or whatever easily and precisely an application >>>>> requires. >>>>> >>>>> Yes, ultimately any geocode is really just a shorthand for some >>>>> polygon. Different jurisdictions around the world will have different >>>>> geocoding schemes, and it's hard to assume that every receiving device >>>>> will be familiar with them all... but geometry is universal... or at >>>>> least planet-wide. >>>>> >>>>> - Art >>>>> >>>>> >>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>> >>>>>> I guess that's my point. Without more spec, we have interoperability >>>>>> issues. When you have limited CAP deployment, these can be dealt >>>>>> with by prior arrangement. We probably can't do that. I would >>>>>> prefer that a polygon be encoded with GML, which is precise, >>>>>> interoperable and an accepted global standard. That can be wrapped >>>>>> in a PIDF (an IETF standard) or not, but we need something very >>>>>> interoperable. >>>>>> >>>>>> Forcing polygons may work in a forward looking sense. I'm probably >>>>>> convincible that a jurisdictional areas aren't needed, but so many of >>>>>> the alert sources I'm interested in supporting are based on >>>>>> jurisdictions. I guess just telling them they need to come up with a >>>>>> relatively simple polygon is okay. Since increasingly, device >>>>>> location is GPS (or equivalent) based, we probably need geo always. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell wrote: >>>>>> >>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>> For example, how do you target "Allegheny County, PA, US"? A text >>>>>>>> line? With what syntax? A polygon? >>>>>>> >>>>>>> >>>>>>> In CAP the recommended presentation would be a polygon, a line of >>>>>>> text that might well read "Allegheny County, PA, US" and optionally >>>>>>> a value, which in the US would typically be a FIPS-based >>>>>>> code conforming to the old Emergency Alert System standard (in this >>>>>>> case, "042003"). >>>>>>> >>>>>>> There are a few subtleties here. First, most hazard footprints >>>>>>> don't align very well with political boundaries, so it's actually >>>>>>> considered best practice NOT to address an alert to everyone in a >>>>>>> political jurisdiction if better resolution is available, which >>>>>>> increasingly often is the case. (This is probably the biggest >>>>>>> challenges in the transition from the legacy EAS and Weather Radio >>>>>>> systems in the States and the newer CAP-based IPAWS framework.) >>>>>>> >>>>>>> Second, but related to the first... there is at present no strict >>>>>>> limit on the number of vertices in a polygon in CAP. Generally this >>>>>>> hasn't been a problem, as both manual and model-derived (e.g., from >>>>>>> a hazardous materials "plume model" software) polygons tend to be >>>>>>> relatively simple. However, if one uses a political jurisdiction as >>>>>>> the target area and if, as often is the case, that jurisdiction is >>>>>>> defined at least in part by a waterway or water body, then at least >>>>>>> part of the "true" polygon will be fractal in nature and the number >>>>>>> of vertices used to represent it becomes an implementation decision. >>>>>>> >>>>>>> In such cases conversion from GIS geometries developed for other >>>>>>> purposes can, at least in theory, produce very lengthy polygon >>>>>>> description strings. Some degree of polygon simplification, >>>>>>> manually or by means of a "convex hull" calculation, may be helpful >>>>>>> in such situations; fortunately those can be calculated ahead of >>>>>>> time. A common guideline and a requirement of the IPAWS profile in >>>>>>> the U.S. is that a polygon be limited to 100 vertices. Again, this >>>>>>> is largely a theoretical concern, and I'm not aware of any case >>>>>>> where this has actually been a problem. >>>>>>> >>>>>>> And third, of course, there's quite a bit of variety in how polygons >>>>>>> get represented as strings. Latitude first and then longitude, or >>>>>>> the reverse "x,y" order? Commas between the coordinates and spaces >>>>>>> between the pairs, or vice versa, or some other delimiters? All >>>>>>> such representations are ultimately equivalent (at least until we >>>>>>> drill down to the level of whether we're using the increasingly >>>>>>> common GPS-standard WGS84 datum or some model of the precise shape >>>>>>> of the Earth.) But it's important to be clear which format is being >>>>>>> used and to remember of convert as necessary, e.g., between CAP and >>>>>>> KML. >>>>>>> >>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string >>>>>>> designators) without also providing the corresponding geometry >>>>>>> (polygon), since to do otherwise is to assume that the receiving >>>>>>> device knows every possible geocoding scheme it might ever >>>>>>> encounter, which in an open global system is probably infeasible. >>>>>>> Indeed, ideally we might have done without geocodes entirely, but >>>>>>> back-compatibility with legacy systems (and the comfort of some >>>>>>> non-GIS-savvy programmers who understood string-matching but were >>>>>>> uncomfortable with things like point-in-polygon algorithms) dictated >>>>>>> their inclusion. >>>>>>> >>>>>>> And the text areaDescription field is defined merely as "human >>>>>>> readable" so it can be as concise or as extensive as circumstances >>>>>>> dictate. However, where multi-lingual alerting is required it tends >>>>>>> to be kept short to facilitate translation. >>>>>>> >>>>>>> - Art >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>> >>>>> >>>>> _______________________________________________ >>>>> atoca mailing list >>>>> atoca@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/atoca >>>> >>>> _______________________________________________ >>>> atoca mailing list >>>> atoca@ietf.org >>>> https://www.ietf.org/mailman/listinfo/atoca >>> >> > _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From mark.wood@engineer.com Tue Sep 25 14:28:35 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316B321F85A1 for ; Tue, 25 Sep 2012 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc5TAzYw2pS1 for ; Tue, 25 Sep 2012 14:28:34 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE6021F8472 for ; Tue, 25 Sep 2012 14:28:33 -0700 (PDT) X-Trace: 559583425/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KAMggYlBRVitW/2dsb2JhbABFvVQBA4EMgQmCIAEBAQQBAQEFBiwcCAcBAgYXAQQBBgMRBAEBAQkMEiAODAYNCQgBAQQTCwkBh3QHl26QfpBcix49MoIngieBBQONaI1MiH6BXIJo X-IronPort-AV: E=Sophos;i="4.80,485,1344207600"; d="scan'208";a="559583425" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Sep 2012 22:28:26 +0100 From: "Mark Wood" Sender: "Mark" To: In-Reply-To: <929000B5-1ED9-4C7E-B2F0-7CD83D3FC019@incident.com> Date: Tue, 25 Sep 2012 22:28:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac2bXwavI7ChTFLcS8SP/iPVQtenoQAAJzsQ X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120925212833.DDE6021F8472@ietfa.amsl.com> Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:28:35 -0000 (FYI my current information is that FEMA IPAWS uses SOAP wrapper to encapsulate CAP). Yes, art is correct. The problem is that the politicians hold the 'sovereignty', not the emergency management community (the originators of messages), nor the participating distribution network, (such as the cellular networks). Now if you want to say "its raining quite a lot actually", well no problem, but if you want to say "leave your home and go to high ground now", this is completely different and only a properly authorised agent of the sovereign state may lawfully do that. If an originator sends a command to another territory, no matter how well meaning, diplomatic storms will result. The 'BBC World Service' has got in a lot of 'hot water' over this despite honest intentions. The decision as to if a polygon should be clipped, parsed, expanded or in any other way modified will be taken well in advance by the 'Trust Protocol Board', or equivalent (hopefully) after consultation between stakeholders, and their decision coded into the gateway for automatic enforcement. Cellcast gateways for example are designed to handle any such cases if the MoA demands it, (though it's not mandatory). And yes, I hope that mutual agreements will emerge in which messages originated in one territory will be permitted in another, subject to terms and conditions of the sovereignty targeted by the polygon. We have accounted for any such possibility. It's possible for an originator to have multiple permitted polygons even if they are completely non contiguous, or have funny holes in them. Gateways can share traffic between them so that messages will be delivered everywhere that they are allowed. Added to this is the issue that many networks are administered from outside the territory, for example the mobile switches for some Caribbean islands are actually on other islands under a different government. No matter, this is why the filtration must account for any differences in policy before handing the submission over to the network so that the correct policy is followed. But even then, neither the originators of the messages nor the participating networks have national sovereignty; each is only able to do what the laws of the state concerned allow. Therefore if an agency creates a warning polygon covering a large number of islands, all of which are separately sovereign, then the sovereignty of those states needs to be respected. It's the respective governments who will decide who can say what, where, when and how, which is why all orders to the public will have to pass through the government gateway, (as opposed to any technological benefits). So as to what extent it is "appropriate' to clip polygons", is defined in the trust protocol for that territory, there is no real moral dilemma here as far as the originator of the message is concerned, for the eventual fate of the message downstream is out of his hands. Any 'doctoring' of the polygon or the contents (such as language) will have occurred before the network even gets it. I share Art's concerns about all of this and I am trying to start a meaningful dialogue about these issues in advance, but at the moment it seems that we will have to wait for the first few actual national trust protocols to be created, then have a review of "best practices" after the event. However the first international conference about this has already occurred, (OASIS/ITU Montreal) with the USA and Canada determined to hash out a workable policy on all of this which I rather admire. I am open to suggestions as to the most appropriate forum for this discussion. Warm regards Mark Wood. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Art Botterell Sent: 25 September 2012 21:47 To: Mark Wood Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone On Sep 25, 2012, at 12:17 PM, Mark Wood wrote: > > Actually the only component that really needs to translate from FIPS to > WGS84 is the Aggregator/Gateway system. This is because it needs to apply > policy to the proposed message on the basis of sovereignty of the territory > under the polygon. This is another interesting and somewhat subtle point. To what extent... and to what end... is it appropriate and/or necessary to "clip" warning geometries to reflect political boundaries? I'd suggest that that's a political consideration, not a technical necessity nor a universal requirement. >From the perspective of public service it might actually be more useful to convert the other way... given a hazard polygon, compute the list of jurisdictions (in this case, U.S. counties represented as FIPS-based strings) than the other way around. That could provide support for legacy systems that can't target any more precisely than the county level, and also provide notification of all jurisdictions touched by an alert, even if the alert came from a different source (an adjoining jurisdiction, say, or a national meteorological agency.) The arguments for limiting alerts to the originating jurisdiction strike me as possibly less noble. Certainly government agencies tend to be jealous and exclusive about their privileges, but hazards don't care. And am I not entitled to prompt warning of a nearby hazard just because there happens to be an administrative boundary in-between? Will the county line protect me somehow? Indeed, mechanisms aimed at political turf protection were one of the major sources of delay and warning failure in the 2004 Indian Ocean tsunami. So... how to strike the balance between the privileges of authority and those of citizenship? The answer is that it's not actually up to us Different countries and different cultures will have different values and legal frameworks. So we probably want to be cautious about trying to instantiate any particular value system in technology. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Tue Sep 25 14:29:50 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84021F867A for ; Tue, 25 Sep 2012 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jao7qKrIvybW for ; Tue, 25 Sep 2012 14:29:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68C21F85A1 for ; Tue, 25 Sep 2012 14:29:49 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so779632pbb.31 for ; Tue, 25 Sep 2012 14:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Oq9q8D2SVjSAkCGnYuRaLmrlS6Yf+HhpqvbqW1eGPHg=; b=sOVqJjZ010gENM2Z+2pNAEItJX+Ou9gbDBjugyu8CBUkit1fRMJk0Lb3IY5Jtb2Qc/ BdXS3Adv/B+i1wbo8MGKc4He7DLArQQZgexxXWkNPhktVlOEGM+UHaTR8bDsfIawZHTy 5zckYT8Us6fQJMnYy/sq6r9d9LzyW2K6SQY4bwZLKG2VGniItxx/1W3DbYZN+8M+iD8h w5OZEDRbcelSEveKX8813trKJRWv/k8qIejG1rzLmGpYsUPYj/GXJ1cklWXXP5pAftQE f7bSqtgivwpejWz7oD+W99o0Rbu9ENMTSH/JlccD7QdedvOaoEzqPOGi66NbcHIxCEA7 zIEw== Received: by 10.68.138.163 with SMTP id qr3mr49212897pbb.161.1348608588611; Tue, 25 Sep 2012 14:29:48 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id bt7sm710560pab.14.2012.09.25.14.29.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 14:29:47 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Art Botterell X-Priority: 3 In-Reply-To: <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> Date: Tue, 25 Sep 2012 14:29:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:29:50 -0000 White space is defined in the W3C XML 1.0 specification (which is = referenced as normative in the CAP spec) as "spaces, tabs, and blank = lines." And the form =93[latitude],[longitude]=94 seems fairly unambiguous, = particularly since white space is specified as the delimiter between = pairs. =20 Also there are a number of examples provided in the CAP document that, = while non-normative, were put there to help resolve any lingering = ambiguity. - Art On Sep 25, 2012, at 2:04 PM, Brian Rosen wrote: > I did. All I see is: > =95 The term =93coordinate pair=94 is used in this document to = refer to a comma-delimited pair of decimal values describing a = geospatial location in degrees, unprojected, in the form = =93[latitude],[longitude]=94. Latitudes in the Southern Hemisphere and = longitudes in the Western Hemisphere are signed negative by means of a = leading dash. >=20 > and > Code Values: The geographic polygon is represented by a = whitespace-delimited list of [WGS 84] coordinate pairs. (See WGS- 84 = Note at end of this section.) >=20 >=20 > There is no definition of whitespace. There is no text specifying if = whitespace is permitted around the comma that delimits the coordinate = pairs. >=20 > Brian >=20 > On Sep 25, 2012, at 4:36 PM, Art Botterell wrote: >=20 >> Please, Brian, look at the spec before generalizing about it. All = those questions are precisely answered. The answers are different than = those for either GML or KML, but no less detailed. >>=20 >>=20 >> On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: >>=20 >>> How are the pairs separated? >>> What whitespace is acceptable? >>> Is whitespace allowed between the coordinates, before or after the = comma? >>>=20 >>> Stuff like that. >>>=20 >>> Brian >>> On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: >>>=20 >>>> Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >>>>=20 >>>> (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >>>>=20 >>>> But I do have to question your assertion that the CAP format is = either "ill-defined" or "subject to interpretation." Have you actually = read the CAP spec? If so, what exactly do you mean? >>>>=20 >>>> - Art >>>>=20 >>>>=20 >>>> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>>>=20 >>>>> Right, but what do we do here? >>>>>=20 >>>>> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >>>>>=20 >>>>> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Sep 25, 2012, at 3:58 PM, Art Botterell = wrote: >>>>>=20 >>>>>> Dunno, Carl... certainly we were glad to have you there on the TC = representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>>>>>=20 >>>>>> - Art >>>>>>=20 >>>>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>>>=20 >>>>>>> Art >>>>>>>=20 >>>>>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>>>>=20 >>>>>>> Cheers >>>>>>>=20 >>>>>>> Carl >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- From: Art Botterell >>>>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>>>> To: Brian Rosen >>>>>>> Cc: atoca@ietf.org >>>>>>> Subject: Re: [atoca] Next milestone >>>>>>>=20 >>>>>>> Funny thing, that... we tried to make the CAP geometries align = with GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>>>>=20 >>>>>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>>>>=20 >>>>>>> - Art >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>>>=20 >>>>>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>>>>=20 >>>>>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>>>>=20 >>>>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>>>> For example, how do you target "Allegheny County, PA, US"? A = text line? With what syntax? A polygon? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In CAP the recommended presentation would be a polygon, a line = of text that might well read "Allegheny County, PA, US" and optionally a = value, which in the US would typically be a FIPS-based code = conforming to the old Emergency Alert System standard (in this case, = "042003"). >>>>>>>>>=20 >>>>>>>>> There are a few subtleties here. First, most hazard = footprints don't align very well with political boundaries, so it's = actually considered best practice NOT to address an alert to everyone in = a political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>>>>=20 >>>>>>>>> Second, but related to the first... there is at present no = strict limit on the number of vertices in a polygon in CAP. Generally = this hasn't been a problem, as both manual and model-derived (e.g., from = a hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>>>>=20 >>>>>>>>> In such cases conversion from GIS geometries developed for = other purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>>>>=20 >>>>>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>>>>=20 >>>>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>>>>=20 >>>>>>>>> And the text areaDescription field is defined merely as "human = readable" so it can be as concise or as extensive as circumstances = dictate. However, where multi-lingual alerting is required it tends to = be kept short to facilitate translation. >>>>>>>>>=20 >>>>>>>>> - Art >>>>>>>>> _______________________________________________ >>>>>>>>> atoca mailing list >>>>>>>>> atoca@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From artbotterell@gmail.com Tue Sep 25 14:42:20 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F191F0425 for ; Tue, 25 Sep 2012 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO-416A2MroF for ; Tue, 25 Sep 2012 14:42:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B76681F041E for ; Tue, 25 Sep 2012 14:42:19 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so794517pbb.31 for ; Tue, 25 Sep 2012 14:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UbnJqDmi39f+vir0ZRgtI4JBZJyOy2zTYaVPj2Vxbbc=; b=wwllAy6lew1THqd/8eLC80T9mTgRqQt1t7pyXVOt5TFkRqaOoLVpDNvPabhEsXC3CY M3cjNgcDZ7CjLCFSl21LrCJl/ponqAcP+7E0ahXhbAPYf2jLMZd9sMEdIPsMHY4k+C30 hJmfAYguwjt9GbiLsumZOyLnpba9FTZPPl2sNQJSZlDmXcj96HinFy+CV0IDf/5NHiRF 1iHwTkEK0oJSP6dgF9Q75Y7HVuDYrD5FFEG98quEA5u0rVfTzERExVXXeZeDtd0rzygk S89/PspudO9tDsn+wKvYfcpOfJWoAtQsU4yMzhQ2In+wseHZV1flFqRw9ZtVDSb0kxGC MdqQ== Received: by 10.68.242.164 with SMTP id wr4mr49864961pbc.41.1348609339565; Tue, 25 Sep 2012 14:42:19 -0700 (PDT) Received: from [192.168.1.69] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id y2sm714660pax.29.2012.09.25.14.42.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 14:42:18 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: <20120925212833.DDE6021F8472@ietfa.amsl.com> Date: Tue, 25 Sep 2012 14:42:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63294164-DEC1-4C6D-8B5C-27697D0F118A@incident.com> References: <20120925212833.DDE6021F8472@ietfa.amsl.com> To: "Mark Wood" X-Mailer: Apple Mail (2.1283) Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:42:20 -0000 On Sep 25, 2012, at 2:28 PM, Mark Wood wrote: > ...but if you want to say "leave your home and go to high ground now", = this is > completely different and only a properly authorised agent of the = sovereign > state may lawfully do that. Well, not everywhere, Here in the U.S. anyone may say that... and may = be held accountable for the results afterwards. (Which accountability = can be so dire that folks generally hesitate before taking the risk, so = the end effect is essentially the same, but arguably with a bit more = flexibility for extreme circumstances.) But that does vary from place to place. As John Perry Barlow once = reminded Americans, "the First Amendment is a local ordinance." So... is it permissible to shout "fire!" in a burning theater? Yes, but = perhaps not in a burning theatre! By which spelling variation I mean to = suggest that in different places this question is subject to different = laws and different notions both of sovereignty and of individual (and/or = corporate) duty. - Art From br@brianrosen.net Tue Sep 25 14:51:34 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B80A21F87A8 for ; Tue, 25 Sep 2012 14:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.586 X-Spam-Level: X-Spam-Status: No, score=-99.586 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOqeC2V7HX2i for ; Tue, 25 Sep 2012 14:51:29 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id B917421F86D4 for ; Tue, 25 Sep 2012 14:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=oJoKcVTrRLBzZRzFce1rLnPB37W35OiINDM3zZN6hSg=; b=XPoaKAZATd0Lxt4/qnelXWr74ow0knZi3E487fJeNBEXXN2mcpaPDwCBP5ii4l/jq+MiU7tucekR+XvkXoTB6X015T1nmG44eCCU0syZ/jLjKVVSL5VDIXzhZuGRMywt; Received: from neustargw.va.neustar.com ([209.173.53.233]:11231 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGd2O-0000Y6-1y; Tue, 25 Sep 2012 17:51:28 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=windows-1252 From: Brian Rosen X-Priority: 3 In-Reply-To: Date: Tue, 25 Sep 2012 17:51:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04112184-1E9E-4C5E-8B6D-A2DE60B16AAA@brianrosen.net> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net><67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> To: Art Botterell X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:51:34 -0000 It's not at all clear if the whitespace used inside the tag is the same = whitespace as used in XML, there is no reason to assume it is. It is decidedly unclear if 100.00, 200.00 is allowed. Parsing 100, 200 = 300, 400 is pretty easy if that's what you thought the rules were. Lots = of parsing routines can deal with whitespace surrounding delimiters if = that's what the syntax is. Defining syntax by use of examples is not very interoperable. It shows = A way, not THE way (or THE ONLY way). I'm pretty concerned about these issues because there is no practical = way to test all possible interoperable implementations, which is unlike = most current CAP deployments. When you have a smallish set of = participants, you can make it work by a bunch of testing. In this work, = we have to make it work on a larger scale, and that means precise, = interoperable definition of syntax and semantics. I have no desire to start over. CAP Is useful for us. We need to deal = with practicalities like this, either by profiling or by wrappers. Brian On Sep 25, 2012, at 5:29 PM, Art Botterell wrote: > White space is defined in the W3C XML 1.0 specification (which is = referenced as normative in the CAP spec) as "spaces, tabs, and blank = lines." >=20 > And the form =93[latitude],[longitude]=94 seems fairly unambiguous, = particularly since white space is specified as the delimiter between = pairs. =20 >=20 > Also there are a number of examples provided in the CAP document that, = while non-normative, were put there to help resolve any lingering = ambiguity. >=20 > - Art >=20 >=20 > On Sep 25, 2012, at 2:04 PM, Brian Rosen wrote: >=20 >> I did. All I see is: >> =95 The term =93coordinate pair=94 is used in this document to = refer to a comma-delimited pair of decimal values describing a = geospatial location in degrees, unprojected, in the form = =93[latitude],[longitude]=94. Latitudes in the Southern Hemisphere and = longitudes in the Western Hemisphere are signed negative by means of a = leading dash. >>=20 >> and >> Code Values: The geographic polygon is represented by a = whitespace-delimited list of [WGS 84] coordinate pairs. (See WGS- 84 = Note at end of this section.) >>=20 >>=20 >> There is no definition of whitespace. There is no text specifying if = whitespace is permitted around the comma that delimits the coordinate = pairs. >>=20 >> Brian >>=20 >> On Sep 25, 2012, at 4:36 PM, Art Botterell wrote: >>=20 >>> Please, Brian, look at the spec before generalizing about it. All = those questions are precisely answered. The answers are different than = those for either GML or KML, but no less detailed. >>>=20 >>>=20 >>> On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: >>>=20 >>>> How are the pairs separated? >>>> What whitespace is acceptable? >>>> Is whitespace allowed between the coordinates, before or after the = comma? >>>>=20 >>>> Stuff like that. >>>>=20 >>>> Brian >>>> On Sep 25, 2012, at 4:15 PM, Art Botterell = wrote: >>>>=20 >>>>> Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >>>>>=20 >>>>> (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >>>>>=20 >>>>> But I do have to question your assertion that the CAP format is = either "ill-defined" or "subject to interpretation." Have you actually = read the CAP spec? If so, what exactly do you mean? >>>>>=20 >>>>> - Art >>>>>=20 >>>>>=20 >>>>> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>>>>=20 >>>>>> Right, but what do we do here? >>>>>>=20 >>>>>> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. =20 >>>>>>=20 >>>>>> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 25, 2012, at 3:58 PM, Art Botterell = wrote: >>>>>>=20 >>>>>>> Dunno, Carl... certainly we were glad to have you there on the = TC representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. =20 >>>>>>>=20 >>>>>>> - Art >>>>>>>=20 >>>>>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>>>>=20 >>>>>>>> Art >>>>>>>>=20 >>>>>>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>>=20 >>>>>>>> Carl >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- From: Art Botterell >>>>>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: atoca@ietf.org >>>>>>>> Subject: Re: [atoca] Next milestone >>>>>>>>=20 >>>>>>>> Funny thing, that... we tried to make the CAP geometries align = with GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>>>>>=20 >>>>>>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>>>>>=20 >>>>>>>> - Art >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>>>>=20 >>>>>>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>>>>>=20 >>>>>>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>>>>>=20 >>>>>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>>>>> For example, how do you target "Allegheny County, PA, US"? = A text line? With what syntax? A polygon? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> In CAP the recommended presentation would be a polygon, a = line of text that might well read "Allegheny County, PA, US" and = optionally a value, which in the US would typically be a = FIPS-based code conforming to the old Emergency Alert System standard = (in this case, "042003"). >>>>>>>>>>=20 >>>>>>>>>> There are a few subtleties here. First, most hazard = footprints don't align very well with political boundaries, so it's = actually considered best practice NOT to address an alert to everyone in = a political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>>>>>=20 >>>>>>>>>> Second, but related to the first... there is at present no = strict limit on the number of vertices in a polygon in CAP. Generally = this hasn't been a problem, as both manual and model-derived (e.g., from = a hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>>>>>=20 >>>>>>>>>> In such cases conversion from GIS geometries developed for = other purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>>>>>=20 >>>>>>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>>>>>=20 >>>>>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>>>>>=20 >>>>>>>>>> And the text areaDescription field is defined merely as = "human readable" so it can be as concise or as extensive as = circumstances dictate. However, where multi-lingual alerting is required = it tends to be kept short to facilitate translation. >>>>>>>>>>=20 >>>>>>>>>> - Art >>>>>>>>>> _______________________________________________ >>>>>>>>>> atoca mailing list >>>>>>>>>> atoca@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> atoca mailing list >>>>>>>> atoca@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/atoca=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From martin.thomson@gmail.com Tue Sep 25 16:02:56 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015B31F0425 for ; Tue, 25 Sep 2012 16:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2leF8Bf2QUXz for ; Tue, 25 Sep 2012 16:02:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8601421F87A8 for ; Tue, 25 Sep 2012 16:02:54 -0700 (PDT) Received: by lbok13 with SMTP id k13so929836lbo.31 for ; Tue, 25 Sep 2012 16:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TAhfK4GBO0T0qlcyU6fnYcyYATmgJf/TBlTtm6alrEs=; b=kJq7RKMjb7Ig0QZwecHBxSm4EcttbP22RG80ekdG7sWo829DZTeRBS1K2prRx+X7eH vr2ddYyYuZSXLrWXgJnp/reM/3LuezLupFFM4w+Kr1kcHiJWoqgUVU7VtMqmmK2ZBIel GGv02bIF/31G5jjfBSQ05wbPVNPKp1KYhLv3IGEQYxXvbV6xakj7RaPjtbq1YrdJmaWz J8mYiY9AnMxAzppjSCahKyPUAPWOjkZdajAy38W/RXHQQjf7c8ACJCdCZqvFsPC+9QkI NXceyJEx6MBizxoD/FhzR5KvpOnTwXLiKT7itNrrXNxKNyJX5+HxH1Vup7yUCV1nmVeK HtNw== MIME-Version: 1.0 Received: by 10.112.103.71 with SMTP id fu7mr5787764lbb.21.1348614171354; Tue, 25 Sep 2012 16:02:51 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Tue, 25 Sep 2012 16:02:51 -0700 (PDT) In-Reply-To: <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> Date: Tue, 25 Sep 2012 16:02:51 -0700 Message-ID: From: Martin Thomson To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 23:02:56 -0000 Brian, This is an interesting discussion, and I think that were getting to the nub of the problem. However, I'd like to understand what you think the draft under discussion needs to include in order to address this problem. --Martin On 25 September 2012 14:04, Brian Rosen wrote: > I did. All I see is: > =E2=80=A2 The term =E2=80=9Ccoordinate pair=E2=80=9D is used in t= his document to refer to a comma-delimited pair of decimal values describin= g a geospatial location in degrees, unprojected, in the form =E2=80=9C[lati= tude],[longitude]=E2=80=9D. Latitudes in the Southern Hemisphere and longit= udes in the Western Hemisphere are signed negative by means of a leading d= ash. > > and > Code Values: The geographic polygon is represented by a whitespace-delimi= ted list of [WGS 84] coordinate pairs. (See WGS- 84 Note at end of this sec= tion.) > > > There is no definition of whitespace. There is no text specifying if whi= tespace is permitted around the comma that delimits the coordinate pairs. "Whitespace" has a very specific meaning in XML. Not without its pitfalls for the uninitiated, but it IS specific. I could write a relatively simple XML schema rule for that text that would completely constrain the grammar. I don't see any ambiguity here. I do see some curvature issues with determining if a point is enclosed or not, but that's nothing a little engineering couldn't solve. > Brian > > On Sep 25, 2012, at 4:36 PM, Art Botterell wrote: > >> Please, Brian, look at the spec before generalizing about it. All those= questions are precisely answered. The answers are different than those fo= r either GML or KML, but no less detailed. >> >> >> On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: >> >>> How are the pairs separated? >>> What whitespace is acceptable? >>> Is whitespace allowed between the coordinates, before or after the comm= a? >>> >>> Stuff like that. >>> >>> Brian >>> On Sep 25, 2012, at 4:15 PM, Art Botterell wrote: >>> >>>> Personally I'd have no objection to using a simple GML-based represent= ation, although that would mean that the "wrapper" would have a different s= erialization of a geometry than the enclosed CAP message, which some might = find confusing or inconsistent even though the two would be semantically eq= uivalent. >>>> >>>> (And again, the underlying question is whether the world actually need= s yet another "wrapper" for alerts, considering that we already have both S= OAP and the OASIS EDXL-DE.) >>>> >>>> But I do have to question your assertion that the CAP format is either= "ill-defined" or "subject to interpretation." Have you actually read the= CAP spec? If so, what exactly do you mean? >>>> >>>> - Art >>>> >>>> >>>> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>>> >>>>> Right, but what do we do here? >>>>> >>>>> In general, in the IETF, we use GML. CAP doesn't, and has an ill-def= ined, subject to interpretation, representation, as you said below. >>>>> >>>>> What should we do? We need interoperability. We could try to profil= e it so we get interoperability, and describe how that would be converted t= o GML I suppose. >>>>> >>>>> Brian >>>>> >>>>> On Sep 25, 2012, at 3:58 PM, Art Botterell wrote: >>>>> >>>>>> Dunno, Carl... certainly we were glad to have you there on the TC re= presenting OGC... and yet somehow, despite all our best intentions, the coo= rdinate order wound up reversed in CAP vs GML. And then, of course, KML ca= me into play, different yet again. But standards-political history isn't t= he topic here. The practical point is that there are a variety of ways out= there to say what's ultimately the exact same thing. >>>>>> >>>>>> - Art >>>>>> >>>>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>>> >>>>>>> Art >>>>>>> >>>>>>> GML changed directions? Not sure what you mean. There is now an OAS= IS GML profile for use in OASIS EM standards. Being referenced in HAVE, xAL= , and EDXL. Perhaps in the next version of CAP? :-) >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Carl >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: Art Botterell >>>>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>>>> To: Brian Rosen >>>>>>> Cc: atoca@ietf.org >>>>>>> Subject: Re: [atoca] Next milestone >>>>>>> >>>>>>> Funny thing, that... we tried to make the CAP geometries align with= GML... even has a representative from OGC (Carl Reed) on the OASIS committ= ee when we were' specifying it... but then GML changed directions and the C= AP spec wound up different. Personally I'd suggest using the CAP syntax, f= or consistency, as that can be switched into GML, KML or whatever easily an= d precisely an application requires. >>>>>>> >>>>>>> Yes, ultimately any geocode is really just a shorthand for some pol= ygon. Different jurisdictions around the world will have different geocodin= g schemes, and it's hard to assume that every receiving device will be fami= liar with them all... but geometry is universal... or at least planet-wide. >>>>>>> >>>>>>> - Art >>>>>>> >>>>>>> >>>>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>>> >>>>>>>> I guess that's my point. Without more spec, we have interoperabil= ity issues. When you have limited CAP deployment, these can be dealt with = by prior arrangement. We probably can't do that. I would prefer that a po= lygon be encoded with GML, which is precise, interoperable and an accepted = global standard. That can be wrapped in a PIDF (an IETF standard) or not, = but we need something very interoperable. >>>>>>>> >>>>>>>> Forcing polygons may work in a forward looking sense. I'm probab= ly convincible that a jurisdictional areas aren't needed, but so many of th= e alert sources I'm interested in supporting are based on jurisdictions. I= guess just telling them they need to come up with a relatively simple poly= gon is okay. Since increasingly, device location is GPS (or equivalent) ba= sed, we probably need geo always. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell wrot= e: >>>>>>>> >>>>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>>>> For example, how do you target "Allegheny County, PA, US"? A te= xt line? With what syntax? A polygon? >>>>>>>>> >>>>>>>>> >>>>>>>>> In CAP the recommended presentation would be a polygon, a line of= text that might well read "Allegheny County, PA, US" and optionally a value, which in the US would typically be a FIPS-based code conformin= g to the old Emergency Alert System standard (in this case, "042003"). >>>>>>>>> >>>>>>>>> There are a few subtleties here. First, most hazard footprints d= on't align very well with political boundaries, so it's actually considered= best practice NOT to address an alert to everyone in a political jurisdict= ion if better resolution is available, which increasingly often is the case= . (This is probably the biggest challenges in the transition from the lega= cy EAS and Weather Radio systems in the States and the newer CAP-based IPAW= S framework.) >>>>>>>>> >>>>>>>>> Second, but related to the first... there is at present no strict= limit on the number of vertices in a polygon in CAP. Generally this hasn'= t been a problem, as both manual and model-derived (e.g., from a hazardous = materials "plume model" software) polygons tend to be relatively simple. Ho= wever, if one uses a political jurisdiction as the target area and if, as o= ften is the case, that jurisdiction is defined at least in part by a waterw= ay or water body, then at least part of the "true" polygon will be fractal = in nature and the number of vertices used to represent it becomes an implem= entation decision. >>>>>>>>> >>>>>>>>> In such cases conversion from GIS geometries developed for other = purposes can, at least in theory, produce very lengthy polygon description = strings. Some degree of polygon simplification, manually or by means of a = "convex hull" calculation, may be helpful in such situations; fortunately t= hose can be calculated ahead of time. A common guideline and a requirement= of the IPAWS profile in the U.S. is that a polygon be limited to 100 verti= ces. Again, this is largely a theoretical concern, and I'm not aware of an= y case where this has actually been a problem. >>>>>>>>> >>>>>>>>> And third, of course, there's quite a bit of variety in how polyg= ons get represented as strings. Latitude first and then longitude, or the = reverse "x,y" order? Commas between the coordinates and spaces between the= pairs, or vice versa, or some other delimiters? All such representations = are ultimately equivalent (at least until we drill down to the level of whe= ther we're using the increasingly common GPS-standard WGS84 datum or some m= odel of the precise shape of the Earth.) But it's important to be clear wh= ich format is being used and to remember of convert as necessary, e.g., bet= ween CAP and KML. >>>>>>>>> >>>>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string des= ignators) without also providing the corresponding geometry (polygon), sinc= e to do otherwise is to assume that the receiving device knows every possib= le geocoding scheme it might ever encounter, which in an open global system= is probably infeasible. Indeed, ideally we might have done without geocod= es entirely, but back-compatibility with legacy systems (and the comfort of= some non-GIS-savvy programmers who understood string-matching but were unc= omfortable with things like point-in-polygon algorithms) dictated their inc= lusion. >>>>>>>>> >>>>>>>>> And the text areaDescription field is defined merely as "human re= adable" so it can be as concise or as extensive as circumstances dictate. H= owever, where multi-lingual alerting is required it tends to be kept short = to facilitate translation. >>>>>>>>> >>>>>>>>> - Art >>>>>>>>> _______________________________________________ >>>>>>>>> atoca mailing list >>>>>>>>> atoca@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>> >>>>>> _______________________________________________ >>>>>> atoca mailing list >>>>>> atoca@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>> >>>> >>> >> > > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From br@brianrosen.net Tue Sep 25 16:53:26 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDBE21F8499 for ; Tue, 25 Sep 2012 16:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.504 X-Spam-Level: X-Spam-Status: No, score=-99.504 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhY86CTyXtXc for ; Tue, 25 Sep 2012 16:53:25 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5512321F8498 for ; Tue, 25 Sep 2012 16:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=tL+/VPFsMTa2e0rlM6np+p/xKTDsVKSLF0HtPq8LVPw=; b=niUVjES7jdnJ1nY1ouuyl7hHJko0+lBV3WaEBIZkls4utjtBi1DnbfLMuTtgdLt7DuUkBvB6a+FitJSQGxcOLOyJQ9EHAqkgTEU0z8l9YUZLBFhEXcHQzUncI4PPdu4M; Received: from neustargw.va.neustar.com ([209.173.53.233]:19165 helo=[10.33.188.75]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TGewN-0000a8-Nu; Tue, 25 Sep 2012 19:53:23 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Brian Rosen In-Reply-To: Date: Tue, 25 Sep 2012 19:53:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> To: Martin Thomson X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 23:53:26 -0000 I'm not sure. If this is the "inner" wrapper, then it needs to profile = CAP for use in this application. The issues we are discussing are in = that profile. I suspect there are more, for example: a) what is the relationship between the identity in the CAP message, the = identity in the wrapper and the identity in the next layer(s)? b) Isn't there some need to classify, on some extensible basis, types of = alerts, for the purpose of filtering in the transmission system? How = are those related to eventCode? c) What are we doing to avoid duplicate alerts received by multiple = distributors? We need some unique ID that is used at the receiving = device. How is that related to alert identifier? There probably are more. Brian On Sep 25, 2012, at 7:02 PM, Martin Thomson = wrote: > Brian, >=20 > This is an interesting discussion, and I think that were getting to > the nub of the problem. >=20 > However, I'd like to understand what you think the draft under > discussion needs to include in order to address this problem. >=20 > --Martin >=20 > On 25 September 2012 14:04, Brian Rosen wrote: >> I did. All I see is: >> =95 The term =93coordinate pair=94 is used in this document to = refer to a comma-delimited pair of decimal values describing a = geospatial location in degrees, unprojected, in the form = =93[latitude],[longitude]=94. Latitudes in the Southern Hemisphere and = longitudes in the Western Hemisphere are signed negative by means of a = leading dash. >>=20 >> and >> Code Values: The geographic polygon is represented by a = whitespace-delimited list of [WGS 84] coordinate pairs. (See WGS- 84 = Note at end of this section.) >>=20 >>=20 >> There is no definition of whitespace. There is no text specifying if = whitespace is permitted around the comma that delimits the coordinate = pairs. >=20 > "Whitespace" has a very specific meaning in XML. Not without its > pitfalls for the uninitiated, but it IS specific. I could write a > relatively simple XML schema rule for that text that would completely > constrain the grammar. I don't see any ambiguity here. I do see some > curvature issues with determining if a point is enclosed or not, but > that's nothing a little engineering couldn't solve. >=20 >> Brian >>=20 >> On Sep 25, 2012, at 4:36 PM, Art Botterell wrote: >>=20 >>> Please, Brian, look at the spec before generalizing about it. All = those questions are precisely answered. The answers are different than = those for either GML or KML, but no less detailed. >>>=20 >>>=20 >>> On Sep 25, 2012, at 1:33 PM, Brian Rosen wrote: >>>=20 >>>> How are the pairs separated? >>>> What whitespace is acceptable? >>>> Is whitespace allowed between the coordinates, before or after the = comma? >>>>=20 >>>> Stuff like that. >>>>=20 >>>> Brian >>>> On Sep 25, 2012, at 4:15 PM, Art Botterell = wrote: >>>>=20 >>>>> Personally I'd have no objection to using a simple GML-based = representation, although that would mean that the "wrapper" would have a = different serialization of a geometry than the enclosed CAP message, = which some might find confusing or inconsistent even though the two = would be semantically equivalent. >>>>>=20 >>>>> (And again, the underlying question is whether the world actually = needs yet another "wrapper" for alerts, considering that we already have = both SOAP and the OASIS EDXL-DE.) >>>>>=20 >>>>> But I do have to question your assertion that the CAP format is = either "ill-defined" or "subject to interpretation." Have you actually = read the CAP spec? If so, what exactly do you mean? >>>>>=20 >>>>> - Art >>>>>=20 >>>>>=20 >>>>> On Sep 25, 2012, at 1:04 PM, Brian Rosen wrote: >>>>>=20 >>>>>> Right, but what do we do here? >>>>>>=20 >>>>>> In general, in the IETF, we use GML. CAP doesn't, and has an = ill-defined, subject to interpretation, representation, as you said = below. >>>>>>=20 >>>>>> What should we do? We need interoperability. We could try to = profile it so we get interoperability, and describe how that would be = converted to GML I suppose. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Sep 25, 2012, at 3:58 PM, Art Botterell = wrote: >>>>>>=20 >>>>>>> Dunno, Carl... certainly we were glad to have you there on the = TC representing OGC... and yet somehow, despite all our best intentions, = the coordinate order wound up reversed in CAP vs GML. And then, of = course, KML came into play, different yet again. But = standards-political history isn't the topic here. The practical point = is that there are a variety of ways out there to say what's ultimately = the exact same thing. >>>>>>>=20 >>>>>>> - Art >>>>>>>=20 >>>>>>> On Sep 25, 2012, at 12:28 PM, Carl Reed wrote: >>>>>>>=20 >>>>>>>> Art >>>>>>>>=20 >>>>>>>> GML changed directions? Not sure what you mean. There is now an = OASIS GML profile for use in OASIS EM standards. Being referenced in = HAVE, xAL, and EDXL. Perhaps in the next version of CAP? :-) >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>>=20 >>>>>>>> Carl >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- From: Art Botterell >>>>>>>> Sent: Tuesday, September 25, 2012 12:51 PM >>>>>>>> To: Brian Rosen >>>>>>>> Cc: atoca@ietf.org >>>>>>>> Subject: Re: [atoca] Next milestone >>>>>>>>=20 >>>>>>>> Funny thing, that... we tried to make the CAP geometries align = with GML... even has a representative from OGC (Carl Reed) on the OASIS = committee when we were' specifying it... but then GML changed directions = and the CAP spec wound up different. Personally I'd suggest using the = CAP syntax, for consistency, as that can be switched into GML, KML or = whatever easily and precisely an application requires. >>>>>>>>=20 >>>>>>>> Yes, ultimately any geocode is really just a shorthand for some = polygon. Different jurisdictions around the world will have different = geocoding schemes, and it's hard to assume that every receiving device = will be familiar with them all... but geometry is universal... or at = least planet-wide. >>>>>>>>=20 >>>>>>>> - Art >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote: >>>>>>>>=20 >>>>>>>>> I guess that's my point. Without more spec, we have = interoperability issues. When you have limited CAP deployment, these = can be dealt with by prior arrangement. We probably can't do that. I = would prefer that a polygon be encoded with GML, which is precise, = interoperable and an accepted global standard. That can be wrapped in a = PIDF (an IETF standard) or not, but we need something very = interoperable. >>>>>>>>>=20 >>>>>>>>> Forcing polygons may work in a forward looking sense. I'm = probably convincible that a jurisdictional areas aren't needed, but so = many of the alert sources I'm interested in supporting are based on = jurisdictions. I guess just telling them they need to come up with a = relatively simple polygon is okay. Since increasingly, device location = is GPS (or equivalent) based, we probably need geo always. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 25, 2012, at 2:14 PM, Art Botterell = wrote: >>>>>>>>>=20 >>>>>>>>>> On Sep 25, 2012, at 10:30 AM, Brian Rosen wrote: >>>>>>>>>>> For example, how do you target "Allegheny County, PA, US"? = A text line? With what syntax? A polygon? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> In CAP the recommended presentation would be a polygon, a = line of text that might well read "Allegheny County, PA, US" and = optionally a value, which in the US would typically be a = FIPS-based code conforming to the old Emergency Alert System standard = (in this case, "042003"). >>>>>>>>>>=20 >>>>>>>>>> There are a few subtleties here. First, most hazard = footprints don't align very well with political boundaries, so it's = actually considered best practice NOT to address an alert to everyone in = a political jurisdiction if better resolution is available, which = increasingly often is the case. (This is probably the biggest = challenges in the transition from the legacy EAS and Weather Radio = systems in the States and the newer CAP-based IPAWS framework.) >>>>>>>>>>=20 >>>>>>>>>> Second, but related to the first... there is at present no = strict limit on the number of vertices in a polygon in CAP. Generally = this hasn't been a problem, as both manual and model-derived (e.g., from = a hazardous materials "plume model" software) polygons tend to be = relatively simple. However, if one uses a political jurisdiction as the = target area and if, as often is the case, that jurisdiction is defined = at least in part by a waterway or water body, then at least part of the = "true" polygon will be fractal in nature and the number of vertices used = to represent it becomes an implementation decision. >>>>>>>>>>=20 >>>>>>>>>> In such cases conversion from GIS geometries developed for = other purposes can, at least in theory, produce very lengthy polygon = description strings. Some degree of polygon simplification, manually or = by means of a "convex hull" calculation, may be helpful in such = situations; fortunately those can be calculated ahead of time. A common = guideline and a requirement of the IPAWS profile in the U.S. is that a = polygon be limited to 100 vertices. Again, this is largely a = theoretical concern, and I'm not aware of any case where this has = actually been a problem. >>>>>>>>>>=20 >>>>>>>>>> And third, of course, there's quite a bit of variety in how = polygons get represented as strings. Latitude first and then longitude, = or the reverse "x,y" order? Commas between the coordinates and spaces = between the pairs, or vice versa, or some other delimiters? All such = representations are ultimately equivalent (at least until we drill down = to the level of whether we're using the increasingly common GPS-standard = WGS84 datum or some model of the precise shape of the Earth.) But it's = important to be clear which format is being used and to remember of = convert as necessary, e.g., between CAP and KML. >>>>>>>>>>=20 >>>>>>>>>> The CAP spec deprecates the use of geocodes (arbitrary string = designators) without also providing the corresponding geometry = (polygon), since to do otherwise is to assume that the receiving device = knows every possible geocoding scheme it might ever encounter, which in = an open global system is probably infeasible. Indeed, ideally we might = have done without geocodes entirely, but back-compatibility with legacy = systems (and the comfort of some non-GIS-savvy programmers who = understood string-matching but were uncomfortable with things like = point-in-polygon algorithms) dictated their inclusion. >>>>>>>>>>=20 >>>>>>>>>> And the text areaDescription field is defined merely as = "human readable" so it can be as concise or as extensive as = circumstances dictate. However, where multi-lingual alerting is required = it tends to be kept short to facilitate translation. >>>>>>>>>>=20 >>>>>>>>>> - Art >>>>>>>>>> _______________________________________________ >>>>>>>>>> atoca mailing list >>>>>>>>>> atoca@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> atoca mailing list >>>>>>>> atoca@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> atoca mailing list >>>>>>> atoca@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/atoca >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca From mark.wood@engineer.com Wed Sep 26 02:52:17 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557DC21F880B for ; Wed, 26 Sep 2012 02:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbaQZKdhged2 for ; Wed, 26 Sep 2012 02:52:16 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207EA21F8811 for ; Wed, 26 Sep 2012 02:52:15 -0700 (PDT) X-Trace: 559671990/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@engineer.com X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEJADnPYlBRVitW/2dsb2JhbABFvUAEgQyBCYIgAQEBBAEBAQUyHAgQBBMBBAEGFAQBAQoeIA4MBg0JCAEBBBMLEIduB5hDkEKRG4seOIRMgQUDjWiETYh/iH6BXIJo X-IronPort-AV: E=Sophos;i="4.80,489,1344207600"; d="scan'208";a="559671990" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 26 Sep 2012 10:52:09 +0100 From: "Mark Wood" Sender: "Mark" To: In-Reply-To: <63294164-DEC1-4C6D-8B5C-27697D0F118A@incident.com> Date: Wed, 26 Sep 2012 10:52:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ac2bZqdVtg2MnKhCQgechYav1f9Q2wAYFDUg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120926095216.207EA21F8811@ietfa.amsl.com> Subject: [atoca] Government Gateways. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 09:52:17 -0000 Chaps; Thanks for bringing this up Art, this may seem like a segue in the context of this conversation about authentication and authorisation wrappers, but it is not, because the technology has to fit the politics and the demands of the participating networks in this situation, so in considering any alerting mechanism, it has to have the capabilities that are required as a condition of their participation. For example, when Cell Broadcast first came under consideration by cellular networks, one of their concerns, (and a perfectly valid one) was any possible liability if their networks broadcasted an evacuation order which subsequently proved to be overly pessimistic. They were worried (quite rightly) about shop keepers suing them over loss of revenue caused by fleeing residents etc (you know how it is!). It's true that the 'Chicken Little' will face his own music, and good luck to him, but the networks are not concerned about that. All networks value their relationship with their customers and absolutely will not risk irritating them in any way, so any participating network would want to protect their reputation with their customers, by having a non repudiation trail back to the originator of a message, and also very robust methodology for making the government liable for vetting authorised officials. Their (completely reasonable) position is that to vet lots of mayors and police chiefs (which have constant churn) would be a unreasonable burden upon them. This is why the government managed gateway solution is demanded by the networks in the CMSAC report for example, and is reason for IPAWS OPEN. Every country that I have worked with takes the same view of this. So any 'instance of participating network' (no matter what technology) will probably be well advised to get its public alerting messages from the alert gateway specified by the sovereign state concerned, rather by some fuzzier discovery methodology which may prove very complex to manage and be full of litigation liability. Google, for example, would need to pay different attention to civic mandates than it would to purely observational information. But thanks to CAP, the gateways are designed to handle this so any distribution outlets of any sort can participate with the gateway under the terms of their own MoU. Mark. -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Art Botterell Sent: 25 September 2012 22:42 To: Mark Wood Cc: atoca@ietf.org Subject: Re: [atoca] Next milestone On Sep 25, 2012, at 2:28 PM, Mark Wood wrote: > ...but if you want to say "leave your home and go to high ground now", this is > completely different and only a properly authorised agent of the sovereign > state may lawfully do that. Well, not everywhere, Here in the U.S. anyone may say that... and may be held accountable for the results afterwards. (Which accountability can be so dire that folks generally hesitate before taking the risk, so the end effect is essentially the same, but arguably with a bit more flexibility for extreme circumstances.) But that does vary from place to place. As John Perry Barlow once reminded Americans, "the First Amendment is a local ordinance." So... is it permissible to shout "fire!" in a burning theater? Yes, but perhaps not in a burning theatre! By which spelling variation I mean to suggest that in different places this question is subject to different laws and different notions both of sovereignty and of individual (and/or corporate) duty. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca