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

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

On Thu, 2003-07-17 at 16:29, Art Botterell wrote:
> 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.

My issue is that this is a "transport" issue and not a "body" issue - not about how hard, easy, difficult, etc.

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

I am not disagreeing it is not an issue, its just that how to encrypt, sign, compress, etc. issues are not about the data - they are about how they are transported. There are other standards, such as ebXML, SOAP, etc. that handle the transport. The moment we start to try and solve transport issues, we prevent real transport standards from working. We create the situation where they overlap, which then hinders or even prevents adoption, which we can not do.

I feel like you are saying I am implying this is not an issue, which I am not. I am just saying this issue is, and should be, solved elsewhere. And we even had an SC (IF SC) that whose charter it is to help in this area.

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

But it is usable - even without attachments. Its just not usable in the scenario brought up at the F2F. To determine the impact of that use case, especially this late in the game, you guys simply determine the benefit of adding and compare that with the impact of adding it.

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

Its not about restricting the problem space - its about targeting the largest target audience that will adopt our standards. Our mission to create standards that can be adopted, and in this particular case there are two schools of thought. One where it increases our adoption, and another where it is thought it will actually reduce the adoption. That is what needs to be figured out.

The way to resolve the URI issue, which is different than the encryption issue (although related), is simple. It lies in 2 questions:

1. What is our potential adoption rate increase/decrease by including/not including attachments?

2. If the adoption rate shows a significant enough increase, then what is the best way to handle the one-way use case?

Ok TC, thoughts?

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