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

[Rex Brooks <rexb@starbourne.com>]

I ended up having to change my mind on this for 1.0, with the 
stipulation (to myself) that I would insist, or try to insist on 
specifying more strict procedures for web services via SOAP, which is 
where I will be working (or so I thought at the time and still do). 
The fact was that the transport agnosticism issue was a real 
showstopper for PPW, and now I actually agree to the extent that I 
think we need to maintain such seemingly anachronistic technologies 
as broadcast radio as well as television as a backup. Real security 
is coming online at a real snail's pace, and I don't want to see us 
hung out to dry if the bad actors acquire the ability to serious 
disrupt the Internet before we can adopt a serious security standard 
or set of standards as seems to be the case.

That said, I do think that as we go into 1.x or 2.0, we do need to 
focus in on specific mechanisms such as SOAP with Attachments,  XML 
signatures, PKI, rigorous identity authentication and specific ebXML 
and UDDI registry policies, and in the Notifications and Messaging SC 
this is going to entail choosing an eventing mechanism, and working 
to keep it coordinated with whatever is decided nationally and 
internationally.

This is at least partially why I think we should step up to the NIMS 
work and use that connection to stimulate more participation in the 
communities that are affected by our work.

Ciao,
Rex

At 11:11 AM -0800 3/23/04, Kon Wilms wrote:
>Couldn't it be argued that an implementation has to at least do 'some work'?
>A standard isn't defined by its ability to transparentlycross 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 see no problem with having to implement connectors. Its just part of the
>natural cycle of interfacing to external systems. 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.
>
>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.
>
>
>***********************************************************************************
>Information contained in this email message is intended only for use 
>of the individual or entity named above. If the reader of this 
>message is not the intended recipient, or the employee or agent 
>responsible to deliver it to the intended recipient, you are hereby 
>notified that any dissemination, distribution or copying of this 
>communication is strictly prohibited. If you have received this 
>communication in error, please immediately notify the 
>postmaster@nds.com and destroy the original message.
>***********************************************************************************
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request