Re: comment for draft 071124

Jo,

Thanks for the draft. Yes I understand it is still a draft, and I'm  
reading it as such. This particular phrase jumps out and I'd rather  
say it early in the process.

Perhaps this is a different way of interpretation. When a content  
provider says no-transform , I'd assume the content provider  
understands it really means nothing is to be changed, and that the  
content owner takes full responsibility even if it breaks the browser.

At the very least, the use of the word "SHOULD" is too strong in that  
sentence. If I interpret RFC 2119 correctly, you are recommending  
transformation proxies to implement this kind of "dangerous markup"  
detection, which is I think not well defined at the moment, and not  
sure if it ever will be. Perhaps changing it to "may" would be better.  
The technology is evolving and there are different kinds of content  
transformation services. Some are more tightly tied to the browser  
than others, and may take a greater part in rendering (WMLC etc.). In  
that case, it makes sense for the transformation server to warn the  
user. But if it's a third party transformation server, I don't think  
it makes sense to say it "should" take care of "bad markup" even if  
the origin server says no-transform. The point is not that CT proxies  
should not do it, the point is not to make it a recommendation that CT  
proxies detect the currently fuzzy and ever-changing "bad markup" when  
the content owner says no-transform.

How about this:

As an exception to the previous requirement, a CT proxy MAY deny CP  
directives that would result in dangerous markup being sent to the  
browser.

On Dec 9, 2007, at 1:26 PM, Jo Rabin wrote:

> Thanks for this contribution, Nigel.
>
> You'll have noticed that section 2 doesn't completely tie in to  
> sects 3
> and 4 at the moment. It's my own view that if you say no-transform  
> that
> means nothing must change at all. While my view is that I'd like to  
> give
> content providers the power to do that, in general I'd strongly  
> advocate
> not saying that and saying something slightly less severe and blunt
> edged. As proposed in section 4 of the current draft.
>
> However, there are circumstances in which the CP should have this  
> power
> and I agree that it should be their prerogative.
>
> Jo
>
>
>
>> -----Original Message-----
>> From: public-bpwg-ct-request@w3.org
> [mailto:public-bpwg-ct-request@w3.org]
>> On Behalf Of Nigel Choi
>> Sent: 09 December 2007 19:38
>> To: public-bpwg-ct@w3.org
>> Subject: comment for draft 071124
>>
>>
>> As a content provider, I take issue with this sentence in section
>> 2.3.1 and 2.5.1:
>>
>> "As an exception to the previous requirement, a CT proxy should deny
>> CP directives that would result in dangerous markup being sent to the
>> browser."
>>
>> How does that work in relation to Cache-Control: no-transform ? Does
>> the Cache-Control: no-transform take precedence, i.e. the proxy sends
>> the markup unaltered IN ANY CASE back to the browser, or does the
>> above requirement take precedence?
>>
>> It will be problematic if it is the latter. I understand this
>> requirement is noble, and we have all seen what bad markup will do to
>> mobile browsers. However, this may be a difficult requirement to
>> fulfill in practice. The problem is in the definition of "dangerous
>> markup." This assumes the content transformation proxy knows better
>> than the content owner what is "dangerous" for the phone. What if it
>> is wrong? What if the content owner sends the markup for a reason?
>> What do you mean by "dangerous?" Without a clear definition of
>> "dangerous markup" one can go down the slippery slope of banning
>> content that the proxy operator deems "dangerous."
>>
>> I propose that this sentence be removed from the requirement  
>> entirely.
>>
>> Thanks,
>> Nigel.
>>
>

Received on Sunday, 9 December 2007 23:19:56 UTC