Subject: More on allowed field characters

From: "Martin Thomson" <[email-masked]>
Date: Mon, 23 Aug 2021 15:03:09 +1000

Hey all,

It seems like the allowed characters in fields is a gift that keeps on giving.

Roy opened https://github.com/httpwg/http2-spec/issues/902 asking about DQUOTE and "(),/:;<=>?@[]{}".

The text is here: https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#name-field-validity

When we made changes for field validation, our intent was not to override requirements in core semantics, but to specify just the bare minimum for interoperability and security.  For interoperability we dropped uppercase field names.  For security, the focus was on request smuggling.  So we block NUL, CR, LF, and COLON, but not a whole lot more.

We ended up saying the following about general validity:

> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by Section 5.1 of [HTTP] and Section 5.5 of [HTTP] as malformed (Section 8.1.1).

That is, requests that contain DQUOTE and friends are still invalid, but we don't require that HTTP/2 implementations specifically look for those octets and treat those messages as malformed.

Roy points out that there are connected systems (like CGI, which communicates using environment variables; yes in 2021) that depend on field names not containing the above characters.  I believe that those systems are still protected by the rules in -semantics.  That is, after all, the most appropriate place for requirements of that nature.

The point of the text in HTTP/2 was to strengthen requirements.  I've reordered the text in https://github.com/httpwg/http2-spec/pull/936 and I think that is sufficient for this case.

Cheers,
Martin

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 23 Aug 2021 07:44:14 +0200

Hi Martin,

On Mon, Aug 23, 2021 at 03:03:09PM +1000, Martin Thomson wrote:
> The text is here:
> https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#name-field-validity
> 
> When we made changes for field validation, our intent was not to override
> requirements in core semantics, but to specify just the bare minimum for
> interoperability and security.  For interoperability we dropped uppercase
> field names.  For security, the focus was on request smuggling.  So we block
> NUL, CR, LF, and COLON, but not a whole lot more.
> 
> > A recipient MAY treat a message that contains a field name or value that
> > includes other characters disallowed by Section 5.1 of [HTTP] and Section
> > 5.5 of [HTTP] as malformed (Section 8.1.1).
> 
> That is, requests that contain DQUOTE and friends are still invalid, but we
> don't require that HTTP/2 implementations specifically look for those octets
> and treat those messages as malformed.
> 
> Roy points out that there are connected systems (like CGI, which communicates
> using environment variables; yes in 2021) that depend on field names not
> containing the above characters.  I believe that those systems are still
> protected by the rules in -semantics.  That is, after all, the most
> appropriate place for requirements of that nature.

One concern that I do have with leaving them allowed in H2 implementations
is that it *will* create interoperability issues between H2 implementations.
Those who implement both the client and the server will put whatever in that
and call that H2, and the day an intermediary arrives in the middle, this
will break, forcing the intermediary to relax its rules and enter a new
class of problems when it has to deal with other versions.

Another example I mentioned previously was chars > 0x7F. This could let
utf-8 chars be used and then it will become a security issue, because
you can be certain that some characters will be transcoded along the
chain and that some header fields could be aliased depending on how
implementations deal with charsets, or worse, well-known names such as
Connection, Host or Transfer-Encoding could be produced as the result
of the transcoding of homoglyphs.

With this said, I think I understand the point you're trying to address.
HPACK is designed to be completely generic and is binary transparent, so
that in a layered design it is not easy to filter invalid characters in
the HPACK layer (just in case it comes from a generic lib that could be
used elsewhere). In addition to this, the fact that HPACK works as a
dictionary is a real pain because it forces to check everything at the
output, since the bad characters that are inserted into it could be
reused for a subsequent request.

And doing so at the semantics layer could be too late as well (e.g. the
recent report about H2 issues with :method, :authority, :path that have
to be validated before being assembled for the semantics layer).

> The point of the text in HTTP/2 was to strengthen requirements.  I've
> reordered the text in https://github.com/httpwg/http2-spec/pull/936 and I
> think that is sufficient for this case.

