- From: Eduardo Casais <casays@yahoo.com>
- Date: Mon, 1 Dec 2008 04:57:47 -0800 (PST)
- To: public-bpwg-ct@w3.org
Tom,
It seems to me that your message got mangled during editing. Here are some comments.
> On (a):
>
>1. If the end-result of HTTPS rewriting is a poor user
>experience (thanks to broken scripts, missing variables)
>then I think that's no different from transcoding in general.
Correct, this is no different than transcoding, and my point is that the CTG should not deal with specifying how to perform specific transformations -- whether it is https URI rewriting, character encoding, markup conversions, table linearization, image rescaling, cookies mapping, or anything else.
>On (b), it seems this is no different to any proxy
>operation.
Correct, so why are the CTG singling out https rewriting without dealing with other security issues as well? My proposal is to handle all these aspects in one section "security considerations".
>On (c), I agree, though can't see how (5) will be
>reached.
Probably thus:
no-transform in requests => requests upstream no longer get modified; no-transform in responses => responses downstream no longer get modified.
>On (d), I can imagine a user case. Many sites use
>HTTPS on simple login forms as gateways to the rest of
>the service. I'd be personally happy to login to Amazon,
>for instance, using transcoded HTTPS. I'm not sure I
>agree with the argument that this is a contrived use case.
So far, only abstract justifications have been provided. Whenever a concrete case is proposed as an example, it appears to be artificial, as there is always a pefectly valid and usable mobile alternative. Thus for Amazon:
"A different version of this web site containing similar content optimized for screen readers and mobile devices may be found at the web address: www.amazon.com/access"
BA.com had been mentioned earlier -- the BA site has a mobile-specific version. Web-mail from a Nokia 6230i had been mentioned -- this model has a mobile-optimized e-mail client. And so on, and so forth.
A non-contrived, reasonable, real use case justifying https in the absence of a valid mobile alternative proves elusive.
E.Casais
Received on Monday, 1 December 2008 12:59:01 UTC