<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Nov 2024 at 21:16, Doug Barton via net-dns-users <<a href="mailto:net-dns-users@lists.nlnetlabs.nl">net-dns-users@lists.nlnetlabs.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ok, I give up.<br>
<br>
Are you willing to at least point me in the right direction to do what <br>
I'd like to do?<br></blockquote><div><br></div><div>I am prepared to deliver, in 1.49, a sensible return value for each SVCB key instead of the unworkable RFC1035 presentation format about which you complained at the start of this conversation.</div><div>The returned value will be the uninterpreted octet string, exactly as it appears on the wire.</div><div>The wire format for each key is defined in RFC9460. Unpacking that in your application should be straightforward.<br></div><div><br></div><div>Generic RFC3597 format will remain as the zonefile representation. Although it may be possible to recover the symbolic format for registered keys, the only way to mix these with unregistered keys would necessitate the use of the RFC1035 presentation format from which you have already discovered it is difficult to extract the raw octet string.<br></div><div><br></div><div>--rwf<br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
net-dns-users mailing list<br>
<a href="mailto:net-dns-users@lists.nlnetlabs.nl" target="_blank">net-dns-users@lists.nlnetlabs.nl</a><br>
<a href="https://lists.nlnetlabs.nl/mailman/listinfo/net-dns-users" rel="noreferrer" target="_blank">https://lists.nlnetlabs.nl/mailman/listinfo/net-dns-users</a><br>
</blockquote></div></div>