Re: recommend Accept in preference to User-Agent to determine formats

Thanks for your helpful feedback on this document which we will keep for
when we update the document under our next charter. 

In the meantime we have some specific responses to your points below.

Many thanks again
Jo

[Link to ACTION-391]

-----Original Message-----
From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-request@w3.org] On Behalf Of Dan Connolly
Sent: 29 November 2006 09:29
To: public-bpwg-comments@w3.org
Subject: recommend Accept in preference to User-Agent to determine formats


Regarding...

"To determine what formats a device supports, Web sites may use any
combination of device profile information such as the HTTP User-Agent
header, HTTP Accept headers and UAProf."
 -- http://www.w3.org/TR/mobile-bp/ (2 November 2006)

The HTTP accept header is specifically designed for this purpose;
web sites SHOULD use it.

It's OK to say that they MAY use other stuff, but it doesn't
make sense to say that User-Agent is just as good as Accept
for figuring out what format the client wants.

I suggest:

  To determine what formats a device supports, Web sites should
  use the HTTP Accept header field; sites may use
  other information from the device (e.g. User-Agent, UAProf).

+++ Response:

I think the interpretation of the word "may" in an RFC 2119 context is
misleading, and perhaps we should reword to avoid this possible
mis-interpretation.

In practice we have found that determining device capabilities and
specifically the formats they support is something of a black art. It tends
to be the case that more accurate, precise and useful information is
available by consulting device capability repositories. 

Many devices state that they accept */*, however delivery of content that
the device does not support can result in serious usability problems, in
that it may present the user with an error that they cannot recover from -
not to mention that they may just have paid for the transfer of information
that is useless to them. 

On the other hand transmission of a more precise statement of acceptable
formats on every request increases latency and can cost the user money to
send data that is relatively unused and not really useful in many contexts. 

We will consider some re-working along the lines of:

When determining the formats a device supports, sites should examine the
HTTP Accept Header for any listed formats and ignore */*. They should also
use information such as UAProf and information determined by consulting
repositories of device capabilities.

+++

Some related, but more minor points:

"Some issues that have been noted by the BPWG in this context are:" is
wordy and refers to the BPWG, which is transient and
only tangentially relevant. Just strike that sentence and leave:

  There are problems with using any one approach to the exclusion
  of the others:

+++ Response

Yes that seems like a good idea, thanks.

+++

It's not clear to me why "User agent headers do not always
uniquely identify the device" is an issue. It's not necessary
to uniquely identify the device to figure out what formats
to use.

+++ Response

In reality, it turns out that it can be useful to know exactly which device
and browser and firmware version are in use in order to identify which
formats they can use. However we take your point that it's not _always_
useful to identify the device and we will consider working along the lines
of:

"User agent headers do not always sufficiently identify a device such
that its supported formats can be determined"

+++

And in what way is it a problem that "Some operator gateways
supplement the accept headers to include formats that they adapt"?
That's a feature, not a problem.

+++ Response

Yes, it could be regarded as a feature, but it may be that as a result the
intentions of the author are not realised in the way they had intended. 

We should consider some amplification of the statements here to make the
points more clearly.

+++

You could usefully elaborate "Some devices do not supply accept
headers". The HTTP spec says "If no Accept header field is present,
then it is assumed that the client accepts all media types." So
I suggest you say:

  Some devices have unstated expectations about formats;
  they do not supply accept headers, but neither do they
  accept all formats.

Putting "UAProf information may not be available or may be
incomplete" in the same list as protocol errors such
as "Some devices mis-state their capabilities" seems misleading.
I can't think of a specific suggested fix, though.

+++ Response

The point is made in the context of using all available information to
assess device capabilities, rather than specifically pointing out that some
browsers do not conform to specification. We will look at providing a more
satisfactory wording in a future draft.

+++

Received on Thursday, 7 December 2006 17:14:13 UTC