I think that the risk remains opened that the spec is quickly overlooked
and that those who consider they don't need to enforce semantics will
make use of those invalid chars. What about adding this before the
paragraph you moved:

  Even though HPACK is capable of carrying field names or values that
  are not valid in HTTP, HTTP/2 implementations MUST NOT emit names
  nor values that include characters disallowed by [HTTP].

This will be sufficient to declare any such sender non-compliant and
then it makes sense to go on with your paragraph suggesting that a
recipient may reject this one as malformed.

Regards,
Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 23 Aug 2021 15:53:08 +1000

On Mon, Aug 23, 2021, at 15:44, Willy Tarreau wrote:
> Another example I mentioned previously was chars > 0x7F. 

We currently disallow >= 0x7f in field names for that reason.

>   nor values that include characters disallowed by [HTTP].

That would be fine with me (s/emit/generate/), apart from it being somewhat redundant with HTTP.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 23 Aug 2021 07:58:43 +0200

> That would be fine with me (s/emit/generate/), apart from it being somewhat

I know but when you see certain stuff like gRPC which try to be very
intimate with H2 without real consideration for upper layers, you figure
that if H2 is considered as convenient for some uses, it makes sense to
remind certain important points that can definitely cause interoperability
issues.

Cheers,
Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 23 Aug 2021 16:20:29 +1000

Hey Willy,

Take another look at the text I've added to https://github.com/httpwg/http2-spec/pull/936

It now goes:

* HPACK can carry anything.
* HTTP defines what is valid.
* Recipients can treat anything that is not valid as malformed (using our formal definition).
* This section includes additional validation requirements.
* <those additional requirements>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 23 Aug 2021 09:30:31 +0200

> * <those additional requirements>

OK, looking at it in the whole context, I think it better addresses the problem:
  - http framing mentions malformed messages
  - malformed messages refer to [HttpHeaders] for the the definition of
    invalid field names or values
  - [HttpHeaders] has a Field Validity subsection which starts by defining
    malformed as anything that doesn't strictly follow HTTP.

It is also mentioned that intermediaries must not forward malformed messages.

However the next paragraph mentioning this does still maintain some confusion:

  A field name MUST NOT contain characters in the ranges 0x00-0x20, 0x41-0x5A, or 0x7F-0xFF
  (all ranges inclusive).  This limits field names to visible ASCII characters, other than
  ASCII SP (0x20) and uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a).

Especially this last sentence which *seems* to endorse the use of such
other characters for header field names, thus contradicting the first points.

Why not instead merge these two paragraphs into a single one:

  All HTTP/2 implementations MUST validate fields in messages they receive as follows:
  ...
  A field name MUST NOT contain characters outside the range permitted
  by [HTTP-5.1]. A field value MUST NOT contain characters outside the
  range permitted by [HTTP-5.5].

This allows to even remove the last few points about special cases for names
vs values.

I would personally be fine with going further in the spirit of the strictness
of the initial work on H2 by declaring as dangerously non-compliant any sender
of some of the invalid characters you wanted to block above, and protect against
their inclusion into the HPACK dictionary:

   An HTTP/2 recipient that receives a field name containing a character
   in the range 0x00-0x20, 0x41-0x51, or 0x7F-0xFF (all ranges inclusive),
   or a field value containing a character 0x00 (NUL), 0x0A (LF), 0x0D (CR)
   MAY treat this as a connection error of type PROTOCOL_ERROR.

But I also understand that this could punish blind H2->H2 coalescing gateways
that have no idea what they're dealing with, and might be a bit extreme.

Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 23 Aug 2021 17:49:23 +1000

Thanks Willy,

Yeah, that's a mistake.  How about:

> This specifically excludes all non-visible ASCII characters, ASCII SP (0x20), and uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a).

I don't think that we need to combine paragraphs as you suggest.  The point is that these are *extra* checks that apply even if you are only forwarding messages.  (RFC 7540 basically said what you suggest and it turned out that no one paid any attention to it.)

