But... it's not actually discardable. The hypothetical "packet" architecture
(using the term architecture somewhat loosely) needed the information being
tunneled in by this character. If it was actually discardable, then the "noop"
character wouldn't be required as it would be discarded.
Ah, sorry. I meant to say that the string should always be normalized (not
"sanitized") before being checked for exploits (i.e. sanitized).
-Original Message-
From: Sławomir Osipiuk [mailto:sosip...@gmail.com]
Sent: Sunday, June 23, 2019 20:28
To: unicode@unicode.org
Cc: 'Richard
On the subject of security, I've read through:
https://www.unicode.org/reports/tr36/#Deletion_of_Noncharacters which says:
"The issue is the following: A gateway might be checking for a sensitive
sequence of characters, say "delete". If what is passed in is "deXlete", where
X is a noncharacter,
> (1) When can we anticipate that the USE spec will be updated to provide
> support for subjoined consonants below vowels (as required for TAI THAM) ?
• The exact scope is actually about allowing conjoined consonant forms (either
encoded with a stacker, or encoded atomically?) after vowel
On Sat, 22 Jun 2019 21:10:08 -0400
Sławomir Osipiuk via Unicode wrote:
> In fact, that might be the best description: It's not just an
> "ignorable", it's a "discardable". Unicode doesn't have that, does it?
No, though the byte order mark at the start of a file comes close.
Discardables are a
On Sat, 22 Jun 2019 23:56:50 +
Shawn Steele via Unicode wrote:
> + the list. For some reason the list's reply header is confusing.
>
> From: Shawn Steele
> Sent: Saturday, June 22, 2019 4:55 PM
> To: Sławomir Osipiuk
> Subject: RE: Unicode "no-op" Character?
>
> The original comment
6 matches
Mail list logo
