Re: Client header for connection speed info

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).

You may also want to follow the work of the W3C's CCPP working group,
which is also working on client capability and preference issues.  Because
of the W3C's cooperation with the WAP forum on this work, the group
is very aware of bandwidth restrictions and their effects on client
capabilities.

			regards,
				Ted Hardie
				Chair, conneg







> 
> You might want to review the work going on in
> 
> Content Negotiation (conneg) Working Group
> 
> http://www.imc.org/ietf-medfree/
> 
> Al
> 
> At 12:15 PM 2000-03-02 -0500, Tam Freestone-Bayes wrote:
> >Many sites and their users can benefit from the provision of more than one 
> >http interface to a site - for example, the increasingly widespread 
> >bandwidth discrepancy between standard modem and broadband connections may 
> >encourage developers to produce both high- and low-bandwidth versions of a 
> >site.
> >
> >Many sites implement this but rely on the user to manually select which site 
> >they "prefer".
> >
> >If the site developer knew what the user's average download times were upon 
> >their arrival, then this could be used to automatically determine what level 
> >of information to display to the user before the first URL is actually 
> >served.
> >
> >I suggest that a client side header (for example "Avg Speed: 38552" 
> >representing bits per second, say, could be useful. It is the responsibility 
> >of the client to calculate and maintain this figure based on their average 
> >or maximum download speeds over the duration of a browsing session.
> >
> >The header should obviously remain optional in any client implementation, 
> >but the benefit of supplying it is high.
> >
> >tam
> >
> >______________________________________________________
> >Get Your Private, Free Email at http://www.hotmail.com
> > 
>

Received on Friday, 3 March 2000 04:06:06 UTC