- From: Kevin J. Dyer <kdyer@draper.com>
- Date: Mon, 06 Mar 2000 12:25:38 -0500
- To: hardie@equinix.com, asgilman@iamdigex.net (Al Gilman)
- Cc: tamagen@hotmail.com (Tam Freestone-Bayes), www-talk@w3.org
Since the traffic is generated by the servers, for the most part, shouldn't
the server and its protocols be aware of bandwidth problems and self-limit
the feed? Has anyone taken a look at the blocks protocol, submitted by
invisible worlds, as a potential fit?
http://mappa.mundi.net/Internet-Drafts/
If an upgrade command is sent along then why wouldn't this be an
appropriate protocol?
Before I get slammed, I realize that clients have to be able to understand
this new protocol and that it is not a perfect fit for everyone. I'm just
asking if anyone has looked at this and could it be applied in certain cases?
At 08:37 PM 3/2/00 , hardie@equinix.com wrote:
>conneg's work is bounded to negotiation related to content features
>and does not include a registered feature tag for something like
>bandwidth or link speed. While it would be possible to use the conneg
>syntax to create a "bandwidth" feature, I believe that doing so would
>not ultimately benefit content negotiation. A device with a very low
>link speed may still be used to render very complex content; it
>increases the download time, but this may not matter to the end user
>(especially if the download is background or unattended). I would
>suggest using MIME types and features to indicate the breadth of
>available content and/or the user's capabilities and preferences; the
>set intersection logic allowed by the conneg syntax is fairly powerful
>in its ability to match capabilities and content features. This
>approach will also catch the case of high-link speed/low capability
>devices (like modem-equipped PDAs).
===========================================================
Kevin J. Dyer Draper Laboratory MS 35
Email: <kdyer@draper.com> 555 Tech. Sq.
Phone: 617-258-4962 Cambridge, MA 02139
FAX:
617-258-2061 http://www.draper.com
----------------------------------------------------------------------------
------------------------------------------
_/_/_/_/ _/ _/ _/ _/ _/ _/_/_/_/
_/ _/ _/_/ _/_/ _/ _/_/ _/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/
_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/_/
Data Management & Information Navigation Systems
===========================================================
Received on Monday, 6 March 2000 12:26:32 UTC