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

[Eliot Christian <echristi@usgs.gov>]

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