OASIS Emergency Management TC

RE: [emergency] Public as responders (was RE: [emergency]...PPW l etter re CAP)

  • 1.  RE: [emergency] Public as responders (was RE: [emergency]...PPW l etter re CAP)

    Posted 10-09-2003 18:03
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: RE: [emergency] Public as responders (was RE: [emergency]...PPW l etter re CAP)


    Thanks for that clarification, Art.  My confusion 
    is not in the technology.  I understand that.  It is in 
    the routing if the public or civilian responder is an 
    asset.  One does find arrest records, for example, where 
    the officer record has a civilian/sworn field.  I wasn't 
    sure how CAP would be applied given that it is an alerting 
    protocol, not a field reporting protocol.
    
    Before I go back to sleep, one can always extend any 
    XML document by adding a namespaced data element with 
    the appropriate declarations therefore adding an element 
    or attribute from a foreign vocabulary.  Adding a base-64 
    element is no big whup as long as the receiver hands it off to 
    the right handler.  If the PPW wants to extend the CAP 
    document type, it is easy to do if they want to extend 
    by their own requirements and not wait.
    
    Datacasting from ps systems via TV has never come up to my knowledge. 
    A release to the media is fairly common but it sounds 
    as if you are talking about public safety systems with 
    direct access to digital media.  Interesting, but other 
    than their web sites, I've not seen it in an RFP and 
    I possibly need to understand the use scenario better.
    
    len
    
    
    From: Art Botterell [mailto:acb@incident.com]
    
    At 10:10 AM -0500 10/9/03, Bullard, Claude L (Len) wrote:
    >I'm trying
    >to understand in this thread what the requirement for
    >supporting this suggested change would look like if
    >or when it hits my desk.
    
    Len, most likely... unless you're dealing with datacasting systems 
    (satellite, digital radio or TV)... the proposed change wouldn't make 
    any difference to you at all.
    
    I'm sorry we've gotten so wrapped around process that we haven't 
    gotten to the point of discussing a specific proposal, but the 
    initial suggestion was that we offer a restricted option of a Base-64 
    encoding inline for use ONLY on one-way (i.e., broadcast) data links 
    WITH sufficient bandwidth.  (The MIME description field Carl mentions 
    is already in our spec.)
    
    An alternate proposal was that we mandate the use of a 
    SOAP-with-Attachments message envelope in such cases... which would 
    do the same thing with essentially the same bandwidth impact, albeit 
    in a more complicated way.
    
    But there's no reason why such a provision would need to have any 
    impact on low-bandwidth systems or IP-network systems.  The inline 
    (or SwA) format would only be supported when there was BOTH a one-way 
    link and sufficient bandwidth to handle the binaries.
    


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