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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency-msg] cap:image and cap:audio


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]