Parsing as a character-string does not necessarily imply unescaping any
sequence other than \". So you parse as a character-string, then parse again as
a comma-separated string, then unescape the components.
Input: "a\,\000,b\,\000\""
Parsed as character-string: a\,\000,b\,\000"
Split on unesc
Except you can’t actually do that. ‘\044' becomes ‘,' on the first pass if you
parse it as a character string first. The ONLY way this works is if you
remember which commas are escaped or not (\044 or \, vs ,). It’s dead easy to
split it into alpn-id as you unescape the string.
Mark
> On 18
OK, I think I now understand the intent, and refactored my code accordingly,
and it is now simpler and cleaner. Yay.
I think it would be clearer to implementers if section 2.1.1 said that all
values are initially parsed as character-strings (allowed to exceed 255
characters), and then further p
> On 14 Jun 2020, at 05:01, Larry Campbell
> wrote:
>
> I think there's an implementation difficulty. Consider:
>
> 1. alpn=h2 ; clear enough
> 2. alpn="h2" ; should be equivalent
> 3. alpn=\h\2 ; should also be equivalent
> 4. alpn=h2,h3; ok (two
I think there's an implementation difficulty. Consider:
1. alpn=h2 ; clear enough
2. alpn="h2" ; should be equivalent
3. alpn=\h\2 ; should also be equivalent
4. alpn=h2,h3 ; ok (two values)
5. alpn="h2","h3" ; should be equivalent
6. alpn="h2,h3
Seciont 6.1 says:
> The presentation value of "alpn" is a comma-separated list of one or more
> "alpn-id"s. Any commas present in the protocol-id are escaped by a backslash:
>
> escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
> escaped-id = 1*(escaped-octet)
> alpn-value =
