Re: [emergency] CAP-related Comments

["CONSULTRAC" <rcarlton@consultrac.com>]

After consideration, I agree with  Rex's process suggestions.

Rick
----- Original Message ----- 
From: "Rex Brooks" <rexb@starbourne.com>
To: <emtc@nc.rr.com>; "Walid Ramadan" <WRamadan@blue292.com>
Cc: <emergency@lists.oasis-open.org>
Sent: Wednesday, October 15, 2003 9:09 PM
Subject: Re: [emergency] CAP-related Comments


> Hi Folks,
>
> Having been privy to the discussions on ICS 201, which overlapped
> some of Walid's CAP items list, and now having read Carl's and Art's
> responses to Walid's list, and considering that we have conducted two
> kinds of tests, I believe we have fulfilled the measures under which
> we voted to recommend CAP as a Committee Specification. In fact we
> have well and truly exceeded OASIS TC process guidance in doing such
> tests. I don't think we need another vote on record.
>
> To be honest, there are areas where I am sure we could tighten,
> tweak, and refine CAP, but we would still be facing a 30-public
> comment period, so beyond mentioning that an Implementation Guide is
> forthcoming, and adding a couple of explanatory statements such as
> Carl has suggested, I think we should proceed. On the lat/long issue,
> I think punting at this point makes more sense. Noting that
> referenced specs should be followed according to the current practice
> pending comment on the candidate Committee Specification should be
> sufficient.
>
> I say this because we are bound to discover more issues during the
> 30-day public comment period, and CAP will not actually become a an
> official Committee Specification until we have a vote after after we
> have dealt with each of the public comment issues as a whole TC. Some
> of what has turned up in Walid's list may need to be dealt with in
> this process, so we are not abandoning or ignoring any currently
> unresolved issues.
>
> Once the 30-day public comment period has passed, then we deal with
> each of the issues that have turned up to a resolution, voting on
> these item by item if needs be. Since I know how rigorous this
> process needs to be, believe me when I say that we will have
> thoroughly gone over everything, probably twice or three times as we
> go through the issues after the first round of public comment is done.
>
> We can't know what it will look like then, no matter how satisfied or
> dissatisfied any of us are now. And the same would apply if we tried
> to anticipate all possible known or hypothetical contradicitons,
> exceptions, misstatements, misunderstandings, etc. Like any battle
> plan, it won't last past the first engagement. So I think we should
> go for it rather than wait, and, as I said, we have already voted up
> on Committee Spec status with minor revisions, which is what we have
> right now.
>
> That's my $.02.
>
> Ciao,
> Rex
>
> At 12:53 AM -0400 10/15/03, emtc@nc.rr.com wrote:
> >Great work Walid - thanx for pulling these together.
> >
> >TC: at this point, its time for our next decision. We have to decide
> >on whether or not to address this information now or after the
> >Public Comment. Doesn't mean that 100% has to be addressed now -
> >just a decision on whether to edit the current doc now or to wait
> >until Public Comment. If not, then we send to OASIS. If there is a
> >need to edit now (or after the Public Comment for that matter), we
> >will need to look at each of these items and determine what to do
> >with them. We can basically decide to amend the spec, reject the
> >comment, debate the comment, or postpone the comment (for a future
> >spec version consideration for instance). There are some variations,
> >but you get the idea.
> >
> >At this time consider the list open to general comments on these
> >issues and how to proceed. We will do this until EOD next Tuesday,
> >at which time I will create a voting ballot on whether to edit or
> >not before we send to OASIS.
> >
> >Allen
> >
> >----- Original Message -----
> >From: Walid Ramadan <WRamadan@blue292.com>
> >Date: Tuesday, October 14, 2003 3:16 pm
> >Subject: [emergency] CAP-related Comments
> >
> >>  CAP-RELATED COMMENTS
> >>  AS OF 10/13/2003
> >>
> >>  All:
> >>
> >>  The following is a list of comments/issues that I compiled from a
> >>  variety of sources. For the most part, comments were collected from
> >>  these sources:
> >>
> >>  * Review of the OASIS CAP-Interop monthly archives at
> >>  * Comments that I received directly from TC and Sub-Committees'
> >>  memberson or before 10/13/2003.
> >  > * EM TC comments after the internal "format" (or "intent") test.
> >>
> >>  As I went through these comments it became apparent that they
> >>  could be
> >>  triaged into several buckets. These buckets are the following:
> >>
> >>  a) Geospatial-Related (Issues 1 through 5): Questions and comments
> >>  around how CAP supports geospatial information. The result of this
> >>  couldbe anything from adding geo-specific "References" or maybe a
> >>  section on
> >>  "How to Use Geospatial Data".
> >>
> >>  b) Transformations (Issues 6 and 7): Questions and comments around how
> >>  to map/transform CAP into other formats, like other XML standards,
> >>  text-to-speech, ASN-1, etc. While this is mostly for backwards
> >>  compatibility with existing applications, standards, products,
> >>  services,etc., it can also be hugely beneficial for the future as
> >>  well. Some
> >>  influence should be considered from issues 9 and 28 as well.
> >>
> >>  c) Transport (Issues 8 through 11): Questions and comments around
> >>  how to
> >>  properly exchange CAP messages. This is where the inline binary, Web
> >>  Service, encryption, authentication, etc. stuff falls into place. Need
> >>  to decide if this should be part of the existing specification
> >>  (means we
> >>  have to go back to Working Draft), or should it be addressed in a
> >>  separate document that focused just on transport (current focus of
> >>  TC).Some influence should be considered from issues 14, 15, and 28
> >>  as well.
> >>
> >>  d) System-Specific Uses (Issue 12): Questions and comments around how
> >>  system specific things should be communicated within CAP. For
> >>  instance,where it is "safe" to return a system-specific error code
> >>  that is not
> >>  standard across all uses of CAP?
> >>
> >>  e) Implementer's Guide (Issues 13 through 15): These are things that
> >  > seem to be most appropriately addressed in the Implementer's Guide
> >>  thatis to be written per our charter. It is necessary to help
> >>  implementersunderstand how to support CAP and use it in various
> >>  environments. Some
> >>  influence should be considered from issues 9, 10, and 28 as well.
> >>
> >>  f) Unsure (Issues 16 through 21): This is a collection of issues that
> >>  require discussion to determine their relevance for inclusion in
> >>  the CAP
> >>  standard
> >>
> >>  g) Editorial and Ambiguity (Issues 22 through 28): These are places
> >>  where the spec just doesn't seem to be clear on what the TC intents.
> >>  Also, places where there could be some editorial clarification that
> >>  doesn't change the spec.
> >>
> >>  Here are the details of these buckets.
> >>
> >>  [GEOSPATIAL]----------------------------------------------------
> >>  1. How to treat an <area> with no geospatial or <geocode> elements
> >>  in a
> >>  CAP message? How best to define <geocode>? Should <geocode> be limited
> >>  to FIPS, SAME, and zip code?
> >>
> >>  2. Spec Document is silent on the format of polygons coordinate pairs:
> >>  should it be in long/lat order or lat/long?
> >>
> >>  3. Geographic targeting codes: The <geocode> element, which was
> >>  includedto provide backward compatibility with existing systems
> >>  (notably EAS and
> >>  NOAA Weather Radio, but also many local systems) also adds a bit of
> >>  complexity. It seems possible that in an ideal world all areas
> >>  would be
> >>  in pure geospatial terms (<polygon> and <circle>) but that may be
> >>  a leap
> >>  too far ahead of the current state of the art to allow update of the
> >>  standard. In the meantime, one suggestion has been to restrict the use
> >>  of <geocode> to certain well-known coding schemes... although it's
> >>  beenargued that doing so could create a barrier to adoption in
> >>  existingsystems that use their own predefined alerting or response
> >>  zones.
> >>
> >>  4. How to cover cases where the sender doesn't have GIS or <geocode>
> >>  data readily available?
> >>
> >>  5. The interface spec will have to declare what representation
> >>  format it
> >>  wants for values in degrees. If it wants geographic data supplied in
> >>  decimal degrees, then it should state that; if it wants it
> >>  <sign>DD.MMmmm, then it should make that clear. Alternatively a
> >>  separatesolution would have to be designed if multiple
> >>  representation formats
> >>  are permitted.
> >>
> >>  [TRANSFORMATIONS]--------------------------------------------------
> >  > --
> >>  6. Protocol is too vague to allow for automated mapping of CAP
> >>  messagesinto other, existing systems. How to address the issue of
> >>  automaticallytranslating a CAP interface in the case of
> >>  specialized pre-existing
> >>  alerting and warning systems?
> >>
> >>  7. How to support captioning and text-to-audio applications?
> >>
> >>  [TRANSPORT]----------------------------------------------------
> >>  8. How to reconcile characteristics of a certain transport network
> >>  withthe capabilities of interoperability standards such as CAP? A
> >>  much more
> >>  intelligent architecture than currently provided for routing is
> >>  necessary.
> >>
> >>  9. Compatibility with existing systems.
> >>
> >>  10. Application of CAP in broadcasting (one-way communication medium).
> >>  CAP must state exactly how one-way communication media should
> >>  embed URI
> >>  referenced data within the alert message. Current CAP specs rely
> >>  on the
> >>  ability of the receiving device to retrieve binary content, which is
> >>  impossible over a one-way broadcast link. Proposed solution is to
> >>  provide an explicit optional mechanism for including binary content
> >>  encoded as text within CAP XML message, accompanied by
> >>  restrictions on
> >>  when that option should be used.
> >>
> >>  11. From a standards perspective, what is the correct way to
> >>  process and
> >>  therefore support CAP messages? Is there enough information in the CAP
> >>  specifications to tell target implementers how to implement the
> >>  standardand share CAP alerts?
> >>
> >>  [SYSTEM-SPECIFIC
> >>  USES]----------------------------------------------------
> >>  12. Addition of fields to CAP in order to allow the receiving
> >>  device to
> >>  generate an EAS activation based on a CAP message.
> >  >
> >>  [IMPLEMENTER'S
> >>  GUIDE]----------------------------------------------------
> >>  13. Categorization of threats: The SC having tried unsuccessfully to
> >>  locate or devise a taxonomy for threats which satisfied them as being
> >>  both broad enough and specific enough to be useful in automated
> >>  processing in all-hazards applications, the current committee
> >>  draft has
> >>  the <event> element as optional. Some implementers have expressed a
> >>  desire for a reliable (i.e., required) way to categorize messages
> >>  according to threat.
> >>
> >>  14. How to support attachments (audio files, images, etc.)? Must
> >>  the CAP
> >>  message always be in a SOAP message to transmit attachments?
> >>  Current CAP
> >>  spec offers no specifications as to how binary representations of rich
> >>  presentation media can be transmitted over broadcast media.
> >>
> >>  15. CAP Alert content and the RSS feed format. More generally, the
> >>  ideaof getting a "short list" of alerts to see before requesting
> >>  the whole
> >>  alert.
> >>
> >>  [UNSURE]----------------------------------------------------
> >>  16. Categorization of responses: The committee draft doesn't
> >>  attempt to
> >>  encode responses into categories, but some implementers have
> >>  expressed a
> >>  desire to be able to automatically slot the recommended response
> >>  <instruction> into one or more machine-readable (i.e., coded)
> >>  categories. Should this be part of the current CAP or future versions?
> >>
> >>  17. ISO code royalty: The current spec provides for use of ISO
> >>  languagecodes to identify multilingual versions. ISO has recently
> >>  asserted an
> >>  interest in collecting royalties for use of those codes (among
> >>  others)... this is a subject of debate internationally
> >>  (http://xml.coverpages.org/ni2003-09-20-a.html). Unless this issue is
> >>  resolved very shortly, some disclosure of this issue probably
> >>  needs to
> >>  be included in the specification document.
> >>
> >>  18. Name attributes in schema: Anonymous data types seem to cause
> >>  troubles with some parsers. It's been suggested that the schema
> >>  ought to
> >>  provide explicit name attributes in <simpleType> declarations. Related
> >>  to the same question, should these attributes be declared globally
> >>  rather than locally? Looking at the items, they could certainly be
> >>  reused in other parts of the spec, and could be imported to other
> >>  specsas well.
> >>
> >>  19. The existing CAP spec is not really a protocol - it is a
> >>  format. It
> >>  should really be referred to as Common Alerting Format, and
> >  > potentiallyhave a sibling standard called Common Alerting
> >>  Transport - together they
> >>  create the Common Alerting Protocol.
> >>
> >>  20. Units of Measurement: The OCG has a document (based on ISO) that
> >>  provides an XML schema for expressing UoM in a consistent and easily
> >>  interpretable (processing) manner. The CAP group might consider using
> >>  this OGC recommendation.
> >>
> >>  21. "area" Element and Sub-elements: As with Info element and Resource
> >>  element, it would be nice to have an optional slot for a URL/URI (such
> >>  as to an http request - like an OGC WMS request or a repository of
> >>  additional spatial information). What is the purpose of the additional
> >>  spatial information?
> >>
> >>  [EDITORIAL and
> >>  AMBIGUITY]----------------------------------------------------
> >>  22. Having multiple blocks within a single message as opposed to
> >>  different messages with single blocks in multiple messages and its
> >>  relation to the "rule of primacy."
> >>
> >>  23. Improvements can be made to the general schema design. For
> >>  example,there is no common format describing "altitude". If such a
> >>  format is
> >>  available, we should define the schema (using the <restriction> and
> >>  <pattern> elements) to support it. "string" leaves it wide open.
> >>
> >>  24. Use Cases and Examples: They should be in the same section of the
> >>  document. More importantly, the examples do not speak to the use cases
> >>  listed.
> >>
> >>  25. Editorial comments: The Data Dictionary section does not
> >>  provide for
> >>  SHOULD, MAY, MUST guidelines for implementers, which causes ambiguity.
> >>  "eventCode" is a good example.
> >>
> >>  26. CAP makes heavy use of the word "warning", which seems odd
> >  > given it
> >>  is the Common Alerting Protocol. Should it say alerting instead?
> >>  What is
> >>  the difference between an alert, a warning, and a notification?
> >>  Documentshould be consistent in the use of these terms. Document
> >>  should also
> >>  define those terms in order to clarify their use.
> >>
> >>  27. elementFormDefault = "qualified". Document should mention why.
> >>
> >>  28. Should CAP be a public warning protocol only or also be used for
> >>  targeting messages between entities? In the latter case, what fields
> >>  should be designated mandatory in order for the recipients to
> >>  understandthat the messages was/was not intended for them? The use
> >>  of text fields
> >>  and fields designated as optional represent limiting factors.
> >>
> >>  Walid
> >>
> >>
> >>  To unsubscribe from this mailing list (and be removed from the
> >>  roster of the OASIS TC), go to http://www.oasis-
> >>  open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
> >>
> >
> >
> >To unsubscribe from this mailing list (and be removed from the
> >roster of the OASIS TC), go to
>
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
oup.php.
>
>
> -- 
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>
>
>