MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Draft Reply To PPW Letter
Agreed. I look forward to working with you all.
Ciao,
RexAt 4:09 PM -0800 10/27/03, Kon Wilms wrote:
> >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.
>
>I agree. Please note that by broadcast I do not mean the 6pm local
>television news. Digital television and other broadcast mechanisms can
>indeed be used to deliver data to EMs. In fact all emergency-services data
>broadcasting systems target these communities over and above the end user
>(who will no doubt watch the 6pm news instead).
>
>>Okay, I didn't mean that, only that it can be provided without
>>demanding it be provided in a certain way.
>
>Definitely. It should be flexible enough to be provided in a multitude of
>ways. If it is not, then someone is bound to make a proprietary version,
>which then by definition is provided in a certain way.
>
>>Isn't that the business of the digital broadcast community to
>>address? If you have a suggestion that doesn't adversely impact other
>
>It could be. But the digital broadcast community in many cases will take
>work with a solid foundation and utilize it as part of a solution. Take for
>example ATSC A/90/2, which uses SDP for the announcement protocol. Any SDP
>transmitter is usable in this implementation, and the ATSC spec refers to
>the SDP for announcement protocol reference. The best case scenario for the
>digital broadcast community would be to take CAP and use it as specified as
>part of an implementation, and then build additional infrastructure around
>it. As it is, if CAP can work over a 1-way transport, there is no work to be
>done for most ATSC delivery mechanisms, as they already would support
>delivery of the CAP message. Any re-formatting, conversion, or
>transportation of the payload would be a given, but in the end the basis of
>the delivery would be the existing CAP spec, without modification. That is
>indeed a best-case scenario, and one which is advantageous for good
>interoperability between products in the two-way and one-way networking
>world(s).
>
>>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.
>
>None of us expects or demands that the political and procedural process to
>be held up, but rather that this issue be raised and addressed during the
>public period and final ratification, so that data broadcasters can begin to
>implement systems which are CAP complaint.
>
>There have been a number of off-line discussions regarding this issue, and
>some of us are working on concrete and specific functional criteria for what
>elements would be required and guidelines to go with these. All that is
>really required is a single embedding which is only valid and used by
>broadcast delivery mechanisms. And indeed the way to have this function
>would be a way that does not affect messaging, applications, or parsers on
>one-way or two-way transports, or between the two -- with an absolute
>minimum impact on the existing spec.
>
>>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.
>
>Indeed. That is *all* that I am concerned with. I can get my message out
>using CAP on a broadcast network -- I just want to be able to get it out in
>a way where I don't have to link it to a proprietary mechanism to get it to
>work end to end in a way that provides optimum interoperability with other
>systems. This actually defeats the purpose of a commercial product (since it
>means no vendor lock-in), but I have been in many a situation where a spec
>has ended up not being widely used because of such implementation problems.
>
>>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.
>
>As I said, holding up the process is not the goal, and everyone wants to use
>CAP as a ratified standard as soon as possible.
>
>Cheers
>Kon
>
>
>
>
>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]