[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]