OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]