Re: [emergency] Re: [emergency-comment] RE: Content ( was RE: [emergency-comment] RE: [CAP] RE: CAP-list digest...)

[R. Allen Wyke <emergency-tc@earthlink.net>]

On Mar 23, 2004, at 2:11 PM, Kon Wilms wrote:

> Couldn't it be argued that an implementation has to at least do 'some 
> work'?

There is plenty of work the implementation has to do - no doubt about 
that. But much like an accountant that has to follow the IRS rules, 
these rules should make a valiant effort to remove ambiguous areas. 
That allows implementers to not start at square 1, but rather start 
where you can get into the real down and dirty details of implementing 
a standard.

> A standard isn't defined by its ability to transparently cross all 
> protocol,
> interface, and transport boundaries. Thats shooting too high, and any 
> such
> attempt to tie all these aspects together is doomed to failure.

I do not disagree with that statement at all, nor does anything I have 
said convey such a statement. A standard is, however, defined by its 
level and scope of adoption, which has a direct correlation with the 
clarity in which it approaches it target implementer/market.

> I see no problem with having to implement connectors. Its just part of 
> the
> natural cycle of interfacing to external systems.

That is because your world of possibilities is limited. You would not 
say that if you had to interface with 1000 systems. Just the overhead 
of keeping track of each of the alert suppliers, let alone the 
programming involved can kill anyone. The reason we have a standard, 
which is to consolidate these 1000 (and I wish it was only 1000) types 
of alerts into a single format and method to exchange. Doing so means 
that any implementation, be it mine, yours, or whoevers, can actually 
and honestly exchange alerts. It is not unlike how a gazillion Web 
pages are exchanged and rendered in various browsers. Sure, there are 
some subtle differences, but its not a bunch of one-offs for each Web 
page.

> I don't think anyone on my
> team even batted an eyelid when this subject came up -- just implement 
> a
> protocol/interface aggregator and expand its connectors as required.

Yeah, but how does the CAP message get into your system or come from 
whatever the case may be? While I am sure I can take a guess or two and 
get it right at some point, that is not the point - guessing. guess != 
standard, and therefore it starts to feel more like a proprietary 
approach to implementing an agreed upon set of elements.

> Cheers
> Kon
>
> -----Original Message-----
> From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
> Sent: Tuesday, March 23, 2004 8:19 AM
> To: 'Art Botterell'
> Cc: Emergency TC
> Subject: [emergency] Re: [emergency-comment] RE: Content ( was RE:
> [emergency-comment] RE: [CAP] RE: CAP-list digest...)
>
>
> Hate to say it, but Bob is right. For anyone trying to support CAP
> messages from various sources, it is impossible, in the current state
> of CAP, to do so in any kind of standard method. You have to build a
> bunch of one-off connectors to handle the different implementations. We
> "stood silent" on so much, that people are all using it differently.
> While that may seem like a good thing to some people, it is not.
> Differently != Standard. Basically, CAP is not a protocol. It is a
> grouping of elements of like purpose to reflect a format.
>
> Allen
>
> On Mar 5, 2004, at 8:30 PM, Bob Wyman wrote:
>
>> Art Botterell wrote:
>>>> At 5:29 PM -0500 3/5/04, Bob Wyman wrote:
>>>>  ... the CAP specification *DOES NOT* tell me where to put them if
>> I
>>>> am trying to pass a CAP message without SOAP.
>>> That's right, it doesn't.... And after discussing this very
>>> question at some length a number of months ago, the members
>>> of the TC decided that it lay outside the scope of the CAP
>>> spec and more properly in the scope of specifications for
>>> a particular transport context.
>> 	So, what you're saying is that CAP *does not* provide any
>> mechanism or facility for doing authentication of messages in a manner
>> which is independent of the transport mechanism. If you want signed
>> messages, you must use a transport, like SOAP, that supports signed
>> messages. Thus, the odd mention of WSSE in the specification is really
>> just a non-normative hint to users of SOAP which reminds them that
>> they can use SOAP to transport and sign CAP bodies. CAP itself,
>> doesn't deal with the issue of signing CAP messages nor does it deal
>> with encryption.

--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net