>    MAY treat this as a connection error of type PROTOCOL_ERROR.

A connection error is something we already permit.  It's just indirect.  You have to follow the chain from here to the definition of malformed and then to stream errors, but it's there.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 23 Aug 2021 18:15:57 +1000

> It seems like the allowed characters in fields is a gift that keeps on

My wife tells me that now I know what it feels like to be a woman in
technology.... say something over and over for ages and people take little
notice... but when some dude called Roy says it everybody says "oh yeah!!"
  :)

> https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#name-field-validity

I'm not sure that https://github.com/httpwg/http2-spec/pull/936/files
actually resolves the concerns Roy raises in #902.

Roy asks (as I did) why are we allowing any of these non valid HTTP
characters to be considered possibly valid (or just not invalid) in h2?  I
think to really address #902 then the "MAY treat non valid HTTP characters
as malformed" needs to at least be upgraded to a SHOULD.

If we really REALLY need to allow some implementation to accept some
non-valid HTTP characters, then having something along the lines of what
Willy suggests that has a "MUST NOT generate invalid HTTP" would go a long
way to satiate

cheers

-- 
Greg Wilkins <[email-masked]> CTO http://webtide.com

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 23 Aug 2021 10:53:54 +0200

On Mon, Aug 23, 2021 at 05:49:23PM +1000, Martin Thomson wrote:
> I don't think that we need to combine paragraphs as you suggest.  The point
> is that these are *extra* checks that apply even if you are only forwarding
> messages.

This is interesting because your expressed intent here is particularly
important but it doesn't translate well into the text. I mean, once the
intent is known it makes sense, but the text alone is not sufficient to
figure the intent and we still risk lazy checks there. Then why not
completely reformulate the introductory line around this:

  Field Validity

  HTTP/2 and HPACK are length-delimited and technically permit any
  character to be encoded. Attacks targetting HTTP/2 implementations
  exploit ambiguous header component delimiters before the message is
  reassembled and submitted to HTTP semantics checks, or forwarded. For
  this reason, immediately after HPACK decoding and before trying to
  process or forward an HTTP message, all HTTP/2 endpoints MUST
  validate fields in message they receive as follows:

  (... then we can go on with the current enumeration ...)

And at the end of this enumeration:

  These checks represent the strict minimum that permits to safely
  reconstruct a safe HTTP message, are not exclusive with the HTTP
  semantics checks on header field syntax described in HTTP#5.1 and
  HTTP#5.5.

>  (RFC 7540 basically said what you suggest and it turned out that
> no one paid any attention to it.)

Yeah I understand. It was so easy to overlook parts of 7540 :-)

> A connection error is something we already permit.  It's just indirect.  You
> have to follow the chain from here to the definition of malformed and then to
> stream errors, but it's there.

This is a good point indeed.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 23 Aug 2021 10:59:32 +0200

Hi Greg,

On Mon, Aug 23, 2021 at 06:15:57PM +1000, Greg Wilkins wrote:
> characters to be considered possibly valid (or just not invalid) in h2?

Actually that was my concern as well but Martin mentions he only tried
to enforce *extra* checks. Thus it's more a matter or formulation or
where it's placed. Please have a look at the proposal I made in this
thread to explain that this is not exclusive to existing checks.

> I

I also think SHOULD is wanted.

> Willy suggests that has a "MUST NOT generate invalid HTTP" would go a long

In my opinion we really do not want them to appear on output nor on input,
and it's fortunate that PortSwigger recently reminded to us how brittle
all this currently is :-)  

Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 24 Aug 2021 11:19:53 +1000

> thread to explain that this is not exclusive to existing checks.

I think that's right.  I've attempted to paraphrase your suggestions on the pull request.
 
> I also think SHOULD is wanted.

