On Wed, Sep 14, 2022 at 10:42:26AM +0200, libor.peltan wrote:
> Dne 13. 09. 22 v 18:21 Viktor Dukhovni napsal(a):
> > The "OPT-RR" is message metadata, and so should not be confused with
> > other sorts of additional records. (TSIG would also fall into that
> > bucket).
>
> Thank you for this point. So we should invent a way how to convert OPT
> record into properties of the JSON-represented message structure.
That could be useful. Someone would have to invest the energy to push
this forward. Do you have the cycles?
> > I should also note that in terms of presentation forms, the SVCB record
> > is particularly challenging, since it also sports extensible options of
> > arbitrary types, and requires both a generic presentation form (for not
> > known options) and a type-specific form for known options.
>
> It seems that SVCB will be standardized soon, which makes me think that
> we may inspire ourselves.
Well, there is presently no specification of a JSON representation of
SVCB records. The wire forms in combination with the presentation names
of the options generally suggest somewhat natural encodings, but the
larger picture is IMHO somewhat murky. The RRtype in question has
elements of an "open" type (new field schemata can be added as we
go along). We specify wire forms and (zone file) presentation forms,
but neither is sufficient for an interoperable and natural JSON form.
Just capturing the presentation form is unappealing, since it represents
lists and other structured elements poorly.
> It might be possible to invent a presentation format for EDNS (despite
> it does not appear in zonefiles, it should be still useful for other
> purposes), which would use the same tricks as SVCB presentation format.
> What do you think?
Sure, but is there enough "energy" (enthusiasm) to do this?
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
