Tom Hume wrote:
>
> Some thoughts after a read through the latest draft:
>
> 1. In section 1.3 the term "distributed user agent" is used. What does
> this mean?
I guess we may remove "distributed" if that's not clear, the meaning
being that the user agent black box in that case is composed of a local
component (from the end-user's point of view) and a remote one, and is
thus distributed.
> 2. JSON or AJAX requests might also fit the definition of "web browsing"
> but should probably avoid transcoding. I realise this has already been
> discussed...
An AJAX HTTP request and responses cannot be easily, if at all, identified.
A JSON HTTP request can probably be if the "Accept" HTTP header is
restricted to (or would "contains" be enough?) "application/json". A
JSON HTTP response can be identified through the Content-Type HTTP header.
I would not mind adding a guideline that prevents transformation of JSON
requests/responses, but I am not sure it truly addresses an existing
problem. Are you aware of any existing problem with that?
>
> 3. In section 4.1.2, reference is made to no-transform headers being
> used in XmlHttpRequests... but no-transform isn't mentioned in the XHR
> spec that's referred to. Is this a suggestion that they be used as a
> matter of course in XHR? Seems a bit cheeky to insert this stuff into
> someone else's spec if so ;)
I do not think that having Cache-Control: no-transform directives used
as a matter of course is such a good practice.
The important stuff is that the XmlHttpRequest API allows developers to
add the directive.
>
> 4. Section 4.1.3 seemed to be a bit stronger previously, placing the
> onus on proxies to ensure they only transcoded web content. In the
> current version this requirement isn't there, and the doc says "careful,
> or you'll break something".
The problem is that it only "seemed" stronger.
We are trying to remove normative statements that look like wishful
thinking but cannot be enforced in practice. There is no normative way
to detect "Web content intended for regular browsing".
>
> 5. Section 4.1.5.3, para 2, sentence 1: what's the thinking behind this
> being a should, rather than a must?
>
> 6. Section 4.1.6.1: again, what's the thinking behind this being a
> should, rather than a must?
I suggest we go through the document once we're "done" with the
remaining topics and balance "SHOULD vs. MUST" then.
>
> 7. The issue of WML is worth raising - HTML is referred to in many
> places, but many sites (e.g. all WALL-based ones) will multiserve WML,
> so it should be considered no? I know this is a topic of discussion
> already...
I agree.
I also agree with Eduardo's proposals to:
1. include *WML* when we talk about *HTML* content
2. prevent restructuring and recoding (while still allowing
optimizing) when proxies encounter a WML DOCTYPE or WML MIME type
I do not know if transformations other than compression are applied to
WML content (i.e. to transform from WML to WML), though. Are there any?
I note that this would de facto prevent conversion of WML content to
(X)HTML, but think it is OK, because a server that serves WML content is
already aware of the mobile context, and most WML developers probably
are aware of the existence of non-WML browsers among mobile devices.
>
> 8. I'm not sure what section 4.2.8.1 is saying: that transformation
> should only occur to improve the user experience? What sorts of
> transformation would be disallowed here (that might actually occur)? UE
> is (as I think has been discussed already) a sadly vague term...
Discussed and removed during last call.
Francois.