Re: [CTG] Draft 2008-11-07 / http-equiv

> And certainly at the time we thought that 
> there was strong justification for
> referring to HTML (in its broadest sense)
> as Web content but not to WML, since that
> is not a component of the Web per se. Nor
> is J2ME etc. A Web browser, or so we 
> thought at the time, is by definition
> something that handles HTML.

The mobile Web is part of the Web, as much so as the desktop Web, at least since 1996, and with undisputed, increasing importance.

The fact that the mobile Web prefers XHTML and WML, whereas the desktop Web is still committed to HTML is not decisive in the context of the CTG. 

The desktop Web and the mobile Web coexist on and rely upon the same infrastructure (image formats, protocols such as HTTP, etc), are accessed on similar servers via URL over the Internet, and may even run on the same devices. The absence of a clear separation between desktop and mobile Web actually explains why transcoders interfere with the latter and why there are transcoders in the first place (otherwise, requests and responses would not cross over between mobile and desktop Web).

Hence a mechanism allowing application providers to protect their content must  apply both to mobile and to desktop content explicitly. I would say this should also apply to TV-set-top-box Web content, which, though much more constrained in terms of service provisioning, relies largely on the same technologies (HTML...) and presents comparable opportunities and difficulties for transcoding as in the desktop and mobile Web. 

> The fact that we don't refer to WML doesn't
> mean that CT proxies should not do sensible
> things with it. Ditto J2ME and so on.

Given the facts that:
a) the mobile Web is part of the Web;
b) the mechanisms of the CTG are to be  generally applicable to the whole Web;
c) transcoders are known to interfere with mobile-optimized content, and badly so;
d) the no-transform directive is essential to protect any content, mobile-optimized as well as desktop-optimized, from being altered by transcoders;
e) because of the way WAP gateways operate, such a directive in the HTTP header may invalidate WML delivery, whereas an http-equiv meta-tag may carry the same information to transcoders safely;
f) WML is an XML dialect, which supports the meta-tag http-equiv, at the usual place in markup documents (in the head, after XML and DOCTYPE declarations), and thus does not entail special parsing mechanisms to handle this feature;

Hence, the inspection of the http-equiv meta-tag should apply to HTML and all XML dialects that include it (at least XHTML, XHTML mp, XHTML basic, WML) and this should be duly specified in the CTG, with proper references to applicable specifications. This ought also to take care of future markup languages in the Web, whatever they may be (HTML 5.0 comes to mind). This must be made explicit in the guidelines, otherwise there will be no normative statement to check against desired or undesired behaviour. 

E.Casais

Received on Wednesday, 12 November 2008 15:53:06 UTC