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] Draft Reply To PPW Letter

>I guess I don't understand why broadcast media would need more than
>having a binary provided or else the basic information from which to
>produce a suitable announcement, which we ought to be able to send if
>it has been generated, with a CAP alert message in a separate
>payload, such as a SOAP attachment or a second message/email
>w/attachment or providing an ftp url where it can be downloaded, all
>of which are as good as, or better than, having it inside the CAP

Please explain how a broadcast receiver with no way to receive data but the
broadcast signal can receive data from two-way sources such as email, ftp,
etc. It cannot. There is no way to 'retrieve' data but to pull it from the
broadcast signal. The 'internet' delivery model and 'internet' protocols do
not apply here. Furthermore, most set top boxes do not have code to
understand any of these protocols. And what do you do when multiple
broadcast systems are utilized, each with a different transport?

None of your proposed solutions work. It is obvious, as you said, you don't

>payload message as an inline. Or, we can establish a
>broadcast-specific policy of sending the binary via their choice of
>transport, provided there is an available
>Broadcast-and-Specific-Transport-capable agency/facility/company in
>our community which can handle that request.

Payload conversion and transport portability are not the same thing.

>I don't believe that broadcast needs to do more than announce the
>emergency message to the public with relevant information and basic
>instructions for immediate action if needed, and/or information for
>the public about how to access more specific information in the same
>way that the emergency broadcast system works now.

Digital broadcast delivery provides far greater capability than delivery of
a simple message. Why let that capability go unused? Why are we bothering
with CAP, if for broadcast purposes we wish to duplicate the existing
emergency broadcast system. This is illogical.

>I don't think broadcast is an acceptable method to be sending CAP
>messages to the Emergency Management community or first responders,

Our first responsibility, to the public and for the well being of our
nation, is to save lives and protect property. It is in the public interest
that emergency messages are delivered over any possible medium in order to
alert as many people as possible. Are you saying this is not the case, and
we should be selective about this process?

>except if it is the only way that the message can get out, which
>seems somewhat unlikely but not impossible. Broadcast is just not set

Unlikely? What happened to all those fiber lines on 9/11? In densely
populated areas, the landlines are usually the first method of communication
to be destroyed or impeded. No matter the level of destruction to property
and buildings, a transmitter will still be able to deliver a signal. And
where a transmitter is destroyed, ones outside of the destruction radius can
in most cases still reach into the affected areas. Where none of these work,
uplink/downlink repeater trucks can be deployed. The turnaround time for
pulling a wire is a lot longer than that of receiving a broadcast signal, or
switching signals.

>up to be able to be used as a coordinating medium, nor is radio,

Broadcast is not the do-all end all for EM coordination. But EM notification
does not solely involve coordination either.

>although the public-access cable channels could well serve that
>purpose. Of course, PBS can also be asked to provide more focused
>programming related to a given emergency.

The alert message should be agnostic to the transport layer and indeed
should also be portable across any transport layer. Your comments are in
line with keeping the message portable over select transport layers only,
which defeats the purpose of the message in the first place, and
inadvertently results in a variety of customized versions of the message -
none which can interoperate without additional interfacing protocols. The
end result of which is an unusable message and a message bound by vendor
lock-in and proprietary systems.

Broadcast delivery does not mean broadcast delivery to PBS viewers and / or
television sets. It also means broadcast delivery to any manner of devices,
be that mobile phones, mobile receivers, digital set-top-boxes, and so
forth. Not only that, but it includes transport delivery over not only your
television broadcast signal, but WiFi, GPRS, 3G/MMS, DVB-H/T/X, and so
forth -- including transporting data between these systems. Broadcast
delivery is also not a one-to-all mechanism. Data and video delivery can
easily be targeted to specific users, encrypted for groups, or delivered to

I would very much appreciate it if you could illustrate your opinions that
broadcast EM delivery is indeed unacceptable by pointing to any unsuccessful
digital broadcast EM trials, studies, or undertakings of any sort.

I know I can back up my comments with facts - can you?


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

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