RE: [emergency] Draft Reply To PPW Letter

["Kon Wilms" <kon.wilms@ndsamericas.com>]

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