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

["Kon Wilms" <kon.wilms@ndsamericas.com>]

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