On Tue, May 4, 2021 at 12:09 PM Dick Franks <rwfra...@gmail.com> wrote:
> The brutal reality is that the char-string parser has already
> obliterated the distinction between escaped and unescaped commas
> before the value-list parser is invoked.
>
Yes, hence the use of "\\," for embedded commas in value-list values.
> > If we use single-layer escaping, this arrangement is not possible.
> Instead,
> > (1) we would need to add complexity to the char-string parser that is
> shared by many RR types.
> > (2) we would need to integrate key-type-specific behavior into the
> tokenizer, complicating the interface between the parsing function and the
> SvcParams implementation.
>
> >
> > In the draft's arrangement, those implementation choices are allowed,
> but not required.
>
> By publishing test vectors including escaped escapes effectively makes
> these required,
To be clear, it is the text of the document, not the test vectors, that
creates this requirement. The test vectors merely complement the normative
requirements, which already detail this arrangement.
...
> For the sanity of all concerned, SVCB should adhere to the same
> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
>
I think that's a good description of why this arrangement was chosen.
Lifting comma-handling up into the char-string parser would result in SVCB
using a _different_ escape convention from all the other RR types. This
arrangement ensures that, to the extent possible, SVCB uses the _same_
escaping as all the other RR types. It also ensures that all the SvcParams
use the same basic parser.
Value-list parsing is a detail, not of SVCB, but of certain SvcParam types
within SVCB. Consider a future SvcParam whose presentation value is
defined to be JSON. Shall we require that the zone file parser switch to
JSON mode based on the key name, to parse jsonThing={"foo": "quote: \""}?
No, we will declare that this value is wrapped in a char-string as
jsonThing="{\"foo\": \"quote: \\\"\"}". Yes, this is less convenient to
type by hand, but the alternative is to have a "char-string parser" that
mixes in all the syntaxes of all the SVCB value types. That way lies
madness.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
