W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: support for non-ASCII in strings, was: signatures vs sf-date

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 02 Dec 2022 19:53:30 +0000
Message-Id: <202212021953.2B2JrUC2007352@critter.freebsd.dk>
To: "Roy T. Fielding" <fielding@gbiv.com>
cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
--------
Roy T. Fielding writes:

> > Roy T. Fielding writes:
> > 
> >> FWIW, there is nothing technical preventing a requirement that sf 
> fields
> >> support UTF-8 by default.
> > 
> > (... provided they are somehow escaped into USASCII visibility.)
>
> No, I meant UTF-8, as in coded 8-bit unicode. They don't interfere with parsing
> when inside a not-yet-standard field-value, whether or not it is a structured field.
> They are, of course, not allowed in current sf field values, but I am not aware of
> any implementations that invoke an sf parser on unknown fields.

You lost me here...

RFC9110 says:

	field-value = *field-content
	field-content = field-vchar [ 1*( SP / HTAB / field-vchar ) field-vchar ]
	field-vchar = VCHAR / obs-text

RFC5234 says

	VCHAR          =  %x21-7E ; visible (printing) characters

How then can you move UTF-8 without escaping it into USASCII visibility ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 2 December 2022 19:53:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:47 UTC