RE: clarifications needed / HTTP header fields, URI patterns

Francois beat me to the draw on B. Happy to accept a proposal for
clearer wording.

On A: 1) yes, SeanP pointed out the unnecessary repetition of header
fields, in the latest draft I have added a "the" to make it clear that
the first is a reference to specific header fields and the second is
part of the names of the header fields. Hope you like it.

2) I take your point but don't know what to do about it. In the new
draft, at the group's request, I have spelled out the equivalence of
X-Device-Yada-Yada to original header field Yada-yada as it seems that
this is needed to push it all along IANA-wise. Can we recommend that
people introduce X-Device-Yada-Yada fields if they do replace fields
other than those listed? This is the bit that just got changed in the
document and was a preferable wording in my view because it covered this
case (tacitly).

Any proposal gratefully accepted as to how to fix this.

Jo

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Eduardo Casais
> Sent: 19 June 2009 15:59
> To: public-bpwg@w3.org
> Subject: CTG: clarifications needed / HTTP header fields, URI patterns
> 
> 
> It seems that during editing something got mixed up in section 4.1.5
> "Alteration of
> HTTP Header Field Values"
> 
> A) ALTERATION OF "NON-CAPABILITY" FIELDS
> 
> Section 4.1.5 states:
> --------
> Aside from the usual procedures defined in [RFC 2616 HTTP] proxies
> should not modify
> the values of header fields other than User-Agent, Accept, Accept-
> Charset and
> Accept-Encoding header fields and must not delete header fields. It
> must be possible
> for the server to reconstruct the original User Agent originated
header
> fields by
> copying directly from the corresponding X-Device header field values
> (see 4.1.5.5
> Original Header Fields).
> --------
> 
> The first sentence is formally equivalent to:
> 	proxies MAY modify header fields User-Agent, Accept, Accept-
> Charset and
>         Accept-Encoding and SHOULD NOT modify other header fields.
> 
> The second sentence states that one can reconstruct modified fields
> from equivalent
> X-Device fields. However, such X-Device fields are only defined for
> Accept,
> Accept-Encoding, Accept-Charset, User-Agent. If other header fields
are
> modified
> because of the transformation operations of a proxy, it is therefore
> impossible to
> reconstruct them.
> 
> Besides, there is an unnecessary repetition of "header fields" in the
> sentence.
> 
> A clarification is needed.
> 
> 
> B) DECISION TO ALTER REQUESTS
> 
> The same section states:
> 
> -------
> Note:
> 
> The heuristics discussed in 4.2.9 Proxy Decision to Transform relating
> to URI
> patterns are not part of the decision to alter HTTP Header Field
> values.
> -------
> 
> What is the reasoning behind this prohibition? Deciding not to
> transform a request
> because a URI indicates a mobile site is quite a valid approach --
> actually more
> efficient than first transforming the request and then figuring out
> whether the
> result was mobile or not in the first place.
> 
> A clarification is requested.
> 
> 
> E. Casais
> 
> 
> 
>

Received on Monday, 22 June 2009 14:28:16 UTC