OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] Implementation Guide Outline


Title: Implementation Guide Outline
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: Rex Brooks
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.
***********************************************************************************


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]