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
I have to say that the reasoning behind separating inline binaries from the
CAP payload for broadcast delivery is at best, extremely vague.
How is separation of binaries an 'alternative' when in fact this is how
transmission is currently specified?
What does (separation of payload from transport) 'works in a more friendly
manner' involve? Does this imply it is easier to use? And easier for who? As
it stands, it is friendly for webservices and internet-transport use. Which
contradicts the notion that CAP should work irrespective of transport
medium. Broadcasters don't make use of webservices (they don't work over
one-way links, period) and have no internet connectivity at many of their
receiver sites (or uplink sites). In fact, the best scenario for alert
transmission over a broadcast link is a link which does not require a
landline of any sort for data reception. The original intent of
encapsulating binary messages inside the CAP XML was to facilitate efficient
delivery of CAP messages over 1-way links. These links have no way to parse
a URI field and 'retrieve' the web page or image from a website -- they have
no connection but an antenna.
I believe there is also confusion about the nature of the broadcast
transport. In a broadcast scenario, a CAP message with an inline binary has
no relation to the transport whatsoever. A minimum of 1-3 levels of
abstraction separate it from the actual transport. These layers involve
encapsulating the CAP message in payloads, for example CAP within a UDP
carousel within MPE sections within a MPEG2 transport stream.
The intention was never to encapsulate large data chunks into the CAP
message. The original intent for inline binaries was to facilitate the
*optional* insertion of *small* binaries as an alternative to URI data not
being available (since there is no back-channel), while keeping
compatibility with the CAP spec and also ensuring that one-way broadcast
delivery does not get labeled 'non compliant'.
A scenario where the CAP message is delivered, and the user gets a 'URL
unavailable' due to having no backchannel to a website URL, is
*unacceptable*. What if this embedded data is a photo of a missing kid, or
an escape route? The CAP message is useless without the ancillary data.
I have seen comments on the list about encapsulating streams, video clips,
and so forth in the CAP message. This is a ludicrous idea. In a broadcast
scenario, such binaries are delivered on a separate channel by a data
delivery engine. The crux here is that there is no fat pipe in the broadcast
world, and datarates typically run at 2400bps-50kbits for most services.
Embedding files larger than a few dozen Kb thus makes no sense, since by the
time the alert is received, it may no longer be valid. Also, delivery of a
file over a one-way broadcast will in most cases take a longer amount of
time than delivery over a 'same-bitrate' TCP connection.
Indeed, one can deliver CAP messages via broadcast with separate binaries.
But consider for a moment that unlike the 'internet', where we can easily
spec that implementations 'must use SOAP and webservices', the broadcast
world consists of many proprietary technologies. You can't rely on these
systems working together. And you can't rely on them having the capability
to separate a binary from the CAP message and successfully deliver both
elements over a one-way link. There are multiple transports in operation,
and the most reliable delivery method is to keep the message as compact in
size and number of elements as possible. Most delivery engines will have no
capability to 'retrieve' URIs or dependent data and transmit them. In fact,
most broadcasters keep their broadcast chain separated from any and all
internet connections. Finally, on the receiver side, you can't rely on the
binary data being available at the same time as the CAP message, since every
data delivery manufacturer has unique ways of delivering and encapsulating
data.
It may be easy to drop this feature in the short term, but in the long term
I can guarantee it will cause headaches, both in operation and
interoperability. Please do not take the easy way out by overlooking it.
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]