Subject: [atoca] Next milestone

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2012 10:09:43 -0700

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: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 13:30:46 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> atoca mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atoca

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 11:14:55 -0700

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 14:25:03 -0400

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

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 11:51:59 -0700

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

---

From: "Mark Wood" <[email-masked]>
Date: Tue, 25 Sep 2012 20:17:41 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Art Botterell
Sent: 25 September 2012 19:52
To: Brian Rosen
Cc: [email-masked]
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.
>> 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.

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 25 Sep 2012 13:28:44 -0600

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: [email-masked]
Subject: Re: [atoca] Next milestone

- Art

On Sep 25, 2012, at 11:25 AM, Brian Rosen wrote:

> 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.
>
> polygon is okay.  Since increasingly, device location is GPS (or 
> equivalent) based, we probably need geo always.
>
> Brian
>
>
>> 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").
>>
>> 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.)
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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: "Carl Reed" <[email-masked]>
Date: Tue, 25 Sep 2012 13:31:01 -0600

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: [email-masked]
Subject: Re: [atoca] Next milestone

Brian

On Sep 25, 2012, at 2:14 PM, Art Botterell <[email-masked]> wrote:

> 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 
> 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.
>
> 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 
> comfort of some non-GIS-savvy programmers who understood string-matching 
> but were uncomfortable with things like point-in-polygon algorithms) 
> dictated their inclusion.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 15:56:43 -0400

We can always hope!

Brian
On Sep 25, 2012, at 3:28 PM, Carl Reed <[email-masked]> 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

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 12:58:36 -0700

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 16:04:24 -0400

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

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 13:15:37 -0700

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 16:33:20 -0400

How are the pairs separated?
What whitespace is acceptable?
Is whitespace allowed between the coordinates, before or after the comma?

Stuff like that.

Brian

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 13:36:21 -0700

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.

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 13:46:53 -0700

On Sep 25, 2012, at 12:17 PM, Mark Wood wrote:
> 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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 17:04:28 -0400

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.

Brian

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 25 Sep 2012 15:23:05 -0600

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: [email-masked]
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:

>> 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
>>
>>
>>> 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
>>>
>>>> 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
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> 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 
>>>>>>> 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.
>>>>>>>
>>>>>>> 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: "Mark Wood" <[email-masked]>
Date: Tue, 25 Sep 2012 22:28:26 +0100

(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: [email-masked] [mailto:[email-masked]] On Behalf Of
Art Botterell
Sent: 25 September 2012 21:47
To: Mark Wood
Cc: [email-masked]
Subject: Re: [atoca] Next milestone

> policy to the proposed message on the basis of sovereignty of the
territory

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

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 14:29:44 -0700

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 “[latitude],[longitude]” seems fairly unambiguous, particularly since white space is specified as the delimiter between pairs.  

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

---

From: Art Botterell <[email-masked]>
Date: Tue, 25 Sep 2012 14:42:14 -0700

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
> 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: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 17:51:26 -0400

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2012 16:02:51 -0700

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

> 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.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 Sep 2012 19:53:22 -0400

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

---

From: "Mark Wood" <[email-masked]>
Date: Wed, 26 Sep 2012 10:52:09 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Art Botterell
Sent: 25 September 2012 22:42
To: Mark Wood
Cc: [email-masked]
Subject: Re: [atoca] Next milestone

> 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