I agree with you Dick, but some developers complained that they "couldn’t
re-use their string parsers" (despite no existing parser supporting key=“value”)
so now we have to double escape backslashes. I very much feel that this is tail
wagging the dog.
> On 3 May 2021, at 01:25, Dick Franks <rwfra...@gmail.com> wrote:
>
> All,
>
> I have considerable difficulty with these test vectors at the end of
> Appendix D.2:
>
> 16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
> 16 foo.example.org. alpn=f\\\092oo\092,bar,h2
>
> \# 35 (
> 00 10 ; priority
> 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
> 00 01 ; key 1
> 00 0c ; param length 12
> 08 ; alpn length 8
> 66 5c 6f 6f 2c 62 61 72 ; alpn value
> 02 ; alpn length 2
> 68 32 ; alpn value
> )
>
> which appear to be incompatible with RFC1035 5.1 paragraph 10:
>
> Because these files are text files several special encodings are
> necessary to allow arbitrary data to be loaded. In particular:
>
> ...
>
> \X where X is any character other than a digit (0-9), is
> used to quote that character so that its special meaning
> does not apply. For example, "\." can be used to place
> a dot character in a label.
>
> \DDD where each D is a digit is the octet corresponding to
> the decimal number described by DDD. The resulting
> octet is assumed to be text and is not checked for
> special meaning.
>
> The intention appears to be to include (a) a single arbitrary octet in
> the argument, and (b) a plain text comma not being a delimiter in the
> argument list. The specimen result is consistent with that assumption.
>
> Armed with the weapons supplied by RFC1035, the obvious way to
> represent such an argument is: alpn="f\092oo\,bar,h2"
>
>
> A parser adhering strictly to RFC1035 zone file escape conventions:
>
> #!/usr/bin/perl
> use Net::DNS 1.31;
> use Net::DNS::ZoneFile;
>
> my $zonefile = new Net::DNS::ZoneFile(\*DATA);
> while ( my $rr = $zonefile->read ) {
> $rr->print;
> }
> exit;
>
> __DATA__
> rfc1035-compliant.example. SVCB 16 foo.example.org.
> alpn="f\092oo\,bar,h2"
>
> produces the desired wire-format image:
>
> rfc1035-compliant.example. IN SVCB ( \# 35 0010 ; 16
> 03666f6f076578616d706c65036f7267 00 ; foo.example.org.
> 0001 000c 08665c6f6f2c626172026832 )
>
> Other parsers are available.
>
>
> The test vectors, as written, appear to rely upon somehow reactivating
> the special meaning of the escape character which is explicitly
> disallowed by RFC1035.
>
> The result in each case is:
>
> non-compliant.example. IN SVCB ( \# 37 0010 ; 16
> 03666f6f076578616d706c65036f7267 00 ; foo.example.org.
> 0001 000e 06665c5c6f6f5c03626172026832 )
>
> the escaped escape characters being inserted as uninterpreted text per
> RFC1035.
>
>
> Dick Franks
> ________________________
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
