RE: NEW ISSUE: Use of "Client" in 14.4

William A. Rowe, Jr. said:
> Travis Snoozy (Volt) wrote:
> >
> >    As intelligibility is highly dependent on the individual user, it is
> >    recommended that <del>client applications</del><ins>user agents</ins>
> >    make the choice of linguistic preference available to the user. If
> >    the choice is not made available, then the Accept-Language header
> >    field MUST NOT be given in the request.
>
> Thank you for the clarification. I have a better rational for your change;
> "user agents" appears repeatedly in the specification;
> "client applications" occurs only in this specific paragraph.

Well, "user agents" is defined; I *assume* "client applications" is
semantically equivalent to "client(s)" (which is defined), but that's just
my interpretation.

> The other rational alternative is to drop the word client.

Yes, but then everything has to make a choice available to the user.

Now, I think I should probably stop and back up a bit: when I say "user", I
mean "the person who told the user-agent to go make an HTTP request" -- not
"the person who is running the server/proxy/gateway." The word "user" does
not appear to be defined (at least, not in section 1.3), so I don't know
what the spec considers users to be, per se. With that said...

> Remember that an application/user agent may not even be interactive, and
> may be an application with a preferences.conf file which can be configured
> appropriately.

Keep in mind that "user agents" are special (the word is defined), whereas
"applications" are not (I read "application" to mean "anything that
interprets HTTP/1.1 messages").

> > ... It's totally up to the implementer how to present Accept-Language
> > options right now, and in my modification; I agree with you that this
> > should be a choice on the implementer's part. But implementers of
> > clients (proxies, user agents, or otherwise) do have to present a
> > linguistic preference choice -somehow- (according to the spec, right
> > now) in order to transmit an Accept-Language header. This is the case
> > even for things (like proxies) that don't have a reasonable way to
> > present a choice to the user.
>
> You presume.  Let's say that in your example above that as TOR's outbound
> proxy, an assortment of proxy services are offered, e.g.
>
> http://fr.tor.example.com
> http://dk.tor.example.com
> http://en.tor.example.com

Yes, but then why would I bother configuring my browser to Yiddish? What
happens if, e.g., there is no yi.tor.example.com? What happens if the TOR
endpoint (which I can't control) goes through a proxy before or after the
xx.tor.example.com?

As far as I can tell, the only things that have business with Accept-
Language are the end-user/user agent and the origin server (and, possibly,
an intermediate cache that can service the request in the appropriate
language).

> I can make the rational argument that these three are user agents acting
> on behalf of the endpoint user agent, even with the language change you
> propose.

Well, section 1.3 isn't rock-solid in its definition, but I think that it's
fairly clear that proxies don't "initiate" requests, they "forward"
requests. Proxies are not _usually_ user agents (though nothing stops you
from implementing a browser that also just happens to run a proxy on :8080).
Also, I think that the intent is that all "user agents" are endpoints (with
origin servers being the other endpoint) -- again, I don't see this anywhere
explicitly, other than the word "initiate" in the definition of "user
agent".


Thanks,

-- Travis

Received on Friday, 5 January 2007 00:55:48 UTC