At 02:13 PM 7/20/2002, Chris Haynes wrote: > "Larry Masinter" wrote: > > > > I propose to NOT fold in the IRI definition, but to allow > > it to proceed along standards track at its own pace. The > > revised URI standard can note the IRI work as a separate > > effort. > >I don't want to pre-empt the IRI experts, but I have a hunch that >giving the URI %HH escapes a formal definition of representing UTF-8 >(rather than the present undefined encoding) would help the IRI >activity enormously. My guess is it would leave them free to define a >canonic mapping of IRIs into URIs without requiring any further URI >spec. changes. There is an underlying flaw in that concept. Many browsers and servers today are passing or inferring non-utf-8 input from the URI or header fields. Many are passing utf-8 data. As the specification makes no preference or definition, the server is responsible for inferring some meaning by the context of the request by the client, and returning the response in kind. >If I'm right, would this simple change be out of scope? Making such a change by fiat would be inappropriate. Some additional information has to be passed by the client to preempt any inference of the high-bit octet codes. If this were a change to the HTTP/1.2 specification, that would be the indicator that all headers and the URI itself are utf-8 encoded. Without a bump of the HTTP version number, it's entirely out of scope. I'm not clear here about Larry's intent, so I will ask; Larry, did you mean for the next document revision to spell out an HTTP/1.2 conformance? If not, is Chris Haynes' proposal out of line, if he introduces the appropriate header field definition to assert that the client and server treat the now-opaque octets %80-%FF as utf-8? BillReceived on Saturday, 20 July 2002 19:53:12 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 October 2007 06:11:42 GMT