> On 21 Jul 2020, at 04:39, Dick Franks <rwfra...@gmail.com> wrote:
> 
> 
> On Thu, 16 Jul 2020 at 21:17, Ben Schwartz <bem...@google.com> wrote:
> 
> Quotes are optional, as with <character-string>.  Quotes are only required if 
> the value contains whitespace.
> 
> I was trying to establish if the quotes indicated the data type.  Clearly not.
>  
> The presentation format is optimized for humans and the wire format is 
> optimized for machines. In particular, when using the named keys it's not 
> obvious what the numeric ordering is, so keeping them in order when editing a 
> zone file by hand would be hard.
> 
>   blog.cloudflare.com.        300     IN      HTTPS   ( 1  . 
>      
> key1=\005\104\051\045\050\057\005\104\051\045\050\056\005\104\051\045\050\055\002\104\050
>      key4=\104\018\026\046\104\018\027\046
>      
> key6=\038\006\071\000\000\000\000\000\000\000\000\000\104\018\026\046\038\006\071\000\000\000\000\000\000\000\000\000\104\018\027\046
>      )
> 
> "optimized" is not the word which springs to this human's mind.
> IMHO, tarted up RFC3597 format is easier to read. 

Well the presentation form clearly is designed for printable ASCII to be 
rendered as ASCII.

> Example:
> 
>     use Net::DNS;
> 
>     my $rr = new Net::DNS::RR <<'END';
>     example.net.        300     IN      HTTPS   1 target.example.net.
>         mandatory=key0,key1,alpn,no-default-alpn,key99  ; with duplications 
> and other sins
>         alpn=h3-29,h3-28,h3-27,h2
>         no-default-alpn
>         port=1234
>         ipv4hint=192.0.2.1,192.0.2.2
>         echconfig=base64string
>         ipv6hint=2001:DB8::1,2001:DB8::2
>     END
> 
>     $rr->print;
> 
> produces:
> 
>     example.net.    300     IN      HTTPS   ( \# 126 0001
>         06746172676574076578616d706c6503 6e657400 ; target.example.net.
>         0000 0004 00010002

Which is a interesting conversion of 
"mandatory=key0,key1,alpn,no-default-alpn,key99”. I would expect the parser to 
reject the record as mandatory contains “key0” in the list.  I would also 
expect the parser to reject the record as there is no “key99” in the record.  I 
would never expect the parser to strip out keys listed in mandatory just 
because they are not present in the rest of the record.

>         0001 0015 0568332d32390568332d32380568332d 3237026832
>         0002 0000
>         0003 0002 04d2
>         0004 0008 c0000201c0000202
>         0005 0009 6dab1eeb8b2dae29e0
>         0006 0020 20010db8000000000000000000000001 
> 20010db8000000000000000000000002
>         )
> 
> Observations and complaints gratefully received.
> 
> --Dick
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> 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

Reply via email to