I am thinking that neither is correct: we should assume that endpoints will apply those rules.  This is mostly about forwarding and other intermediary processing.  We should just note that those rules exist and note that they could be enforced (either additionally or instead, it doesn't matter as the effect is the same).

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Aug 2021 11:43:22 +1000

> On 23 Aug 2021, at 3:53 pm, Martin Thomson <[email-masked]> wrote:
> 

Perhaps:

Note that Section 5.1 of [HTTP] prohibits implementations from generating field names that include some additional characters, even though HPACK is capable of carrying them.

Cheers,

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 26 Aug 2021 15:51:32 +1000

> It seems like the allowed characters in fields is a gift that keeps on giving.

Thanks everyone for all the words you gave.

Based on feedback from Willy and Greg in particular, I've taken another go at this:

  https://github.com/httpwg/http2-spec/pull/936/files

It says that:

* fields SHOULD be validated properly (according to HTTP §5.1 and §5.5)

* failure to validate fields might enable attacks, especially if the message ends up in HTTP/1.1 somehow (that is, providing motivation that was lacking from previous iterations on this)

* if fields aren't fully validated, attacks might happen, so minimal validation MUST be performed (with the checks previously agreed)

This does not address Roy's original point directly.  Yes, code that makes assumptions without taking responsibility for checking them might be exposed to the full consequences of poor decisions.  However, I believe that a lot of implementations will abide by the SHOULD here.  This is about levying requirements on implementations that might have expected to avoid having to validate fields; because we've learned that copying and pasting without checking happens.

(I do worry that this is an overreaction.  The original text in the spec was arguably fine.  It was just being ignored.)

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 26 Aug 2021 08:50:52 +0200

>   https://github.com/httpwg/http2-spec/pull/936/files

Thanks Martin, as discussed, I'm overall OK with it (though I'd like to
add some guidance regarding the risks caused by pseudo-hedaer fields
reassembly).

> * failure to validate fields might enable attacks, especially if the message
> ends up in HTTP/1.1 somehow (that is, providing motivation that was lacking
> from previous iterations on this)
> 
> * if fields aren't fully validated, attacks might happen, so minimal
> validation MUST be performed (with the checks previously agreed)
> 
> This does not address Roy's original point directly.  Yes, code that makes
> assumptions without taking responsibility for checking them might be exposed
> to the full consequences of poor decisions.  However, I believe that a lot of
> implementations will abide by the SHOULD here.  This is about levying
> requirements on implementations that might have expected to avoid having to
> validate fields; because we've learned that copying and pasting without
> checking happens.

I'm fine with tunnels or H2-H2 gateways blindly forwarding HEADERS frames
without verifying anything there. They're just taking the risk that their
stream or connection is killed on the next hop by violating some SHOULD or
MUST. The risk really is huge when H2 is implemented as a second protocol
next to H1 because known-reliable code is reused (which is better than to
reinvent new stuff and insert new bugs) but this code wasn't necessarily
designed to be exposed to certain delimiting characters that were previously
filtered out by the parser in H1. This is why I find this additional warnings
useful. And pseudo-headers can strike even when H2 is alone but reassembles
a start line that is processed by regular code.

> (I do worry that this is an overreaction.  The original text in the spec was
> arguably fine.  It was just being ignored.)

Yep, at least with the extra words, there's no more excuse for overlooking
this aspect. It's no more just a definition of what is called a header field
but there are some instructions and warnings around that. But I too was
concerned by the previous wording leading to Roy's reaction that could also
be read as "you're allowed to use all this in H2, make your choice".

Thanks,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 26 Aug 2021 11:13:20 -0700

> On Aug 25, 2021, at 10:51 PM, Martin Thomson <[email-masked]> wrote:
> 

I think my issue is still being misunderstood.

I don't think we need every implementation to do field validation on every receipt
or forwarding of HPACK fields. I think we need to be clear on what the requirements
for field validation are when extracting HPACK-encoded strings and using them
in an HTTP context, whether that context be for HTTP fields in other versions,
CGI environment variables, Servlet tables, or an internal data structure for request
processing. The point is that the implementation translating HPACK to an abstract
HTTP message (regardless of version) MUST ensure that the result fits within
all of HTTP's field requirements when that field is used as HTTP, since the
implementation cannot trust the HPACK encoder.

