Date: Mon, 14 Apr 1997 14:20:04 -0700 (PDT) From: Chris Newman <Chris.Newman@innosoft.com> Subject: Re: UTF-8 URL for testing In-Reply-To: <334E7F88.firstname.lastname@example.org> To: IETF URI list <email@example.com> Message-Id: <Pine.SOL.3.95.970414140622.21307Hfirstname.lastname@example.org> On Fri, 11 Apr 1997, Dan Connolly wrote: > Francois Yergeau wrote: > > What is needed is standardization, and I am *not* satisfied with > > the current syntax draft, which continues to ignore a very basic need. > > > > If *recommending* UTF-8 means that URL syntax cannot progress to Draft > > Standard, so be it: recycle to Proposed and come back in 6 months. > > That makes sense to me. I don't consider this a minor cleanup of RFC1738 > and RFC1808, but a fairly substantial re-write where we should take the > opportunity to make some cost-effective changes like this one. I do not believe the current URL syntax draft can or should go to draft standard at this point. At the very least, the relative-URL resolution has completely changed syntax from RFC 1808 (with respect to parameters). While this change may better reflect implementations, it is sufficiently fundamental to the spec that it should be recycled at proposed. In addition, I urge the URL community not to make the same mistake that happened in the email community. RFC 822 was quite clear that 8-bit characters were not permitted in email and did not specify their meaning. People implemented and still implement unlabelled 8-bit characters in email with completely non-interoperable behavior -- despite MIME's existance. For URLs we can come up with all the perfectly valid reasons why US-ASCII only would work better in practice, but that does not reflect reality. I think it is inappropriate for the next URL spec to fail to provide an unambiguous interoperable way to support multilingual characters. I see no reasonable alternatives on the table to the proposed UTF-8 language.