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

From: eric bianchetti <[email-masked]>
Date: Tue, 9 Feb 2010 18:31:36 -0800 (PST)

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 <[email-masked]>
Subject: Re: [http-state] non-ASCII cookie values (was Re: Closing
    Ticket 3:    Public Suffixes)
To: Julian Reschke <[email-masked]>
Cc: [email-masked]
Message-ID:
    <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 3, 2010 at 12:50 AM, Julian Reschke <[email-masked]> 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

---

From: Adam Barth <[email-masked]>
Date: Tue, 9 Feb 2010 18:40:36 -0800

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

---

From: eric bianchetti <[email-masked]>
Date: Tue, 9 Feb 2010 18:55:23 -0800 (PST)

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 

as it would mean no browser involvement.

my 2 cents only

Eric

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

Thanks,
Adam

On Tue, Feb 9, 2010 at 6:31 PM, eric bianchetti
<[email-masked]> wrote:
> Cc: mailto:[email-masked]
> Message-ID: