No objections here.
Rick
----- Original Message -----
From: <>
To: "CONSULTRAC" <>
Cc: <>
Sent: Friday, October 17, 2003 9:22 AM
Subject: Re: [emergency] CAP-related Comments
> I agree as well. I would even go so far as to suggest we do not tweak it
at all, and send as-is. That prevents us from having to revote on even a
slightly edited version. Unless there are any objections, we can make a
final decision on Tuesday.
>
> ----- Original Message -----
> From: CONSULTRAC <>
> Date: Thursday, October 16, 2003 3:16 am
> Subject: Re: [emergency] CAP-related Comments
>
> > After consideration, I agree with Rex's process suggestions.
> >
> > Rick
> > ----- Original Message -----
> > From: "Rex Brooks" <>
> > To: <>; "Walid Ramadan" <>
> > Cc: <>
> > 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, 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 <>
> > > >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_workgroup.php.
> > >
> > >
> > > --
> > > Rex Brooks
> > > GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> > > W3Address: http://www.starbourne.com
> > > Email:
> > > 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.>
> > >
> > >
> >
> >
> > 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_workgroup.php.
>
>
>
