Re: [emergency] usage scenarios

[Kon Wilms <kon@datacast.biz>]

"Separate automatic notifications of both the car crash and the HAZMAT
carrier are sent using the Vehicular Emergency Data Set (VEDS),
contained in the Distribution Element, and in addition, a video clip
taken from a live transmission is transmitted as a properly mimeTyped
non-xml mpeg file for a time-stamped reference."

It concerns me that the EDXL framework is being used in this example as
a transport mechanism to deliver MPEG video - something it clearly is
not. I've brought this up a few times and it has largely gone ignored.

Base64 encoding adds quite a lot of overhead to data, and embedding this
type of content can easily lead to situations where a decoder is
hammered because it cannot deal with the size of the payload, or the
message is rendered useless because it cannot be delivered in a timely
fashion over bandwidth-starved and/or error-prone transmission links. If
the transmission link is unicast, you can quite easily cap out the
bandwidth on the link if multiple recipients are retrieving the content
at the same time (in which case the EDXL delivery system is for all
intent purposes rendered useless).

Content of this nature should be delivered to recipients via out-of-band
delivery on the same base transport mechanism (be that HTTP or
whatever). That way you can receive the message immediately and parse
the video content when it arrives. Server operators can also then apply
QoS settings to the traffic to prioritize delivery of EDXL messages.

In these situations it may also be advantageous to support multiple
content URI references, i.e. a reference to a download URI for the
content, a local disk reference if another mechanism handles delivery of
assets, and alternate methods for access such as streaming (in which
case the streaming metadata file (SDP, etc.) is inserted into the
content as a derefuri chunk).

Cheers
Kon