> On Dec 18, 2020, at 07:13, Katarina Eriksson <gmym at coopdot.com> wrote: > > Help! I'm getting pulled in! Katarina! Thanks for dropping by! Welcome to the party! ? ? > I'm assuming including me here was intentional. I truly can't tell if that is an accurate description of my possession. Thanks for noticing. Timing is everything. See Cunningham's Law ? > "I used to be in the US-ASCII only camp" refers to me no longer thinking requiring everything to be encoded to pass as US-ASCII is the best idea. This is me moving away from the status quo towards a possible compromise. Or am I missing where we're going? Indeed, this is the crux of the issue, the notorious IRI vs. URI chasm: native UTF vs ASCII encoded. > I see no reason to %-encode those non-ASCII bytes in the client or anywhere else. Surely I have missed something obvious somewhere. Can anyone help me? Genau. As it stands, the spec mandates URIs -therefore ASCII only- making UTF IRIs V E R B O T E N! NICHT GUT! NOT COMPLIANT! ? ? Now that we all took time to survey the lay of the land, the question is: should the specification be amended to refer to IRI (urn:ietf:rfc:3987), instead of URI (urn:ietf:rfc:3986)? As simple as that. That's all folks! ????
---
Previous in thread (26 of 34): 🗣️ Katarina Eriksson (gmym (a) coopdot.com)
Next in thread (28 of 34): 🗣️ Björn Wärmedal (bjorn.warmedal (a) gmail.com)