Re: Libraries assuming iso-8859-1 (was: Re: Consensus call to include Display Strings in draft-ietf-httpbis-sfbis)

> On 30 May 2023, at 5:04 am, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Mon, May 29, 2023, at 02:16, Mark Nottingham wrote:
>> So, while I think it would be great if we could use UTF-8 in HTTP 
>> fields directly, I agree with Julian's characterisation of this as 
>> appropriate for an experiment, not something that we should include in 
>> infrastructure like SF -- implying that it has to be very highly 
>> reliable. 
> 
> I'm inclined to agree.  But, if we proceed with %"..%xx." now, what would UTF-8 look like?  "ε", %"∝", or something new like '§'?  I would like to run that experiment: it would be the most efficient and most natural thing to do, but I share at least some of your concern about the risks (which are largely a function of middleware: CDNs, stacks, WAFs, etc...).  That is tempered by Roy's points about the feature being introduced alongside a feature.  Upgrading software should be justifiable if the feature provides enough incentive; but would we want to deploy a new valuable feature with something like this that might add deployment hurdles?
> 
> What might we also do to prepare for such an experiment? Preparation can make success more likely.  It seems to me like maybe specifying the new type now is how you get the new type recognized ahead of the time that you run the experiment.  Keep in mind that %"" doesn't have an immediate customer either.

This is a very good question; I'm not sure what the answer is. In my mind, anything in SF should be _very_ solid; that rules out putting it in the spec alongside %"...". Could we write a separate spec that defined a SF extension that has to be explicitly referenced, and that explains the limitations?



--
Mark Nottingham   https://www.mnot.net/