emergency-msg — archive

[Art Botterell]

Eliot - The issue isn't really embedding versus referencing, I think, but rather, whether we should provide both capabilities. There seems to be no dispute that referencing is preferable... when it's possible. The challenge... and it's a very specific one... is how to deliver binary resources over a one-way data link. (A data subchannel on a digital TV broadcast would be just one example.) Without a two-way transport layer, receivers have no way of requesting a separate transmission of a binary. Bandwidth is a separate issue; we can envision both high- and low-bandwidth instances of both bi-directional and unidirectional transports. Binaries will be problematic over low-bandwidth transports of either kind and in such contexts should probably be inhibited (or perhaps, in some cases, transformed into smaller versions) at network gateways. * Under the implementation principles proposed, attachments would be used only when transmitting over a transport network that was known to be one-way and of sufficient capacity. In practice this would mean that a gateway to a one-way channel would transform a CAP-with-Reference message into its CAP-with-Attachment equivalent by retrieving the resource(s) and attaching it/them to the forwarded version. Likewise, a gateway might receive a CAP-with-Attachment message over a unidirectional link, detach the binary asset(s) and post it/them to a local on-demand server, and then forward the CAP message over a bidirectional channel in CAP-with-Reference form with URI(s) to the new retrievable asset(s). (E.g., for a message received over a military "fleet broadcast" system and then distributed on a shipboard LAN.) Use of the embedding option would be rare, I expect, but providing both capabilities makes CAP much more flexible in terms of transport and application. - Art * There's actually a third question here: How can users be discouraged from providing unnecessarily large binaries out of either ignorance or an excess of zeal? This, I think, is largely an implementation issue... e.g., my email program asks me to confirm anytime I send an email larger than a meg or so. For image formats (and possibly some others) an advanced implementation might even offer automatic resizing of oversized assets. And an application sending CAP-with-Attachments over a one-way link could be configured with a filesize limit, above which it would either reject the message or simply strip the binary, as required to meet the "sufficient capacity" requirement for its particular downstream network(s). At 1:36 PM -0400 7/19/03, Eliot Christian wrote: >As I understand the argument, at issue is how a CAP message >should handle associated online resources such as Web pages, >image files, and audio files. > >I do see value in providing for content authentication >(e.g., a digest) within the CAP message, whether the >associated resource is directly embedded in the message >or just referenced by a URI. > >As to resource embedding versus referencing, I think that >URI referencing makes for a CAP message that is simpler and >more concise. I appreciate that those who want to run a CAP >service that provides associated resources will need to run >a separate streaming process for such products. I believe >that separation of the command stream from the content stream >may well be preferrable anyway, for the same reasons that FTP >separates the command stream from the content stream. > >I do envision CAP services that are bandwidth-constrained, >either by their nature (e.g., wireless wristwatches) or because >of partial outages and traffic saturation during an emergency. >The trade-off between reliability and timeliness would also be >a consideration in choice of protocols. You may want minimally >sized alerts messages to travel TCP/IP to assure complete >receipt, but associated video might be run directly over TCP, >trading for some lossiness in order to assume timeliness. >Selection of streams of audio/video products in multiple >languages present yet another kind of consideration. > >To me, the fact that the CAP message format is not bound to >any particular protocol or transport is *crucial* for the >standard at this point in time. It seems to me that specifying >a way to embed associated resources within the CAP message >goes further toward specific protocol bindings than we should. > >Eliot