Re: [emergency] IFSC was: RE: [emergency-msg] Any word from Jamie?Notes.

[Kon Wilms <kon@datacast.biz>]

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.