MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] CAP Visualization (was RE: CAP Developers'Forum...)
Hi Jeff,
There are a couple of ways I see that this can be handled. For the
immediate time being one can resort to out of band methods for
ensuring that the CAP feeds one arranges to receive by such out of
band agreements include <eventCode> as tedious as that might be. You
can also handle that by the stipulations you make in your security
policy using SAML and XACML. At the same time, by bringing it up in
the TC as a feature request for CAP 1.x-2.0 we can ask that it be
made a required field for a specific CAP provider profile within a
registration context which we can establish for that purpose. One of
the specific reasons for establishing an XML basis for a CAP message
type is to take advantage of the ability to make a subset or superset
of the basic spec. By providing a specific registration procedure for
different kinds of systems such as broadcast and web service
delivery, providers, intermediaries and receivers of CAP messages can
more easily connect up with each other for this purpose. For web
services we can do this through WSDL in ebXML or UDDI Registries and
in practice through encrypted, signed SOAP messages. We can do this
now by building it into the message brokers we use and just insisting
that our partners support it, or find themselves unable to use our
offerings. That's not very feasible this early in the process of
promoting adoption, but it is one way to do it.
Another thing just occurred to me. As part of an effort to establish
trusted networks, it would be wise to avail ourselves of an aspect of
the API services DMIS provides, and ask for some special
functionality to filter messages by how <eventCode> is handled, or
not. We are going to have a lot of issues like this, so we might as
well start tackling them now.
Ciao,
Rex
At 7:12 PM -0500 5/19/04, Jeff Kyser wrote:
>Hey Kwasi,
>
>Since <event> is a required field (of an <info>) but is
>free text, and <eventCode> is optional and
>system-specific, we're not left with much if we want
>to filter messages based on event, are we?
>
>oh well.
>
>-jeff
>
>On Wednesday, May 19, 2004, at 05:45 PM, Speede, Kwasi wrote:
>
>>Jeff,
>>
>>Yes, we "fell back" on processing against system-specific <eventCode> values
>>in the broker. <Event> was not appropriate for our purposes because multiple
>>instances cannot be defined for a single message scenario.
>>
>>I am curious about the different approaches that are evolving or being
>>proposed for determining who are the authorized CAP message originators
>>across various implementation communities and how developers are intending
>>to authenticate their messages when processing CAP. This topic would be a
>>great addition for the implementers guide!
>>
>>Thanks all,
>>
>>Kwasi
>>
>>