Re: [http-state] non-ASCII cookie values (was Re: Closing

[eric bianchetti <[e-mail]>]

Poor wording of mine , I do agree. 

My interrest is : as web specifications are more and more accepting non ASCII characters set we do have the need to include them in the new specs. It's more a way to prepare the future than to get immediate benefits. I precised the place where I work, because it is a daily reminder to me there is a lot of programmers who are from nonASCII countries.

To answer the other question; I do not think it is the best to be normative; but simply state both ASCII and non ASCII characters set may be used. So, 1 or 2 could be good, with a edge for 

                         1) Recommend non-ASCII characters be encoded into ASCII (for example,
                          with base64).

as it would mean no browser involvement.

my 2 cents only

Eric



----- Original Message ----
From: Adam Barth <[e-mail]>
To: eric bianchetti <[e-mail]>
Cc: [e-mail]; [e-mail]
Sent: Wed, February 10, 2010 9:40:36 AM
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing

I'm sorry, I didn't quite understand your message.  It sounds like
you're interested in non-ASCII cookies because you work in Thailand.

Would you prefer that we:

1) Recommend non-ASCII characters be encoded into ASCII (for example,
with base64).
2) Allow non-ASCII characters and leave the character set undefined
(or up to the server internally).
3) Specify a particular character set, such as UTF-8 or ISO-8859-1.
4) Some other option that hasn't been discussed yet.

Thanks,
Adam


On Tue, Feb 9, 2010 at 6:31 PM, eric bianchetti
<[e-mail]> wrote:
> It was the idea that made me point on the non-ASCII characters. At one moment in a near future we will have to go for them.
>
> Working in a non-ASCII country since 2002 (Thailand); I can tell there is need to include (non normatively for now) non-ASCII characters in the specs (for human and technical reasons).
>
> Some generals wordings , such precising non ASCII have to be encoded (would it be better to precise or not-precise the encoding?) if they are used for cookies.
>
> Eric
>
>
>
>
> Message: 2
> Date: Tue, 9 Feb 2010 08:47:58 -0800
> From: Adam Barth <[e-mail]>
> Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing
>     Ticket 3:    Public Suffixes)
> To: Julian Reschke <[e-mail]>
> Cc: mailto:[e-mail]
> Message-ID:
>     <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Feb 3, 2010 at 12:50 AM, Julian Reschke <[e-mail]> wrote:
>> Adam Barth wrote:
>>> In general, I'm very reluctant to specify a behavior that conflicts
>>> with IE, Firefox, Chrome, and Opera. ?In specific, IE has something
>>> like 99% market share in some Asian markets. ?The fact that this issue
>>> affects Asian markets disproportionately means the pressure to be
>>> IE-like is even greater than usual.
>>> ...
>>
>> On the other hand, why require something that's known not be in use (if that
>> is the case)?
>
> As Maciej points out, this is not the standard of evidence that user
> agent implementors usually use when making compatibility decisions.  I
> understand that this is a bit of a cultural divide in this group, but
> I'll try to give you a flavor of why UA folks think this way.
>
> A number of months ago, I helped change the way JavaScript prototypes
> were configured in WebKit.  Instead of using the lexical or dynamic
> scope (which is what WebKit was using a mix of at the time), we
> changed them to some other esoteric rule that matched Firefox and IE.
> At the time, we had zero evidence that this change had any
> compatibility because the cases where these things are different are
> extremely obscure.  So, why did we change it?  Well, because there's
> no value in being different from other browsers and some (potential)
> value in being the same.  That means the benefit (potentially
> non-zero) outweighs the cost (essentially zero).
>
> Now, as far as I know, the project still has zero evidence that this
> change actually improved compatibility in the real world.  However, I
> happen to know by some random coincidence that this change was hugely
> beneficial.  It just so happens that when folks use both Selenium (a
> popular web application testing harness) and Prototype.js (a popular
> JavaScript library), they arrive in precisely the situation where
> these computations give different answers.  Without the change,
> developers have a lot of trouble testing a Prototype.js-using web site
> with Selenium, but, with the change, it works fine.
>
> So what are the consequences of the change?  Well, it means developers
> are much more likely to test their web sites in Safari because they
> can just re-use their existing Selenium tests instead of having to
> build or find another testing harness.  That means they're more likely
> to fix bugs that affect Safari, which means their web sites will work
> better in Safari.  That, in turns, means users of Safari will have
> better experiences at web sites and the marketshare of Safari will
> grow.
>
> If the WebKit project had required actual examples of the change being
> beneficial, they probably would not have made that change and would
> not have enjoyed the benefits.  Now, not every change pays off as well
> as the one I describe, and, in many cases, we never find out how well
> they pay off.  The point is more that user agent implementing are
> being rational when they make these sorts of decisions.
>
>> If you allow non-ASCII characters (or actually require support), you'll also
>> have to figure out how existing server and client based APIs are to deal
>> with them (so what encoding is it?).
>
> For our purposes, it doesn't really matter how existing servers handle
> the encodings.  In the end, they do what they do.  As long as we send
> the "right" bytes on the wire, they'll do the "right" thing, whatever
> that is.  As for client APIs, yes, we'll need to get that right,
> either in this specification or in the specification of those APIs (as
> we've discussed elsewhere in this thread).
>
> Adam
>
>
>
>