[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Re: [emergency-comment] Fwd: CAP Implimentation inCompassLDE
Rex et al : Great ... If you wish to progress this further - I believe the next (protocol) step would be for this TC and the ebXMLRegistry TC to review a discussion document that would be jointly presented at the next meeting of the e-Government TC (phew !!). have a nice weekend carl <quote who="Rex Brooks"> > Thanks Carl, > > I'm also a member of the eGov TC and I have a great interest in this > pilot project because it has the potential to add that > "international" component to the range I spoke of in my message. This > week, I learned in the course of Farrukh Najmi's brief presentation > on ebXML Registry Note for WSRP Thursday, that XACML is implementable > via ebXML Registry. That makes the issue of developing "trust > networks" with role-based access provisions via that mechanism > possible in an interoperable way now. That answered a particular > question I had as I explored WSS and WS-I Basic Security Profile, > since it seems very likely that role-based access is one requirement > I think the EM community will have in addition to propagating userid, > establishing secure channels, non-repudiation, encrypting message > payloads, etc... > > Ciao, > Rex > > Thanks, and I will look into liaising with you on this, if you're > interested. > > At 9:31 AM -0400 8/6/04, Carl Mattocks wrote: >>Rex et al : >>It may be possible to address these requirements as an extension of the >>joint E-Government / ebXMLRegistry Tc effort that aims to publish best >>practices around collaborative development of content. >> >>finest regards >>Carl Mattocks >> >><quote who="Rex Brooks"> >>> Thanks, Allen, >>> >>> It looks like the time has come to address this overall issue. I >>> uploaded a general presentation on WSS, borrowed from the WSRP TC >>> which is one of several areas of concern that all intersect in this >>> specific issue of establishing trust networks. In this case the area >>> is web services. In line with the various transport-specific >>> requirements, we might want to consider gathering requirements for an >>> EM-specific registry, especially in the context of developing the >>> message-wrapper for setting context(s). A great deal of work has >>> already been done in ebXML and UDDI, so we are far from starting from >>> a zero point. >>> >>> I was going to upload the presentations and discussions we have been >>> having this week for related issues in security in the WSRP meetings, >>> but they have gotten too specific to be valuable in a more general >>> context, let alone in narrowing back down to a CAP-specific >>> discussion, and we still have one more today. However, it has been >>> instructive. >>> >>> An EM Registry need not be web-only, but could have sections per >>> transport mechanism with recommendations for how to organize it to >>> list a registrant's organizational capabilities, memberships, >>> protocols/standards supported, etc. While that approach might entail >>> multiple or repeated entries where an organization spans transports, >>> it could be organized in such a way as to make establishing trust >>> relationships reliable without having too great an overhead cost. >>> >>> Regardless, such a registry would need to have the support and >>> cooperation of the governmental jurisdictional authorities from the >>> local to the international levels, but the movement toward >>> cooperation in these areas appears to be favorable, for now at least. >>> >>> Ciao, >>> Rex >>> >>> At 6:52 AM -0400 8/6/04, R. Allen Wyke wrote: >>>>Note that I moved this discussion over to the TC thread and took it >>>>off the Public Comment list. >>>> >>>>Also, please notice that what JD is asking is not "what's possible", >>>>but rather "what's official". >>>> >>>>On Aug 5, 2004, at 8:08 PM, David Aylward wrote: >>>> >>>>>Claude: >>>>> >>>>>Yes, but not yet in the best way, integrating the data flow into and >>>>> out >>>>>of the CAD system. Obviously that requires an interface with the CAD >>>>>system, which we are looking forward to doing soon. >>>>> >>>>>David Aylward >>>>>Director >>>>>The ComCARE Alliance >>>>>888 17th St., N.W. >>>>>Washington, DC 20006 >>>>>202-429-0574 Extension 247 >>>>>202-296-2962 (fax) >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com] >> >>>Sent: Thursday, August 05, 2004 5:16 PM >>>>>To: David Aylward; R. Allen Wyke; >>>>> emergency-comment@lists.oasis-open.org >>>>>Cc: jdm@compasscom.com >>>>>Subject: RE: [emergency-comment] Fwd: CAP Implimentation in CompassLDE >>>>> >>>>>Has that been tried with the 911 systems in your membership >>>>>areas? >>>>> >>>>>len bullard >>>>>intergraph public safety >>>>> >>>>>-----Original Message----- >>>>>From: David Aylward [mailto:daylward@comcare.org] >>>>>Sent: Thursday, August 05, 2004 3:51 PM >>>>>To: R. Allen Wyke; emergency-comment@lists.oasis-open.org >>>>>Cc: jdm@compasscom.com >>>>>Subject: RE: [emergency-comment] Fwd: CAP Implimentation in CompassLDE >>>>> >>>>> >>>>>There are a number of ways to do this, but the architecture our >>>>> members >>>>>have developed and trialed in the field with CAP assumes that: >> >>> >>>>>1. any emergency agency (broad definition of "agency") can initiate a >>>>>CAP message (down the road there will need to be some rules about >>>>> that) >>>>> >>>>>2. either the initiating application, or a message broker serving it, >>>>>either has the addresses (a local system), or queries a directory for >>>>>the electronic addresses of agencies which have registered to receive >>>>>it, and then transmits the message >>>>> >>>>>3. one example of such a directory is the Emergency Provider Access >>>>>Directory (EPAD) we are putting together, helped by a DOJ grant. >>>>> There >>>>>agencies register who they are, what service they provide, what >>>>>incidents they want to hear about, the geographic area(s) of their >>>>>incident interest, and the address(es) to which they want data sent. >>>>> >>>>>4. Thus, for example, each client agency of yours would register the >>>>>CompassCom electronic address for the incident types it wanted to >>>>>receive for its area. >>>>> >>>>>5. Message initiators would not need to know recipient agencies. >>>>> >>>>> >>>>>We put a short Flash on our website (www.comcare.org) to illustrate >>>>>this. The link is on the left hand column of the website's front >>>>> page. >>>>> >>>>> >>>>>David Aylward >>>>>Director >>>>>The ComCARE Alliance >>>>>888 17th St., N.W. >>>>>Washington, DC 20006 >>>>>202-429-0574 Extension 247 >>>>>202-296-2962 (fax) >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: R. Allen Wyke [mailto:emergency-tc@earthlink.net] >>>>>Sent: Thursday, August 05, 2004 1:30 AM >>>>>To: emergency-comment@lists.oasis-open.org >>>>>Cc: jdm@compasscom.com >>>>>Subject: [emergency-comment] Fwd: CAP Implimentation in CompassLDE >>>>> >>>>>Good question JD. I have forwarded this to the EM TC Public Comment >>>>>list. >>>>> >>>>>Begin forwarded message: >>>>> >>>>>>From: "J.D. Main" <jdm@compasscom.com> >>>>>>Date: August 4, 2004 12:35:59 PM EDT >>>>>>To: emergency-tc@earthlink.net >>>>>>Subject: CAP Implimentation in CompassLDE >>>>>>Reply-To: jdm@compasscom.com >>>>>> >>>>>>Allen, >>>>>> >>>>>>CompassCom plans to add the CAP message to our API and thus >>>>>>make our Mobile Asset Tracking product line "CAP Compatible" I >>>>>>understand the format and purpose of the CAP message. I am a bit >>>>>>fuzzy on where they would come from in a real implimentation. In a >>>>>>real sense, I must set up a CAP listener - who is broadcasting? Is >>>>>>there a process of registering an implimentation of my application >>>>>with >>>>>>those agencies who would broadcast a CAP message? My apologies >>>>>>if these questions seem basic, but I have not discovered any >>>>>>documentation to clear this up. >>>>>> >>>>>>Please let me know what you think. >>>>>> >>>>>>Best Regards, >>>>>> >>>>>>J.D. Main >>>>>> >>>>>>CompassCom, Inc. >>>>>>6770 S. Dawson Circle, Unit 1A >>>>>>Centennial, CO 80112 >>>>>>PH: 303-680-3221 >>>>>>Fax: 303-766-2488 >>>>>>www.compasscom.com >>>>>> >>>>>> >>>>>>******************************************************* >>>>>>This message is intended only for the use of the Addressee and may >>>>>>contain information that is PRIVILEGED and CONFIDENTIAL. >>>>>> >>>>>>If you are not the intended recipient, you are hereby notified that >>>>>any >>>>>>dissemination of this communication is strictly prohibited. If you >>>>>have >>>>>>received this communication in error, please erase all copies of the >>>>>>message and its attachments and notifyCompassCom, Inc. >>>>>>immediately at solutions@compasscom.com >> >>>>******************************************************* >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>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 >>> >>> 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. >>> >>> >> >> >>-- >>Carl Mattocks >> >>co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC >>co-Chair OASIS Business Centric Methodology TC >>CEO CHECKMi >>v/f (usa) 908 322 8715 >>www.CHECKMi.com >>Semantically Smart Compendiums >>(AOL) IM CarlCHECKMi > > > -- > 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 > > 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. > > -- Carl Mattocks co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC co-Chair OASIS Business Centric Methodology TC CEO CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart Compendiums (AOL) IM CarlCHECKMi
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]