MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] IFSC was: RE: [emergency-msg] Any word from Jamie? Notes.
Kon,
Your points are well taken. I will use your input & those from Rex to
layout the IF SC strategy and timeline.
Regards,
Tom Merkle
CapWIN: www.capwin.org
Phone: (301) 614-3720
Cell Phone: (240) 375-1966
Fax: (301) 614-0581
e-mail: tmerkle@capwin.org
CapWIN
6305 Ivy Lane Suite 300
Capital Office Park
Greenbelt, MD 20770
-----Original Message-----
From: Kon Wilms [mailto:kon@datacast.biz]
Sent: Wednesday, August 18, 2004 1:51 PM
To: Tom Merkle
Cc: emergency@lists.oasis-open.org
Subject: Re: [emergency] IFSC was: RE: [emergency-msg] Any word from
Jamie? Notes.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]