RE: Re: please reivew mobileOK Basic Tests 1.0

Anne

Thanks for your reply, my personal view is that content negotiation
should only be used when there are different representations of the same
resource not when there are different resources with the same URI
distinguished by their content type.

It seems to me on the face of it unlikely that that index.htm and
index.css are different representations of the same resource.
Consequently referring to them by the same URI and relying on content
negotiation to sort out the difference seems unsafe at best and could
lead to the css representation being returned when the html
representation is required (for example when the user types in
"http://example.com/index" and the browser must send an accept header
indicating all the content types it supports.)

At a deeper level, my view is that if you have an image which in some
circumstances can be an equivalent representation of an html page, but
is also used as an image within a page then the two intended uses of the
image are distinct and should be given different URIs. The second use of
image demands an image and consequently it can't be considered
equivalent to the image when it acts as a substitute for an html page.

In saying this, I am not advocating that browsers should adopt the
behaviour we specify. We are not specifying a browser, we are specifying
a checker. By specifying the behaviour we do, we may in some
circumstances uncover a potential inter-operability problem, which in my
view should be identified.

Hope this helps and fwiw I think this is a vexed question that would
benefit from clarification, by the TAG perhaps. For example URI
Collision [1] doesn't quite address this issue, as I read it.

Jo

[1] http://www.w3.org/TR/webarch/#URI-collision
 

> -----Original Message-----
> From: public-bpwg-comments-request@w3.org
[mailto:public-bpwg-comments-
> request@w3.org] On Behalf Of Anne van Kesteren
> Sent: 03 October 2007 08:24
> To: mike@w3.org
> Cc: public-bpwg-comments@w3.org
> Subject: Re: Re: please reivew mobileOK Basic Tests 1.0
> 
> 
> (removing public-html from the cc list)
> 
> On Wed, 03 Oct 2007 05:13:02 +0200, <mike@w3.org> wrote:
> > We don't agree that the HTTP RFC requires this interpretation. We
> believe
> > that if a user agent includes an accept header that specifies
text/css
> in
> > a request, that is an indication not that text/css is an acceptable
> > response for an image but that it can process text/css in some
> > circumstances. In general the User Agent does not know what type of
> > resource to anticipate when it makes a request. It is a special case
> when
> > it does, as a result in this case of making a retrieval linked to a
> > specific element in a resource already retrieved.
> 
> Has the Working Group studied HTTP content negotiation before making
this
> claim? Say I got a file index.css and a file index.htm and Apache
> MultiViews is enabled. If the user agent does a request _all_ the time
to
> /index with
> 
>    Accept: text/html, text/css
> 
> index.htm will _always_ be returned. Even for <link href="/index"
> rel="stylesheet">. That seems wrong.
> 
> 
> > Your comment on 2.3.2 HTTP Request:
> >> On another point, Content-Type of the response for both image and
style
> >> sheet requests is simply ignored. The image type is determined
through
> >> sniffing and in case of a linked style sheet it is simply parsed as
> >> CSS. This is more or less required for user agents if they want to
> >> support
> >> web pages out there.
> >
> > Working Group Resolution:
> > We accept that real browsers have to adopt many heuristics and take
a
> > pragmatic approach. The intention of mobileOK Basic is to point out
to
> > content providers that mislabeling the content is an error. We
certainly
> > do not endorse the mislabeling.
> 
> Fair enough.
> 
> 
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

Received on Wednesday, 3 October 2007 08:42:32 UTC