Re: Feedback on CT Document

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.

Received on Wednesday, 26 November 2008 16:22:43 UTC