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

[Art Botterell <acb@incident.com>]

At 8:33 AM -0400 7/18/03, Allen Wyke wrote:
>My issue is that this is a "transport" issue and not a "body" issue 
>- not about how hard, easy, difficult, etc.... The moment we start 
>to try and solve transport issues, we prevent real transport 
>standards from working.

Only if we make such provisions mandatory.  So far I'm not aware that 
we've done that.  Bear in mind that a single CAP message may, in its 
lifetime, traverse a number of different transports.

We've tried to provide a minimal set of tools to make it possible for 
all the required characteristics to be achieved over any transport 
that can move an XML message.  We haven't required that any of those 
tools be used or that others not be used, nor even that the same 
combination of tools be used at every step along the way.

By the same token, we haven't relied on any assumptions about the 
characteristics or capabilities of the transport(s) used, other than 
that it/they can somehow transmit an XML message.

>But it is usable - even without attachments. Its just not usable in 
>the scenario brought up at the F2F.

The scenario I brought up at the F2F was a very pure instance of 
one-way (e.g., "broadcast") transmission.  If it isn't usable in that 
scenario, then we haven't met our requirement.  Which would be a 
shame given that we've identified a feasible way to meet those 
requirements while controlling the potential for negative impacts.

>  To determine the impact of that use case, especially this late in 
>the game, you guys simply determine the benefit of adding and 
>compare that with the impact of adding it.

We did.  The benefit was that we supported both our agreed-upon 
requirements and a specific real-world use case.  The impact was that 
we created a potential for capacity/bandwith problems, for which 
we've identified remedies that don't require us to sacrifice 
functionality.

>The way to resolve the URI issue, which is different than the 
>encryption issue (although related), is simple. It lies in 2 
>questions:
>
>1. What is our potential adoption rate increase/decrease by 
>including/not including attachments?

Near-term adoption rate is a legitimate concern, but I'm not sure it 
should be the only thing we care about.  However, just in the short 
term, we're balancing:

	* Our stated requirements, and,
	* The real existence of at least one significant potential 
adopter with an
	immediate and high-profile application for which they won't be able to
	use CAP if we can't support full-featured one-way transmission,

	 versus

	* A hypothetical concern that somebody somewhere might find the
	very minimal additional requirements involved in providing that option
	and preventing it's misuse to be a show-stopper.

Anyway, based on what I heard at this week's EC meeting, I'm not sure 
adoption rate is going to be our problem.  There appear to be so many 
players lined up to implement CAP that there was some concern 
expressed about being overrun with adoptions, but none about a 
shortage.

>2. If the adoption rate shows a significant enough increase, then 
>what is the best way to handle the one-way use case?

That is indeed the question.  If there's a better way to do this than 
what's been discussed, I hope it will be brought forward.

To recap and as background for the folks who haven't heard all the 
discussion so far, the current (but still somewhat controversial) 
state of the proposal is as follows:

1) Consolidate the functions of the <audio> and <image> elements into 
a single <resource> structure, which is optional and may be multiple 
within an <info> block.

2) Within <resource> provide the following elements:
	<description> - A free-text description of the nature of the 
resource [required]
	<mimeType> - A MIME type for the resource [optional]
	<digest> - A digest (hash) of the resource  [optional]
	<URI> - A URI for the resource  [optional but strongly recommended]
	<data> - A base64-encoded representation of the resource  [optional but
		strongly discouraged except for use over one-way transmission
		links with sufficient bandwidth.]

3) To mitigate any bandwidth or other capacity impacts due to 
inappropriate use of the <data> option, the following implementation 
notes:

	a) Any implementation which transmits CAP message should not use
	the <data> element unless the output channel is known to be a one-way
	channel of sufficient bandwidth;

	b) Any implementation which retransmits received CAP messages should
	strip received <data> elements prior to retransmission unless the
	output channel is known to be a one-way channel of sufficient
	bandwidth; and,

	c) Any implementation which retransmits CAP messages should, if
	possible, decode such stripped <data> content and make it 
visible on the
	Web and substitute a <URI> for the posted version prior to
	retransmission, unless the output channel is known to be  a one-way
	channel of sufficient bandwidth.

- Art