OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency-comment] comments on CAP draft standard


Friends -

Herewith a few notes on the attached comments submitted to the public 
comment list by David Aylward of the ComCARE Alliance.  (Regrettably 
I wasn't able to address these issues in sufficient depth before 
leaving ComCARE.)

In short, I believe all the capabilities David asks for are already 
available in the CAP format.  However, I'd appreciate any thoughts 
from other members of the Subcommittee, especially on the specific 
requests:

>Section 2.2 Requirements for Design
>
>	We request that you add new lines 7e and 7f, after line 219:
>
>e. Target category(ies) of agency or organization
>f. Target category(ies) of event and/or information interest (i.e. 
>based on the event types for which the standard already provides, or 
>subsets of them).  

Until now CAP hasn't really been designed with the restricted 
transmission of sensitive information in mind.  I'm not sure whether 
that's an appropriate expansion of the mission of CAP or not... I'll 
leave that question to the SC and the TC.

Anyway, it's important to remember that, while a CAP message can 
represent any  addressing or restrictions the sender cares to assert, 
it can't ensure that every network and node it traverses will respect 
them.  The only ways I know reliably to control access to XML 
messages are, a) by sending them only over trusted private (or 
virtual private) networks linking only trusted nodes, or, b) by 
applying XML message encryption.  Both those techniques are 
implemented at different layers of the protocol "stack" than that of 
the CAP message format itself.

(In the Security Note, section 3.3.3, we recommend the OASIS 
WS-Security framework for XML message encryption and other security 
services, although other methods may be preferred in some 
applications.)

That said, it seems like the existing <restrictions> and <addresses> 
elements (in concert with an appropriate value for <scope>), and also 
the <eventCode> element, offer the means for asserting the kinds of 
selectivity requested.

>Section 3.1 Document Object Model
>
>	It appears from the final box in the chain that the only 
>targeting/addressing mechanisms for a CAP message are geographic and 
>a limited number of summary event types.  These are critical.  We 
>respectfully suggest that two further targeting/addressing 
>selections be allowed: agency or organizational type (e.g. law 
>enforcement, school), and specific informational interest expressed 
>by recipients, in effect subsets of the current event types.

The <source>, <restrictions>, <addresses> and  <code> elements in 
<alert> and the <eventCode> element in <info> exist solely to provide 
a flexible capability for targeting assertions in non-geospatial 
terms.

>Section 3.2 Data Dictionary
>
>	To carry out our suggestions, we suggest that two further 
>optional fields be included:
>
>(a) in "cap: category", allow the addition of more detailed subsets 
>of events.  Thus, for example, within the general category of 
>"Safety" there could be a subset of "Amber Alert".

That's the function of the <eventCode> element.  For example, in the 
current version (0.9a1) of the spec, in Appendix A.4 (the example 
AMBER Alert), that very example is implemented thus...

		<eventCode>same=CAE</eventCode>

   ... where "CAE" is the FCC's designated EAS/Weather Radio (SAME) 
code for "Child Abduction Event".

>(b) in or after "cap: audience", allow the addition of specific 
>organizational or agency type.

That could be included within the existing free-text <audience> 
element, of course.  But then it would apply only to the immediate 
<info> block, which might be one of several in a CAP message.  So I 
think using the <restrictions> or <addresses> elements in the overall 
<alert> structure might be a better choice for expressing this sort 
of routing preference.

In summary, I think the capabilities ComCARE requests are already 
provided... insofar as they can be implemented by a message format 
alone.  But even though we've tried to keep the CAP format simple, 
clearly it's already complicated enough that the answers to certain 
questions aren't always obvious.  So I've started assembling an FAQ, 
which I'm sure will be fleshed out considerably during our next round 
of trial implementations.

- Art

ComCARE_Cmmnts_CAP_0.9.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]