RE: [emergency] Draft Reply To PPW Letter

["R. Allen Wyke" <emtc@nc.rr.com>]

Ok, I have been *trying* to follow this thread, but I think it keeps
going deeper and deeper into the trees, and we are missing the forest. I
know Rex and Kon seem to have finished their thread, but its pretty
obvious there is still some need for clarity. I think I understand the
concerns, the arguments, the situation, etc., so let me recommend a
couple of things to move things forward.

1. Rick: as part of the Requirements document, I would recommend we
include a definition of "transport". We have talked about this as a
group before, but that was before Kon joined. Basically, we need to
clarify that "transport" is not at the packet level - we have loosely
considered that the "communications" level (we should define
communication level as well). Transport is more like the USPS, where
they use boxes, envelopes, etc. - not the trains, planes, and
automobiles they use. Those are more of the communications level.

2. Broadcast Group: few of requests from you guys. First, all of these
ideas, thoughts, and comments should be tailored to be included in the
Requirements document. So, the best way to address your need is to list
out "how do I" questions that are generated when you look at how to use
CAP in your scenario.

Second, it would be helpful if you further educated us on your
"platform" (aka technical details of the medium you have to operate on).
I actually had some experience with the settop box/OS people a few years
ago (OpenTV, ReplayTV, Canal+, etc.. about 7 of them), so I understand
the low baud backchannel you mention and some of the other things.
However, it is my understanding that while the backchannel is slow,
which is where the small URI requests would be made (I worked for a
company that would serve ads to these machines), the download still
occurred on the high bandwidth channel. The issue we had then was more
around the fact that this backchannel was not connected all the time for
some of the boxes, although that seemed to be going away. Along those
same lines, if you are unable to make any request at all, then how are
you going to validate a CAP message against the schema - box, device, or
whatever it is on? If it is hardcoded locally, then that would imply you
would not be able to support future versions, which really puts you back
where you are now - might as well not have a standard. Anyway, I my
intension for mentioning these are not to start another thread, but to
stimulate some thought into what the group needs to better understand,
so providing us with some details on the broadcast "platform" will help
facilitate that in a positive and productive manner. With that, I will
ask that you do not reply to these comments directly, but rather use
them as a guide to help us better understand the broadcast use case.

Finally, I would recommend you guys read up on XML Schema and maybe even
Namespaces in XML. One of the things I *think* I am reading between the
lines is that it is your understanding that if CAP does not have inline
binaries, that it is not possible to send them in the same XML document
- which is not true. It is completely possible to do this, even today,
using various features/functions of XML Schema and/or Namespaces in XML.
The issue around it, as you would quickly determine, is how to do that
in a way that is standard across implementations. Ahhh, and we quickly
arrive at the current task before the IF SC today. How to standardize on
sending CAP messages from A to B, and possibly through C in the process.
The topic of transport (remember how we define it, not how you were
using it). And believe me, it will step into more than just the
technical details of "how" to do it. There is a WHOLE world of how to
"facilitate" this exchange, because as Kon pointed out in one of his
examples, things such as dependencies on the image must be addressed.
The "don't send this alert unless you know the image can go and be
rendered", which of course means we now have to figure out a way to
"know". This topic is going to be a lot bigger than I think some of you
are thinking.

Hope this helps - Allen

On Mon, 2003-10-27 at 19:09, 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.
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
-- 
R. Allen Wyke
Chair, OASIS Emergency Management Technical Committee
http://www.oasis-open.org/committees/emergency