RE: [emergency-msg] cap:image and cap:audio

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

On Wed, 2003-07-16 at 08:17, Art Botterell wrote: 
> At 10:28 PM -0400 7/14/03, Allen Wyke wrote:
> >...would the following not be true:
> >
> >If a resource is static (ie: you do not want it to change), then the
> >sender of the CAP message MUST include the resource on a server they
> >control, and can therefore also control the security of that server -
> >its "trusted."
> 
> It's not hard to imagine a scenario under which an issuing agency 
> might want to use a resource served from another agency: e.g., a 
> local emergency management agency might issue a post-earthquake 
> advisory that says something like, "if the ground shaking in your 
> area was strong (areas shown in yellow or red on the USGS 
> shaking-intensity map) then you should inspect your building 
> foundations immediately and check carefully for gas leaks," with the 
> referenced image being a shake map served from a USGS server.
> 
> And even with a "trusted" server there's always the possibility of 
> accidental (or even malicious) changes occurring on the server after 
> the referencing message is issued.

Correct, but that is a different problem and one that is outside of the
scope of our work. Technically, I can hack into the system and send a
100% false CAP message too - with or without an attachment. 
> >If the resource is dynamic (ie: you want to point to the latest and
> >greatest), then all you really can do is point to it.
> 
> True.  Or the sender might not consider the referenced content 
> critical enough to bother with a digest.  Which is why the digest 
> would be optional.

My original statement was not in regards to a digest here - just that
their motive might be for the latest and greatest. 
> >That being said, maybe the solution is to put in an attribute that
> >specifies if the resource is external (not in my network/control) or
> >internal (default, but can explicitly state it is in my
> >network/control).
> 
> Problem is, asserting that the resource is external just raises 
> doubts without providing any way to resolve them.  

URI is the way to resolve. It can then be a URL or a URN, and we can at
least say the majority % of implementations (100% if we recommend Web
Services as the transport mechanism) will support this kind of
resolution, because at some point in the process, the CAP sender or
receiver will have to send or receive the message from some
URI-addressable server.

> A digest of the 
> asset can be used to determine directly whether the received asset is 
> the same one the sender meant to reference... which is what we really 
> care about... regardless of how or whence it was delivered.
Yeah, I don't disagree, but again my original comments were in regards
to referencing resources, not the need or importance of digests.

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