Specifically, coming up with an arbitrary set of different requirements for that
process is NOT GOOD. I understand one desire to do that is because h2 has
the additional restriction of all-lowercase names, but the right way to say that
is as an additional requirement for h2, not by trying (and failing) to subsume
the existing requirements of HTTP.

I think it is fine if this is limited specifically to those recipients actually doing
HTTP things with HTTP fields, as opposed to merely forwarding arbitrary fields
at scale, but it cannot be limited just to HTTP/1. This is an application issue for
anything that consumes an HTTP message. It is still necessary even if an
h2-only server receives a request and directly handles it via an internal
application library. The vulnerability may be inside the application library,
but the h2 server is expected to prevent it because that's where the rubber
meets the road.

Likewise, an HPACK decoder MUST produce valid HTTP field values if they
are going to be used as HTTP field values.

I am fine with HPACK also being used to convey UTF-8 named fields and/or
carrying binary field values, but only when that is clearly indicated via the
protocol and processed as such.

I want the h2 spec to say something like:

   When an implementation extracts a field name string from HPACK and
   intends to use that string as an HTTP field name (semantically), the
   implementation MUST validate the strict intersection of the existing
   MUST requirements on syntax (ref. field-name ABNF [SEMANTICS]
   with uppercase excluded) when extracted from HPACK and used
   with the semantics of an HTTP field name. This is particularly important
   when the received header fields are transformed as a whole from one
   form (i.e., HPACK) to another (e.g., a translated header section, an
   internal hash table, or a set of environment variables).

IOW, don't make up new requirements based on perceived syntax issues.
Refer to the specific syntax required by HTTP and add the h2-specific
limitations, since any variation might result in unforeseen differences
in downstream handling of that message.

....Roy

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Aug 2021 11:21:05 +1000

How is this not a core HTTP problem?

Part of the intent of the change is to leave the validation to core specs.  If you are using h2 fields as HTTP fields, the rules for HTTP already cover that use.

There are two extra things we do in h2:

1. deny uppercase field names
2. mandate extra checks from an abundance of caution

