Re: [http-state] New Issue: The domain attribute and I18N domain names

Peter Saint-Andre <> Wed, 03 February 2010 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D5BC3A6CCC for <>; Wed, 3 Feb 2010 11:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.742
X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mf7qoFAQ3Y5m for <>; Wed, 3 Feb 2010 11:17:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E9153A6CC9 for <>; Wed, 3 Feb 2010 11:17:47 -0800 (PST)
Received: from ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id E6C7740332 for <>; Wed, 3 Feb 2010 12:18:29 -0700 (MST)
Message-ID: <>
Date: Wed, 03 Feb 2010 12:18:28 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <op.u7jnvc0pqrq7tp@acorna.invalid.invalid>
In-Reply-To: <op.u7jnvc0pqrq7tp@acorna.invalid.invalid>
X-Enigmail-Version: 1.0
OpenPGP: url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms040602020206010709090603"
Subject: Re: [http-state] New Issue: The domain attribute and I18N domain names
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Feb 2010 19:17:48 -0000

On 2/3/10 2:12 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> Hello all,
> AFAICT the current draft does not address how servers should specify
> domain names in the domain attribute of a Set-Cookie header when the
> Unicode form of the domain name contain non-ASCII characters, e.g.
> blåbæ (
> My suggestion is that the A-label (punycode) form should be used in all
> cases, but if that is too strict the only other alternative is to allow
> UTF-8 encoding of the name in addition to the recommended use of the
> A-label.

That seems reasonable because it is consistent with the IDNA2008 work,
but be aware that once you go down that path you might never be able to
switch to UTF8-encoded domain names because you'll need to interoperate
with software that only does A-labels and not U-labels. Forever. But
picking one format is better than allowing both A-labels and U-labels, I
think. Your Applications Area Advisor was heavily involved in the
IDNA2008 effort, so she might have some valuable insights here. :)


Peter Saint-Andre