[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]