- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Tue, 15 Apr 1997 10:30:53 PDT
- To: Gary Adams - Sun Microsystems Labs BOS <Gary.Adams@east.sun.com>
- Cc: uri@bunyip.com, fielding@kiwi.ics.uci.edu, Harald.T.Alvestrand@uninett.no
> Are there any "facts" still in need of investigation > or are the only unresolved issues questions of "opinion"? (My opinion > is that the current system is already broken, if this could be > subtantiated would that invalidate the "status quo" as a viable > alternative?) At this point, I think we need not just "facts" but some actual "design". Exactly how does this all work in a way that actually solves the problem? Let's suppose someone wants to publish information about their product and put up a URL in a magazine. a) what URLs do they support in their server? b) what gets printed in the magazine? c) what does the user type into the browser? d) what does the browser do with what the user typed in order to turn it into the URL that was generated in (a). how does this work for 1) Japanese (16-bit characters) 2) Hebrew (right to left) What happens with "/" and the path components? How does directionality get represented? What are the considerations for ambiguity beyond the familiar 0O0O0O1l1l1l for ASCII? When the details of this are worked out, and we actually have something that works to allow non-ASCII URLs, then we can look and see if %xx-hex encoded UTF-8 encoded Unicode actually forms part of the solution. But it doesn't seem "trivial" to me, or at all certain that the current proposal is actually part of the solution. Regards, Larry -- http://www.parc.xerox.com/masinter
Received on Tuesday, 15 April 1997 13:33:38 UTC