[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] IFSC was: RE: [emergency-msg] Any word fromJamie? Notes.
Hi Folks, I moved this over to the emergency-if list. This sounds straightforward and reasonable to me. I will do my best to get the web services summary with urls to references as well as standards, standards in progress, etc. out to the list over the weekend, and earlier if I can. I will try to get it out tomorrow or Friday, if I can. There's a lot of material to cover, and this is not going to be a glossover even though it will be a summary. Ciao, Rex At 10:51 AM -0700 8/18/04, Kon Wilms wrote: >Tom, > >I don't believe anything will be gained by passing titles around. We >need to produce something concrete as a group and people need to >step up to the plate. > >As other folks have said, there are 3 things to cover - > >1. completing the 'transport models' document > >I believe the current document on current infrastructures and >standards capable of supporting and transmitting CAP should be >shelled out and a end-date set for a first revision. Once existing >mechanisms are documented we can look at what is missing, which I >believe maps to #2 below. > >The nebulous of 'what could be used in the future' is an >unattainable goal and should be dropped from the document. > >I've given input, Rex plans to, who else can? And what is the end >date? I would think we could do a draft by next week or the week >after. I am willing to finish the document if people at least get >some discussion going on the list with defined frameworks, protocols >they use, and method for translating CAP to it, or if not - >implications of use. We should point to specific standards, >implementations, and information - no nebulous data. > >This document should provide a baseline for people taking CAP and >wanting to transmit it on a given medium - 'what protocols and >format should I use for my infrastructure?'. I would think that this >would also help facilitate and accelerate interoperability. > >2. art's edxl framework & fema/eic wrapper model > >#1 and #3 can provide some good building blocks for helping to >define this or some other cap-specific transport transform protocol >or layer, be that related or not. Right now we have no ground to >stand on, so I don't see how we can provide well-informed input into >this process without at least some notion of #1 and #3. > >3. registries, identity, and security reccomendations > >This should follow from #1, with mapping between protocols and >transports and what security methodologies best work on them (i.e. >RSA and symmetric key encryption for one-way). Once again, no >vaporware/nebulous standards. > >I would think that there would be a specific demarcation between the >security methodologies and the registry/identity management >reccomendations, since there is in many cases a 1-n mapping of >management to delivery. > >All of these need a best practices section for each subsection, so >that where in doubt people can make a well-calculated decision on >how to implement their delivery systems. > >Well that's my 2c - any suggestions from other folks? > >Cheers >Kon > >Tom Merkle wrote: >>Kon, >>Since you seem to have an idea on where the IF SC needs to go, I invite >>you to take my position as IF SC co-chair. I have never been associated >>with a black-hole standards group and it is not my intention to start >>now. > >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]