[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Draft Reply To PPW Letter
>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.