(The latter might be mere paranoia, but it's demonstrably necessary.)

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 27 Aug 2021 13:42:10 +1000

Martin, Roy,

How about the latest text is augmented to say something like:

The HPACK is able to transport characters that are not valid HTTP and as
such HTTP/2 implementations may be used for
non-HTTP semantic transport.  HTTP/2 implementations that are used to
represent HTTP semantics MUST validate field
names and values according to their definitions in Sections <xref
target="HTTP" section="5.1" format="counter"/>

I.e make it really clear that when HTTP/2 impl is being used with the core
HTTP spec then it MUST comply with that spec.  If it is transporting
non-HTTP compliant headers, then it make it clear it is not representing
HTTP semantics.

regards

On Fri, 27 Aug 2021 at 11:24, Martin Thomson <[email-masked]> wrote:

> Part of the intent of the change is to leave the validation to core
> specs.  If you are using h2 fields as HTTP fields, the rules for HTTP
> already cover that use.
>
> > > * failure to validate fields might enable attacks, especially if the
> message ends up in HTTP/1.1 somehow (that is, providing motivation that was
> lacking from previous iterations on this)
> > >
> > > This does not address Roy's original point directly.  Yes, code that
> makes assumptions without taking responsibility for checking them might be
> exposed to the full consequences of poor decisions.  However, I believe
> that a lot of implementations will abide by the SHOULD here.  This is about
> levying requirements on implementations that might have expected to avoid
> having to validate fields; because we've learned that copying and pasting
> without checking happens.
> > >
> > > (I do worry that this is an overreaction.  The original text in the
> spec was arguably fine.  It was just being ignored.)
> >

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Aug 2021 07:20:19 +0200

> non-HTTP compliant headers, then it make it clear it is not representing

I think it's roughly the same as what is already there, but I'm fine
with this. However I really want that we keep the extra caution about
the risk of failing to filter out CR/LF/COLON from these fields by
reusing known valid code which was not subject to this before H2, and
that we add the caution on what must absolutely be filtered out of
pseudo-header fields before reassembling them.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 27 Aug 2021 06:49:37 +0000

--------
Roy T. Fielding writes:

> carrying binary field values, but only when that is clearly indicated
> via the protocol and processed as such.

I looked into this as part of Structured Headers, and I can say
rather conclusively that nobody competent would do that.

The average symbol length in HPACK's huffman table is 18.2 bits, so 
high entropy binary data, be it due to compression or encryption,
encodes to more than twice the original size, +128% to be precise.

The HPACK huffman table could have been designed to minimize UTF-8's
penalty, at no cost to the lower 128 ASCII characters, but it almost
looks like the opposite was attempted.

It is impossible to put a representative number on the UTF-8
pessimization, but given the magnitude of it, I think the original
"frownie", U+2639, is a proper example:

In UTF-8 it becomes (0xe2, 0x98, 0xb9) which HPACK expands to 65 bits.

In comparison "\u2639" only takes 48 bits.

According to my experiments, base64 is the optimal HPACK encoding
for high entropy binary data, obviously reflecting its popularity
in the random sample of HTTP headers that went into the HPACK table
design.

The base-64 characters average 6.46 bits per symbol making the
overhead just:

	4 * 6.46 / 3 = 8.62 bits/byte = 7.8% 

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 27 Aug 2021 09:33:42 +0200

> Am 27.08.2021 um 08:49 schrieb Poul-Henning Kamp <[email-masked]>:
> 
> --------
> Roy T. Fielding writes:
> 

Nicely analysed.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 27 Aug 2021 09:13:02 -0700

> On Aug 26, 2021, at 11:49 PM, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------
> Roy T. Fielding writes:
> 

That's funny. I just spent three years updating a 30 year old protocol
and am quite sure that (aside from Referer and TE) field names are
rarely chosen for efficiency. If-Moderated-Since is my worst.

> 	4 * 6.46 / 3 = 8.62 bits/byte = 7.8% 

That's nice to know. Maybe we should add a "check your HPACK length"
resource somewhere, or a new flag on curl for evaluating extension names.

....Roy

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 30 Aug 2021 11:52:50 +0900

> rarely chosen for efficiency. If-Moderated-Since is my worst.

Isn't that If-Modified-Since ? (one character shorter :-)

Regards,   Martin.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 30 Aug 2021 13:23:15 +1000

> In comparison "\u2639" only takes 48 bits.

Huffman coding is optional, so it can stay at 48.

The good news here is that there might be a point in our future where interpreting fields as UTF-8 is interoperable.  The charset debate has ended for sure, we just have to wait for the remnants of the other charsets to clear themselves out.  Maybe there will be enough progress by 2028 that we'll be able to do something else.

I'm content to wait a while longer before exploring that space; though I appreciate the efforts of pioneers to brave the incompatibility hazards in search of whatever it might be you get here.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 30 Aug 2021 05:50:48 +0200

On Mon, Aug 30, 2021 at 01:23:15PM +1000, Martin Thomson wrote:
> The good news here is that there might be a point in our future where
> interpreting fields as UTF-8 is interoperable.  The charset debate has ended
> for sure, we just have to wait for the remnants of the other charsets to
> clear themselves out.  Maybe there will be enough progress by 2028 that we'll
> be able to do something else.

I personally hope this will never happen for field names. UNICODE was
made for humans and we're discussing protocols to let computers interact.
Placing emojis there is useless. However we know that there is a very high
risk of aliasing between different values, that *will* cause a lot of
security trouble and interoperability issues.

Just my two cents,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 30 Aug 2021 14:52:32 +1000

> made for humans and we're discussing protocols to let computers interact.
+2c!