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]