Re: [atoca] Next milestone

Brian Rosen <br@brianrosen.net> Tue, 25 September 2012 23:53 UTC

Return-Path: <br@brianrosen.net>
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 <atoca@ietfa.amsl.com>; 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 <atoca@ietfa.amsl.com>; 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 <atoca@ietf.org>; 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 <br@brianrosen.net>) 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 <br@brianrosen.net>
In-Reply-To: <CABkgnnX9X-H3CK=9t_UbfaaSJ6rNEXvAuKaXwF9w3TshVptJuw@mail.gmail.com>
Date: Tue, 25 Sep 2012 19:53:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2CA4762-3837-4B25-AECF-7EF619E88E95@brianrosen.net>
References: <CABkgnnXJQ25CRw4wVGmvk3tBCKUZGNgei4KOVseFBYJfotxb=Q@mail.gmail.com> <1597D6F5-A6A4-418C-AE5C-C4426992A645@brianrosen.net> <67ADBEFC-B056-4064-B18C-02EB9CBC539E@incident.com> <A8BDD10D-479A-4D72-B565-439DD6923F71@brianrosen.net> <783AAAE3-344E-4C03-B3FB-E402F84D0699@incident.com> <E7978A1A74C14CCF94702F4C4816DCAC@OfficeHP> <C45316E8-46F1-42A0-85C2-B73EFAA0408B@incident.com> <B9135A12-7D34-459C-8529-CE0F615FBC6A@brianrosen.net> <5B654303-65A2-4BD8-AAC3-7A986FA2C2AE@incident.com> <D935B591-6BB0-49BB-811A-2E6B3275B141@brianrosen.net> <D26D3E61-64E7-4B4D-8666-8B0DCABF1E19@incident.com> <07595E05-B7C4-4A76-A5A0-129CF249CD6A@brianrosen.net> <CABkgnnX9X-H3CK=9t_UbfaaSJ6rNEXvAuKaXwF9w3TshVptJuw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
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." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=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 <martin.thomson@gmail.com>; wrote:

> 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 <br@brianrosen.net>; wrote:
>> I did.  All I see is:
>>        • The term “coordinate pair” 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 “[latitude],[longitude]”. 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.
> 
> "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 <acb@incident.com>; 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.
>>> 
>>> 
>>> 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 <acb@incident.com>; 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 <acb@incident.com>; 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 <acb@incident.com>; 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 <geocode> 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