From: "Larry Masinter" <firstname.lastname@example.org> To: "Leslie Daigle" <leslie@Bunyip.Com> Cc: "URI distribution list" <uri@Bunyip.Com> Date: Tue, 1 Sep 1998 19:25:16 PDT Message-ID: <email@example.com> In-Reply-To: <Pine.SUN.3.95.980901100647.12597Bfirstname.lastname@example.org> Subject: equivalence relationships... > Software that interprets URIs as the names of local resources SHOULD > accept multiple renditions of the URIs in the case where those > resources names might have non-ASCII representations; this includes > accepting both the URI syntax of section 2.1 and the 8URI form in > section 2.2. You're right, this is just too fuzzy to stay as is, and it combines a couple of different pieces of advice. a) For servers that currently accept 'native' encodings, continue to do so. b) In any case, accept both canonical UTF8 URIs and 8URIs c) Consider carefully applying aliasing and fuzzy matching in order to simplify the typin strategy. (a) and (b) are a matter of accomodating both current and upgraded software. (c) is not to accomodate software, but a matter of dealing with users who might otherwise have trouble typing URLs. > If there is not a well-known, algorithmically-applicable set of > rules to achieve this set of "multiple renditions", this should not > be suggested as a "SHOULD". You're right. (a) and (b) can be SHOULD, (c) is a MAY.