[W3C] Draft Mobile Web BPWG / completeness

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,
highlighting the need for precision and completeness in some
sections.


1) Section 2.2.1:

The CTG distinguishes between retructuring, recoding and
optimization. This is a useful approach, and the distinction
could be used more systematically across the document. However,
without a formal definition of these terms, various parties
are left with too much leeway when classifying some operations
one or the other of the categories. This may entail inconsistencies 
regarding the interpretation of the guidelines.

The guidelines should:
a) Define formally each of the three categories, possibly on
the basis of language theory. As an example, optimization seems
to be related to equivalent token streams (for textual content),
whereas recoding seems to deal with equivalent parse trees. Some
operations are reversible, others are not. The W3C is home to 
technologies such as XSLT, so there should be competence there 
to help ground definitions on solid formal concepts. Basing such 
definitions on formal language theory is a suggestion, not a 
requirement; other formally grounded definitions are possible.
b) Define exactly how to classify an operation that spans several
categories. As an example, converting HTML to XHTML while at the
same time eliminating comments and redundant white space should
amount to a recoding.


2) Sections A and D

Since 2005, the Open Mobile Alliance has been working on a 
Standard Transcoding Interface, and has published specifications
for it. The usage scenario is different: the STI is meant for 
servers offering transformation services on demand via a Web
services interface, whereas the usage scenario of the CTG is 
for proxies that intercept all HTTP flows between clients and 
servers. However, there are several aspects that may overlap 
-- in the requirements or the definition of the acceptable 
limits during transcoding (e.g. content size). A reference 
to this standard, and a discussion of the relation between 
the CTG and the OMA specification is in order.


3) Section 4.3.6

The third bullet under "examples of heuristics" is to be split 
into two points:

"the Content-Type of the response are known to be specific to the 
device or class of device. At a minimum, the following MIME types
intended for mobile Web browsers MUST represent mobile-optimized 
content:

Browsing XHTML-related
	application/vnd.wap.xhtml+xml
	application/xhtml+xml
Browsing WML-related
	text/vnd.wap.wml
	application/vnd.wap.wmlc
	text/vnd.wap.wml+xml
	text/vnd.wap.wmlscript
	application/vnd.wap.wmlscriptc
	image/vnd.wap.wbmp
	application/vnd.wap.wbxml
Browsing and downloading
	application/vnd.wap.multipart.mixed
	application/vnd.wap.multipart.related
	application/vnd.wap.multipart.alternative
	application/vnd.wap.multipart.form-data

In addition, the following MIME types of the form */x-up-* 
SHOULD be considered as representing mobile-optimized 
content, at a minimum:

Legacy Openwave
	image/x-up-wpng
	image/x-up-bmp

The range of MIME types is intended to cover typical mobile
browsing applications.

Transformations specified by the relevant standards are allowed
(WAP-236 WAE specifications 19.12.2001, WAP-192 WBXML specifications 
25.7.2001, WAP-191 WML specifications 19.2.2000 and predecessors, 
WAP-193 WMLScript specifications 25.10.2000).

In accordance with Internet standards and practices, a proxy 
SHOULD determine whether a content is mobile-optimized FIRST by 
examining the HTTP header field content-type, before inspecting 
the XML declaration and its associated DOCTYPE."

Rationale: Inspection of the HTTP field Content-type is an
usual mode of operation amongst transcoders. It is also simpler
and safer than applying heuristics on DOCTYPE, because inspecting 
the content of a body requires one to deal with character encoding 
issues (see RFC3023, XML 1.1 sections 4.3.3 and E), or parsing 
multipart-structured content; these are unnecessary when handling 
HTTP fields. Finally, specifying a minimum set of required MIME 
types to take into account helps ensure that proxies will exhibit a
standard behaviour, and that non-textual content types for which 
there is no DOCTYPE (notably mobile-specific image formats) are 
properly dealt with. A normative document cannot leave full freedom 
to implementors to select whichever subset of content types are to 
be considered mobile-optimized or not.


