OASIS Emergency Management TC

 View Only

RE: [emergency] Draft Reply To PPW Letter

  • 1.  RE: [emergency] Draft Reply To PPW Letter

    Posted 10-28-2003 00:13
     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


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


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]