[CAP] CAP 1.2

[Mick Jagger]

Hi,
	I had suggested before that a CAP 1.2 release was in order as part of the CAP 2.0 discussion.  Here are my suggestions for changes/additions to CAP 1.2 with the goal of the 1.x series being backward compatibility, while 2.x would not.  This list is minor housekeeping changes that could comprise 1.2, I have a list of more extensive changes/updates that will follow.

1. Create a new paragraph on CAP index formats in the introduction.  Specifically caution against use of unrelated info segments as an index.

2. Update the area block section in the introduction to clarify the use of area blocks as defining the target audience/area and mention filtering uses.

3. Remove the Note at the top of the Data dictionary allowing null values.  There is nothing worse than getting a message with a null identifier or sender or info/event.  I've seen this happen numerous times.  These required fields should not be null.

4. references element description - Include note that all earlier messages within a references chain should be included to keep the full scope of the incident available.  This also goes for ref chain merges.

5. incidents element description - Update to include a better discussion about the differences between references and incidents.  Also update the currently undefined format to something more specific.  I suggest something like the following "system,access"  The "system" is the method used to access the incident data.  For a starting list I would suggest just "internet".  However as future CAP message collation and exchange systems come online such as DM-OPEN, they can also be added to this list.  The "access" is the info required to access the incident data.  So a URL for the internet system or an incident ID for a CAP message exchange/broadcast system, etc.

6. event element description - Update the event element to have a size limit.  The event element is ideal as an end-user display value in a list of alerts.  Its also useful for composing short message summaries (TXT for example) when combined with areaDesc and other values.  I suggest a limit of 50 characters.

7. responseType element - As Art has already suggested an "Avoid" value should be added.

8. area/circle element description - Update the description to disallow the use of 0 as a radius.  0 has been used to describe a "point" value, an example of which is actually in the CAP spec, but point values are not valid geometry elements of an area block.  This is a little cheat to accomodate a drawback of CAP which causes real problems for systems that use area filtering.  There is a better solution for those using "points" and I'll describe it in detail in my next message.

-- 
lists at jpw.biz
--