4) Section 4.3.6

The second part of the bullet split as described in (b) is to contain
the following:

"other aspects of the response such as the DOCTYPE are known to be 
specific to the device or class of device.

At a minimum, the following DOCTYPEs MUST be considered as 
mobile-specific:

XHTML mobile profile
	-//OMA//DTD XHTML Mobile 1.2//EN
	-//WAPFORUM//DTD XHTML Mobile 1.1//EN 
	-//WAPFORUM//DTD XHTML Mobile 1.0//EN
XHTML basic
	-//W3C//DTD XHTML Basic 1.1//EN
	-//W3C//DTD XHTML Basic 1.0//EN
	-//OPENWAVE//DTD XHTML 1.0//EN
	-//OPENWAVE//DTD XHTML Mobile 1.0//EN
XHTML i-Mode
	-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.0) 1.0//EN
	-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/1.1) 1.0//EN
	-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.0) 1.0//EN
	-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.1) 1.0//EN
	-//i-mode group (ja)//DTD XHTML i-XHTML (Locale/Ver.=ja/2.2) 1.0//EN
Compact HTML
	-//W3C//DTD Compact HTML 1.0 Draft//EN
	-//BBSW//DTD Compact HTML 2.0//EN

The following DOCTYPEs MUST be considered as mobile-specific. 
Transformations explicitly provided for by the relevant standards 
are allowed (WAP-192 WBXML specifications 25.7.2001, WAP-236 WAE 
specifications 19.12.2001, WAP-191 WML specifications 19.2.2000 
and predecessors, WAP-193 WMLScript specifications 25.10.2000).

WML
	-//WAPFORUM//DTD WML 1.0//EN
	-//WAPFORUM//DTD WML 1.1//EN
	-//WAPFORUM//DTD WML 1.2//EN
	-//WAPFORUM//DTD WML 1.3//EN
	-//WAPFORUM//DTD WML 2.0//EN
	-//PHONE.COM//DTD WML 1.1//EN
	-//OPENWAVE.COM//DTD WML 1.3//EN

The range of MIME types is intended to cover typical mobile
browsing applications."

Rationale: A normative document cannot leave full freedom to 
implementors to select whichever subset of DOCTYPEs are 
considered mobile-optimized or not. This helps ensure that
transformation proxies exhibit a standard behaviour.


5) Section 4.1.5.

Statement to be added:

"In so far as the transformation carried out by the proxies is
to make content intended for a certain class A of devices 
available to devices of another class B, then requests MUST NOT
be modified whenever a client of a certain class is accessing
content intended for its class. 

If the class of request (either mobile-optimized or full-Web) is
not unambiguously determined from the URI pattern, the proxy
MUST take into account the original user-agent to avoid 
unnecessary transformations."

Rationale: It is obviously pointless to transform full-Web 
content accessed by full-Web capable devices (or vice-versa, 
transforming mobile-optimized content for devices with mobile 
browsers). Two cases illustrate the situation.
a) When full-Web devices such as advanced HTC PDAs, iPhones 
or tablets access the Web, there is no guarantee that an 
established server will include a no-transform directive; in
fact, it might explicitly leave it out to allow transformation
to cater for non-full-Web capable devices. Further, the 
proposed heuristics will not work: the MIME types of returned
content will indicate full-Web content (e.g. text/html), as
well as the DOCTYPE (e.g. -//W3C//DTD HTML 4.01//EN).
b) When i-Mode terminal accessing i-Mode applications, there is
no guarantee that the corresponding servers return a no-transform
directive (since it is irrelevant for i-Mode applications). 
Heuristics may not work either, since content is largely returned
as text/html, and without any DOCTYPE declaration.

 
Eduardo Casais
areppim AG
Bern, Switzerland

Received on Monday, 11 August 2008 20:03:57 UTC