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
