Re: "Difficult Characters" draft
Alain LaBont/e'/ <alb@sct.gouv.qc.ca> Tue, 06 May 1997 20:34 UTC
Received: from cnri by ietf.org id aa04131; 6 May 97 16:34 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa18516; 6 May 97 16:34 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id QAA20367 for uri-out; Tue, 6 May 1997 16:18:30 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA20362 for <uri@services.bunyip.com>; Tue, 6 May 1997 16:18:28 -0400 (EDT)
Received: from socrate.riq.qc.ca (socrate.riq.qc.ca [199.84.128.1]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id QAA28266 for <uri@bunyip.com>; Tue, 6 May 1997 16:18:23 -0400 (EDT)
Received: from riq-44-239.riq.qc.ca by socrate.riq.qc.ca (5.x/SMI-SVR4) id AB11946; Tue, 6 May 1997 16:23:55 -0400
Message-Id: <3.0.1.16.19970421161022.08f7bb0c@riq.qc.ca>
X-Sender: alb@riq.qc.ca
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 14 (16) [F]
Date: Mon, 21 Apr 1997 16:10:22 -0000
To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
From: Alain LaBont/e'/ <alb@sct.gouv.qc.ca>
Subject: Re: "Difficult Characters" draft
Cc: URI mailing list <uri@bunyip.com>
In-Reply-To: <Pine.SUN.3.96.970506210330.245U-100000@enoshima>
References: <3.0.1.16.19970422141730.2b8f756c@riq.qc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-uri@bunyip.com
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by services.bunyip.com id QAA20367
A 21:20 97-05-06 +0200, Martin J. Duerst a écrit : >On Tue, 22 Apr 1997, Alain LaBont/e'/ wrote: > >> From a *real user*'s point of view what you say is disconcerting. In fact >> it does not correspond to a reality I exeperience every day. My insurance >> agent gave me his personal URL last week, for example, URL in which there >> were uppercase letters that were transformed into lower case when Netscape >> displayed the actual URL and in searching with both forms it is allright... > >Well, I just tried the URL, and my Netscape didn't do any lowercasing. Someone does in my environment (I'm not sure it is Netscape)... but I use French versions... of Netscape 2 under Win 3.1 and Netscape 3 Gold under Win95... >But that's a detail. > >> Hence in this actual concrete example, >> >> http://www.LaMutuelle.com/agent/home.htm?aid=S200569 and >> http://www.lamutuelle.com/agent/home.htm?aid=S200569 >> >> are totally equivalent. Changing those habits would not be desirable. > >These are indeed totally equivalent. But try to write > >> http://www.LaMutuelle.com/Agent/home.htm?aid=S200569 or >> http://www.lamutuelle.com/agent/Home.htm?aid=S200569 > >and you will get a nasty error (all in English, with a pointer >to http://www.themutualgroup.com/). Some exceptions and surprises to the >contrary nonewithstanding, an uninformed user has to be tought to copy an >URL as is, including case. A more informed user may know about parts >of an URL that can be changed in capitalization. Actually, you can >write > >> http://wWw.lAmUtUeLlE.CoM/agent/home.htm?aid=S200569 > >and it will still work. But please leave the part after the first >single slash alone. All right... That is not very user friendly. Totally inconsistent... from a user perspective, undesirable... >> In French at least, case doesn't have in general the importance that has in >> German, for example. For accented and unaccented data, of course minimally >> a lower case accented letter should be equivalent to the upper case >> counterpart, but even in lower case, it is desirable that an unaccented >> letter be equivalent to its accented counterpart (an actual case is that it >> is processed like this since 1981 in DOS on a PC) for searching purposes. > >If a lowercase accented letter appears in the later part of an URL, >it won't be equivalent to the corresponding uppercase letter because >there is also no equivalence for nonaccented letters. If I understood well, no equivalences at all even for case. But what about the first part? What about user expectations in inconsistent behaviours? >In case there is indeed equivalence, as we currently have it in domain >names, it will be the task of domain name internationalization to >decide what to do about it, whether to make the usual domain names >case sensitive or whether to introduce case eqivalences for characters >outside ASCII or whatever. There is no problem with any kind of >URL scheme or mechanism to introduce additional eqivalences where >they see fit, but we can't introduce them for all URLs. I'm puzzled that the notion of consistency is neglected... I learned something. >> What I suggest is that searching be done according to the same spirit as >> ISO/IEC CD 14651 which deals with such equivalences. At the limit (this >> does not have an influence on URLs but it should be considered) in >> searching URLs, expectations could be built on LOCALEs... that is what I >> suggest. > >I full agree for searching. However, what is done usually with URLs >is not searching. It is binary matching. Only things that are absolutely >binary equivalent (after the last step in your sorting standard) match. >The normalization procedures in the draft only increase the level a tiny >bit, to avoid those cases where the binary representation is different, >but the user has absolutely no chance to make a difference. > > >> For example as was explained, o and ö are not equivalent in Swedish (while >> they are in German), > >They are definitely not! Otherwise, we wouldn't need the ö :-). >It's only that we don't consider ö a letter of its own, >but that doesn't mean a German wouldn't be able to know where >to put an o and where to put an ö in an URL (with the exception >of those cases where both possibilities make sense and where it >is all the more important to make the difference :-). > > >> n and ñ are not equivalent in Spanish while they are >> in French and so on. That has no impact per se on the making of URLs, but >> it has one on their use, that was the only consideration I was trying to >> suggest. > >I agree that it should have an inpact on the use in searching and such. >But that's not the main function of URLs. Not the main, but if it is a function it becomes problematic. I do not want to be a trouble maker, but just signal problems from a user point of view. Alain LaBonté Québec
- Re: "Difficult Characters" draft Jonathan Rosenne
- Re: "Difficult Characters" draft Michael Kung <MKUNG.US.ORACLE.COM>
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Michael Kung <MKUNG.US.ORACLE.COM>
- Re: "Difficult Characters" draft Larry Masinter
- Re: "Difficult Characters" draft Alain LaBont/e'/
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Alain LaBont/e'/
- Re: "Difficult Characters" draft Alain LaBont/e'/
- Re: "Difficult Characters" draft Larry Masinter
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Larry Masinter
- o and Alain LaBont/e'/
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Alain LaBont/e'/
- Re: "Difficult Characters" draft Martin J. Duerst
- Re: "Difficult Characters" draft Keld J|rn Simonsen
- Re: "Difficult Characters" draft (in URLs) Alain LaBont/e'/
- Re: "Difficult Characters" draft (in URLs) Martin J. Duerst
- Re: "Difficult Characters" draft Larry Masinter
- Re: "Difficult Characters" draft (in URLs) Alain LaBont/e'/
- Re: "Difficult Characters" draft Leslie Daigle
- Re: "Difficult Characters" draft (in URLs) Martin J. Duerst
- Re: "Difficult Characters" draft (in URLs) Larry Masinter
- Re: "Difficult Characters" draft (in URLs) Alain LaBont/e'/
- Re: "Difficult Characters" draft (in URLs) Martin J. Duerst