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

--------
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.