- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Thu, 3 Apr 2008 21:29:06 +0200
- To: ietf-http-wg@w3.org
Julian Reschke wrote: >>> There's an overlap with issue 74 >> I don't understand section 5 in RFC 3987. Are HTTP >> implementors forced to grok IRI comparison ? What >> has this to do with I18N for <Reason-Phrase> ? > That's what I'm asking you :-) LOL. Okay, then I'd say <Reason-Phrase> used to be a string of Latin-1 octets carefully avoiding CR and LF. There could be a Latin-1 IRI in <Reason-Phrase>, but Latin-1 IRIs are not sexy, unlike KOI8-R IRIs. ;-) In other words, as long as HTTP headers can't do "raw" UTF-8 we can ignore IRIs. Folks wanting them anyway find the recipe to transform any IRI into an URI in RFC 3987. As soon as it's an URI it's US-ASCII and we can forget Latin-1 wrt IRIs. In a <Reason-Phrase> or elsewhere. Using IRIs or URIs within an in essence unstructured part of a header field has similar problems as using IRIs or URIs in text/plain mail or news bodies: Put them in angle brackets, maybe use <URL: .. >, or not. In the case of a header field they could end up in an 2047/2231 <encoded-word>, a seriously bad idea. But hopefully not bad enough to talk about it in 2616bis. I've never seen a 2047/2231 encoded IRI. >> Sanity check, we don't want folding there, right ? > I don't think so. That's what i94 is about. Good.
Received on Thursday, 3 April 2008 19:27:52 UTC