MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Implementation Guide Outline
Title: Re: [emergency] Implementation Guide
Outline
Looks good to me. We need to cover the entire field.
Ciao,
Rex
At 4:42 PM -0700 4/5/04, Kon Wilms wrote:
Since
broadcast is codec-agnostic, maybe:
3 Broadcast
Considerations
3.1
Wired
3.1.1 Local area
3.1.2 WAN/MAN
3.1.3 Internet
3.2
Terrestrial
3.2.1 One-way
3.2.2 Asynchronous
3.2.3 Synchronous
3.3
Satellite
3.3.1 One-way
3.3.2 Asynchronous
3.3.3 Synchronous
3.4 Bridging
& Re-Broadcast
makes more
sense? Video and radio broadcast systems may use the same transport
layer, and may even use the same bird. The difference between one-way
and async is that async has a backchannel, but not a true two-way
connection. Also since broadcast injection frequencly uses IP
multicast, this is also applicable to wirelsss WAN/MAN systems and so
forth, where data can be redistributed or originated (which is where
bridging comes in).
Cheers
Kon
----- Original Message -----
From: rexb@starbourne.com">Rex
Brooks
To: emergency@lists.oasis-open.org
Sent: Monday, April 05, 2004 1:00 PM
Subject: [emergency] Implementation Guide
Outline
Hi Folks,
This is a first draft, strawman for the implementation or
implementer's guide. So please view it as a point of departure. I left
out tentative contacts from the justice/law enforcement community that
I have already tried to arrange, and our recent discussions on XML
examples on the list.
Common Alerting
Protocol Implementation Guide Outline
(Note: the first question we need to ask is "What does this
audience of implementers need to know?" It is suggested that
getting answers from this community is the best way to determine this,
so it is also suggested that a method for that be adopted.)
1.Introduction
1.1 Purpose of CAP--Single Consistent Message
Across All Primary Audience Boundaries
1.1.1 Provide Common Message Format and Terminology
1.1.2 Transport Independence
1.1.2.1 Data Dictionary
1.1.2.2 XML Schema for API s and Web Serivces
1.1.2.3 One-way Broadcast Capability
2. Basic Concepts
2.1 Notification Messages Protocol
2.1.1 Not Signal Protocol
2.1.2 Code of Conduct, Rules of Conduct, Conventions
2.2 Implementer Audience
2.2.1. Emergency Management
2.2.2. First Responders
2.2.3. Public Immediately At Risk
2.2.4. Updates and Secondary Audiences
2.2.4.1. Update Consistency for Changes to Area, Severity,
Urgency, Recommendations
2.2.4.2. Update Consistency for Additional Related
Incidents
(Subsequent Incidents impacting Traffic, Responders,
Recommendations)
3. Broadcast Considerations (Need Implementer[s] Feedback from
Broadcast/Cable/Satellite Community)
3.1.
Video
3.1.1. Broadcast
3.1.2. Cable/Satellite
3.2. Radio
3.2.1. Broadcast
3.2.1. Satellite
***********************************************************************************
Information contained in this email message is intended only for use
of the individual or entity named above. If the reader of this message
is not the intended recipient, or the employee or agent responsible to
deliver it to the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please immediately notify the postmaster@nds.com and destroy the
original message.
***********************************************************************************
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]