W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: [W3C] Draft Mobile Web BPWG / Guidelines clarifications

From: casays <casays@yahoo.com>
Date: Thu, 07 Aug 2008 13:32:59 -0000
To: public-bpwg-comments@w3.org
Message-ID: <g7etib+9a0e@eGroups.com>

To the W3C Mobile Web BPWG.

This is a third series of comments regarding the "Working 
Draft of the Content Transformation Guidelines" from 1.8.2008,
focussing on clarification of some sections with respect to
standards.

1) Section 4.2.2:

Statement to be inserted:

"As per sections 13.5.2 and 14.9.5 of RFC2616, proxies MUST
NOT modify neither the header fields Content-Encoding,
Content-Range and Content-Type, nor the body originating
from a server that includes a no-transform directive in
its response. Proxies that do not follow this rule do not
conform to the HTTP protocol."

Rationale: there actually are transcoders which, despite 
no-transform directives, modify the body of the responses 
from server. The statement reminds the users of such proxies 
that they must be configured so as not to violate IETF 
standards.

2) Section 4.1.5.5

Statement to be inserted:

"Except when explicitly provided for by RFC2616 to comply
with HTTP operations, a proxy MUST NOT delete HTTP header 
fields received upstream from the client or downstream
from the server."

Rationale: deployed transcoders have been known to filter
out entire HTTP fields, preventing servers from performing
adequate content delivery. In some environments, this 
behaviour seems to have affected x-wap-profile in particular.
The statement makes it clear that deleting HTTP header fields
is in violation of the Web standards.

3) Cascaded proxies.

a. Section 4.1.3

Statement to be inserted:

"Whenever the requester is another transformation proxy, the
receiving proxy MUST treat it as a non-browser agent. The
receiving proxy SHOULD rely upon the presence of alternative
X-Device- HTTP fields to detect that it is placed downstream
from a chain of proxies."

b. Section 4.3.2

Statement to be inserted:

"As per section 14.46 of RFC2616, 214 Transformation applied
MUST be added by an intermediate cache or proxy if it applies 
any transformation changing the content-coding (as specified 
in the Content-Encoding header) or media-type (as specified in 
the Content-Type header) of the response, or the entity-body 
of the response, unless this Warning code already appears in 
the response. 

A proxy receiving a 214 code MUST NOT change it."

c. Section D.4

Eliminate entirely.

Rationale: together with 4.3.1, 4.3.2, 4.1.2, 4.1.5.5, 4.1.6.1, 
4.3.6.1, these changed sections entirely solve the issue of cascading 
proxies in a standards-compliant way.

4) Section 4.3.6.

Complete the statement:

	"the URI of the response (following redirection 
	or as indicated by the Content-Location HTTP header) 
	indicates that the resource is intended for mobile 
	use (e.g. the domain is *.mobi, wap.*, m.*, mobile.*"

ADD: 	, pda.*, imode.*, iphone.*,

	"or the leading portion of the path is /m/ or /mobile/);"

Rationale: URL with pattern imode.* and pda.* have been in
use for many years, and unambiguously indicate sites that
are optimized for i-Mode devices or for PDA (Palm, PPC, 
IEMobile). URL of the form iphone.* have started to appear,
providing experience specifically tailored to i-Phones; they
do not need, and should not be transformed either.

5) Section 4.1.5.

Statement to be added:

"The request MUST NOT be altered Whenever the URI of the 
request indicates that the resource being accessed is able
to provide mobile-optimized content, e.g. the domain is
*.mobi, wap.*, m.*, mobile.*, pda.*, imode.*, iphone.*,
or the leading portion of the path is /m/ or /mobile/."

Rationale: The guidelines make the assumption that all
requests may first undergo a transformation before possibly
falling back on a transformationless mode of operation. 
This is unwarranted, and does not correspond to the way
many deployed proxies operate. 

Obviously, it is rather pointless to go all the way to 
send a request to the server and wait for its response
in order to detect whether the resources accessed are for
mobile use, when it is already possible to do this by
inspecting the request of the client. The addition to the
guidelines covers this situation, and corresponds to the
state of the art in transformation proxies. It is also
consistent with the heuristic serving to determine whether
a response is already mobile-optimized. Following this
new guideline improves the performance of the entire 
content delivery chain without loss of functionality,
and is congruent with the stated objective of the 
guidelines of not disturbing mobile-optimized content.


 
Eduardo Casais
areppim AG
Bern, Switzerland
Received on Thursday, 7 August 2008 13:33:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC