<html>
<body>
At 20:38 22/10/2010, Adam Barth wrote:<br>
<blockquote type=cite class=cite cite="">I'm not sure I quite understood
everything that was mentioned during<br>
this thread. Concretely, here's what cookies need to
do:</blockquote><br>
To make sure we all understand well I think it would be nice to be sure
we talk of the same things in documenting:<br><br>
- who is "we"<br>
- what does mean "receive from the network"<br>
- what is the user agent<br>
- where do we have the URL from ? (in reference for example to the RFC
5895 special case).<br>
- X is a lowercase A-label <br><br>
Suggestion: to be sure you cannot be mistaken, do not consider U-Label as
Unicoded Labels you could match one way or another, but as User-Labels
which can be many different things ranging from ASCII label to a
converted snap of user fingers as Portzamparc hinted it. You will _never_
know which UTS 36, RFC 5895, etc. etc. process has been used to convert
U-labels into lowercase A-labels. Just remember that at Project.FRA we do
not know yet (we want to experiment first with people from many other
languages) how we will support plain French language "U-labels"
as far as majuscules are concerned (same for other Latin languages).
Being a majuscule as impact on the words meaning and this is one of the
metadata information Unicode does not support.<br><br>
I understand that you want to "s<pre>pecify the syntax and semantics
of these headers as they are actually used _on_ the Internet." IMHO
you follow the same thinking as IDNA2003, while IDNA2008 should make you
say "_through_ the Internet". You want to document "on the
rope" something now documented as being "off the rope"
(still networked but controlled by the user). You meet the same problem
as the WG/IDNABIS met. A problem of IS/MUST/SHOULD/MIGHT that demands
that you clarify the scope of the communication process you want to
stabilize to understand where you can use MUST, SHOULD and MIGHT - and if
IS/ARE have to be considered that are imposed on you.
IMHO to be off universal good value cookies should only be Internet
documented semi-stable data containers (therefore relying only on inner
Internet controlled elements such as A-labels).
You cannot know all the different ways people will use it. But you must
tell them that if they want to use it in your way, they MUST follow that
you say. And, because you write a MUST you MUST be in control of the
feasibility of what you demand. On an "end to end" basis you
only control the "inner Internet" (within the Iron Curtain) DNS
entry/output, i.e. the lowercase A-label. And you can also trust it: they
are the xn-- labels Registries have actually registered, under IDNA2003
and IDNA2008. </pre>By nature a robust architecture is synergetic. This
is synergetics.<br><br>
Seen that way, your cookies makes things simple and the whole net simpler
and more robust (RFC 3439) and inscrease the robustness of the whole
internet.<br><br>
jfc<br><br>
<br><br>
<blockquote type=cite class=cite cite="">1) We receive a sequence of
octets from the network, which we convert<br>
to lower case. Let's call this X.<br>
2) We have a URL that the user agent has used to generate an HTTP<br>
request. Let's call the host name component of this URL Y.<br>
3) X is a sequence of octets that's has all the crazy xn-- stuff.<br>
4) We need to transform Y to the crazy xn-- form to see if it's in<br>
some relation to X.<br>
5) For our sanity, we'd like to use octet-by-octet comparison,
without<br>
reference to any kind of folding (e.g., case-folding, IDNA-folding,<br>
etc).<br><br>
As an added constraint, we don't feel its our place to mandate to
user<br>
agents whether they ought to use IDNA2003 or IDNA2008. User
agents<br>
are free to make the decision independently of what the cookie spec<br>
says. You should feel free to lobby them one way or another,
but<br>
we're not going to impose that requirement on them in this
document.<br><br>
My understanding is that the text in the spec meets our
requirements.<br>
If that's not the case, please let me know.<br><br>
Adam<br><br>
<br>
On Fri, Oct 22, 2010 at 7:48 AM, Andrew Sullivan <ajs@shinkuro.com>
wrote:<br>
> On Fri, Oct 22, 2010 at 10:29:19AM -0400, Vint Cerf wrote:<br>
>> andrew,<br>
>><br>
>> we were pretty explicit that the algorithm that produces
A-labels<br>
>> produces only lower case. check with John Klensin.<br>
><br>
> I remember talking about it, and I remember this being an issue<br>
> because Punycode does not actually require lower case. But I
can't<br>
> put my fingers on the text where it says this right now. I
haven't<br>
> looked that hard, however.<br>
><br>
> The reason I haven't looked hard is that it doesn't matter.
There is<br>
> absolutely no way we can enforce any restriction in the DNS
that<br>
> requires the label to remain lower case. Though DNS is
supposed to be<br>
> ASCII-case-preserving but ASCII-case-insensitive, the plain fact
is<br>
> that not every implementation does this, or does it correctly.
(I<br>
> recall quite clearly pointing this out during the WG
discussions,<br>
> because some implementations use compression pointers to the
original<br>
> query string and therefore get whatever was asked by an
application.)<br>
> Applications can put their LDH queries in _in any case at all_
and<br>
> have them work. An IDNA2008-unaware stack with an
IDNA2008-aware<br>
> application above might do anything, including converting
everything<br>
> in the label to upper case (try logging into an old-fashioned
UNIX<br>
> console with the caps lock on. You'll do a lookup for
XN--SOMETHING<br>
> no matter what you intend). If it does that, and happens to
query<br>
> through a caching name server, the upper case form will persist in
the<br>
> cache. You still have to treat that label as matching the
lower case<br>
> U-label. We couldn't do all this above the DNS if you didn't
have to.<br>
><br>
> The case-preserving, case-insensitive feature of DNS was, in my<br>
> opinion, a grave error. But it's an error we have to live
with<br>
> forever if we're going to continue using DNS. You simply
cannot build<br>
> a case-sensitive layer atop the DNS if any of the US-ASCII code
points<br>
> in the labels you want to use are themselves to be case
sensitive. If<br>
> you want to do something clever like Punycode, only for the
entire<br>
> Unicode range (i.e. including that which overlaps with US-ASCII)
so<br>
> that you never have a transparent map between the DNS name and
the<br>
> user-presented name, then you have the possibility of introducing
case<br>
> sensitivity to the naming system (but not the DNS). Otherwise,
you're<br>
> out of luck.<br>
><br>
> A<br>
><br>
><br>
> --<br>
> Andrew Sullivan<br>
> ajs@shinkuro.com<br>
> Shinkuro, Inc.<br>
><br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>