Re: RFC: draft-brown-device-stock-ua-00.txt

On 08.11.2012 08:26, Tiffany B. Brown wrote:
> On 11/7/12 10:17 AM, Eitan Adler wrote:
>> On 7 November 2012 13:04, Tiffany B. Brown <tiffanyb@opera.com> 
>> wrote:
>>> Hello all,
>>>
>>> I've recently submitted an RFC for a new HTTP header: 
>>> Device-Stock-UA.
>>> Feedback is welcome.
>>>
>>> http://www.ietf.org/staging/draft-brown-device-stock-ua-00.txt
>
> Brief aside: I've been informed that I should have called this an
> Internet Draft (because it is). For the sake of following the
> discussion, I am keeping the original subject line.
>
>
>> It isn't at all clear to me that this solves the problem:
>>
>> - the stock services may have been changed. just because a browser
>> comes with a device by default doesn't mean it wasn't removed.
>> - the capabilities of the third party browser may differ from the
>> capabilities of the stock browser
>
> This header should be used in conjunction with feature detection if
> used at all. Perhaps that's worth mentioning in an implementation
> notes or similar?

Feature detection of *what* exactly? that is important. critical even. 
Being informed about a piece of software which is not related to the 
transaction underway is useless. And I say this with my experienced web 
developer hat on.

For example;
   when opening a Z format object in Browser 'X' do I need to know the 
image processing capabilities of browser 'Y', or the fact that Picassa 
versus Photoshop are installed?

  No. I need to know that the browser X has a Z interpreter and is using 
it to handle the processing of the response I about to send back.

If browser X requests an image object, I still don't need to know that 
browser Y was installed, or even that the imaging software is installed. 
Just that the browser has *an* image processing component *it is making 
use of*.

There is nothing more annoying to both developer and user than to have 
a browser send explicit mention of capability Z, only to display that Z 
format response using a text processor and dump raw binary out at the 
viewing user.


>
>> - user agent shouldn't be use for capability detection in the first 
>> place
>
> Agreed. However, this is precisely how the user agent string is being
> used. This is particularly true for sites and applications that
> support hand-held devices (mobile phones, tablets, etc). Developers
> are relying on the user agent string to determine which image and CSS
> files to serve.
>
>> - what does the (stock) user agent string have to do with "other
>> software that may be running in addition to the user agent"?
>>
>
> Developers are also using the user agent string to infer things such
> as the presence of audio and video codecs, plugin availability, and
> whether the OS permits file system access.

*This* is the problem. Your header is making zero progress on fixing 
it.

Those websites are ignoring the Accept* headers content where such 
codec and media type support is listed in annoyingly great detail. And 
instead depending on the browser agent name string.

Amos

Received on Wednesday, 7 November 2012 23:07:17 UTC