Re: [emergency-msg] Re: [emergency-comment] comments on CAP draftstandard

[Allen Wyke <emtc@nc.rr.com>]

On Thu, 2003-07-31 at 23:45, Art Botterell wrote:
> >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.

I completely agree with your comments here. I would further point out
that agency and organizations, specifically, are really nothing more
than properties of a given user/targeted message receiver, and that as
such targeting on these should be handled by the implementation, rather
than in CAP. Maybe, if it is even needed, there is a compromise longer
term, but let's walk before we run and understand more about what the
implementations need to be successful.

Looking at event and/or information interest, the same applies. This is
information that should be maintained by the system sending the CAP
message, not contained in the message itself.

> >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".

Personally, as you know, the jury is still out with me on the issue of
incident types one. However, I am going to hold off that discussion for
this thread until we get CAP to the Committee Specification state. If it
is needed by the public, we will know soon enough. At the same time, if
the IF SC is seeing more and more cross-standards efforts, then we may
want to consider that. Enuff of that for now :)

> 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.

Excellent idea! In fact, and you may have gotten this as well, OASIS is
going to start including an FAQ link on each TC's site. That being said,
this group needs to think about where the best place is to put this
information. Should it be in an FAQ, the standard itself, an
implementor's guide, or all of the above? My guess is that the answer
will probably present itself as we go through the testing and public
review.

Allen

> 
> - Art
> 
> ______________________________________________________________________
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency