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

[Art Botterell <acb@incident.com>]

At 7:44 PM -0400 7/16/03, Allen Wyke wrote:
>On Wed, 2003-07-16 at 08:17, Art Botterell wrote:
>  > 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.

I'm not sure I agree either that it's difficult or that it's out of 
scope, especially since it's so simple to address (by providing space 
for a digest) within the message format and so much harder to solve 
it anywhere else.

>Technically, I can hack into the system and send a
>100% false CAP message too - with or without an attachment.

Which is why we provide for digital signatures on CAP messages. 
Anyway, security is never an absolute... but that doesn't mean we 
shouldn't do what we can, especially when there are well-known and 
inexpensive techniques available.

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

Of course, one of our original requirements for CAP was that be 
usable over one-way (e.g., broadcast) transport mechanisms as well as 
bidirectional links like Web services.  It would be nice if we could 
restrict the problem space to fit our preferred technologies, but the 
world that emergency management serves is larger even than the 
Internet.

- Art