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


At 1:22 PM -0800 10/27/03, Kon Wilms wrote:
>  >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
>understand.

We are not connecting. I do not think that CAP should be going out to 
the public. I think it's audience is the Emergency Management 
community. One part of that community is broadcast media. Broadcast 
media can do a much better job of informing/alerting the public.

>  >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.

Okay, I didn't mean that, only that it can be provided without 
demanding it be provided in a certain way.

>  >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.

Isn't that the business of the digital broadcast community to 
address? If you have a suggestion that doesn't adversely impact other 
systems, I'm sure we would be happy to include it, but if you want us 
to hold up on getting a useful first version out the door, it seems 
unlikely. We have a 30-day public period in which we can work with 
whomsoever wishes to work with us. So, let's take it up in that 
process, okay? That's what our process allows for and requires.

>  >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?

Precisely. If there is a significant Emergency Response community 
that we don't reach, we need to know about it. If there is such a 
community that ONLY gets broadcast, then by all means, let's find a 
way to get the message out.

>  >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.

I'm not against providing for the service. I simply don't think it 
should prevent us from getting a useful standard into practice, even 
while we are amending it. CAP has already been two years in the 
works. We are not going to hold it up. We will be formally in the 
30-day public comment period very soon.

>  >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.

Agreed.

>  >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.

I disagree. It makes little sense to me to engage in more argument. I 
doubt either of us will convince the other.

>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
>all.

Some of those are two-way, but that's not really the point. I'm fine 
with including broadcast capability in CAP, just not being restricted 
by it, nor being held up until the suitable mechanism is proposed and 
adopted.

>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?
>
>Cheers
>Kon
>

Ciao,
Rex

>
>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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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