[CAP] CAP 1.2?

[Jim Trawick]

Excellent discussion, Mick(?), but I have issues on a couple of points.

The first is that I believe 2.0 is the appropriate place to start the
discussions. While there may not be "enough" implementers, for those of us
who are, CAP 1.1 contains a couple of basic things that, if changed, would
help us a bunch, and others that would possibly enable a much broader use.

The second is that I also believe we should at least entertain the
possibility that what we have learned so far in this quite embryonic stage
may lead us in a direction that may not be backward-compatible (such as
dropping fields, adding new mandatory fields or making optional fields
mandatory, or rearranging the schema hierarchy), and even tweaks in that
category usually dictate major-revision status.

It's not so much that folks are pushing 1.1 to its limits, but so many of
the major players are "faking" it, because the fields in front of them don't
seem to apply. And the time to make big changes is when the installed
footprint is still small.

Motion is a valuable piece of information in a majority of warnings. Where
the fire is headed is very nearly as important as where it is now, and how
fast it's moving tells me a great deal, as well. Substitute rain, poison
gas, floodwater, plague of locusts or whatever, it's a nice piece of
information to have. Warnings set in the future are hard to handle in the
public sector, which tends to panic early, and berate you later if it
doesn't happen. Frequently all you know is where it is, and where it seems
to be headed. I advocate a probable motion vector, with 3-space direction,
speed and possibly rate of expansion of the hazard, with enumerated units
designators (e.g., "km", "mph", etc.) to support conversion and
international cooperative exchange.

The primary disseminators of warning in both the US and Canada gravitate
toward multipart warnings. We also receive the same warnings from multiple
sources. I don't know that a unique indicator is the answer, but in those
cases, we could use some help to ensure the suppression of duplicate
warnings. Anything that comes out that doesn't require an action only
encourages inaction to the next one.

I strongly oppose replicating information in a message. It gives me two
places to have to look for it, and if it's not the same, which one is right?

In short, we should at least start the discussion at the 2.0 level. If we
find that we don't really need those kinds of changes, then nothing says we
can't entertain renaming it 1.2.

That said, so many things have required at least two major revisions before
they were sufficiently mature to be commonly used (FORTRAN IV, Solaris 2.3,
Apple II+ and Windows 3.1 come to mind). Art's good, but I think that it's
unfair to demand that he be that good.

-----Original Message-----
From: cap-list-bounces at lists.incident.com
[mailto:cap-list-bounces at lists.incident.com] On Behalf Of
cap-list-request at lists.incident.com
Sent: Monday, October 22, 2007 3:00 PM
To: cap-list at lists.incident.com
Subject: CAP-list Digest, Vol 19, Issue 7

Send CAP-list mailing list submissions to
	cap-list at lists.incident.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://eastpac.incident.com/mailman/listinfo/cap-list
or, via email, send a message with subject or body 'help' to
	cap-list-request at lists.incident.com

You can reach the person managing the list at
	cap-list-owner at lists.incident.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CAP-list digest..."


Today's Topics:

   1. Re: Toward CAP 2.0 (Mick Jagger)


----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Oct 2007 14:11:54 -0400
From: Mick Jagger <lists at jpw.biz>
Subject: Re: [CAP] Toward CAP 2.0
To: cap-list at lists.incident.com
Message-ID: <20071022141154.7d39db90.lists at jpw.biz>
Content-Type: text/plain; charset=US-ASCII

> Which is why I'd like to suggest that we on this list... the folks  
> who got the ball rolling in the first place... should take a first  
> stab at some recommendations for the next revision of the OASIS/ITU  
> CAP specification.

I don't think a version 2.0 is what we should be working on.  Version 2
would imply major feature changes/updates and at this stage it would be more
practical to look at tweaks and fixes right now.  So perhaps version 1.2
would be better?

The reason I say at this stage, is because there really aren't enough
implementations out there.  A lot of CAP setups are using 1.0 and very few
sites actually use any of the more advanced features of CAP beyond the
required elements.  If anyone is really pushing the standard to the max and
running into roadblocks and problems, I'd be interested to hear about it and
it would certainly help this discussion.

> 	* responseType: New values needed?

I like the idea about adding "Avoid" to the responseTypes, it would be very
useful.  Maybe replace "Prepare" as that type is one that never gets used.
Anything to do with preparation is usually an "Execute" with Instruction.

> 	* area: How to describe motion?

Motion isn't a suitable value for the area blocks.  It would however be very
useful in resources as a storm-track image perhaps.  The area block is
really the area needing to be alerted.  If you know that 1 hour from now
another area will need alerting, either issue a new alert at that time for
the appropriate area, or include a 2nd info block with the new area and an
Effective/Onset time.  Motion processing logic isn't something that end-user
CAP clients should have to build into their systems.

> 	* info: Need for unique identifiers?

I think unique identifiers adds unnecessary complexity.  The vast majority
of alerts are issued with 1 info segment, maybe 2-3 if additional languages
are used.  If 1 info segment changes and another doesn't, all segments
should still be included in the new alert.  If the receiving system has a
previous alert from the message chain on file, then it can compare them to
find the differences, or if the system is just joining the message chain, it
will all be new information.

> 	* Mandatory and optional elements

I don't think responseType should be mandatory since there a lot of cases
where it will be None and therefore providing no useful information.
However it would be useful to more strongly link some values together
somehow.  For example responseType and instruction, msgTypes Update/Cancel
and references, scope and restriction/addresses, etc.  Because even though
the spec mentions these links, there are still messages being created
without them.  Maybe some big BOLD letters or something.

** Other changes  **

Copying senderName from the info blocks to the alert block would be useful.
Something human readable
and make it mandatory.  Individual info blocks could still have their own
senderName as well.  So for example in the alert block would be "Alert
Agency", which would be the end user displayed name, and if there was an
info block senderName "Bob Smith", it could be appended for end user display
"Alert Agency - Bob Smith".

The alert element incidents could be better defined.

-- 
lists at jpw.biz
--


------------------------------

_______________________________________________
CAP-list mailing list
CAP-list at lists.incident.com
http://eastpac.incident.com/mailman/listinfo/cap-list


End of CAP-list Digest, Vol 19, Issue 7
***************************************