On 7/14/25 11:38, Gavin Brown wrote:
Thanks Jorge!
IMHO, the document is pretty much where I wanted to get it, but Maarten did
raise this point:
i would like to see some changes to the data format if possible, now there are
a bunch of nested arrays, as a developer i this is very annoying to work with.
maybe we can make it a bit more developer friendly.
(see: https://mailarchive.ietf.org/arch/msg/regext/Wl7I4AJ663z0W5Wn92pwBrZ42mM/)
I'd appreciate the WG's feedback on this. This was actually the approach I took
in the -00 version, but I changed it to the current syntax after receiving
private feedback.
One benefit of the current approach is that common TTL values, remarks and
events are mapped to multiple DNS record types. This reduces the duplication
(where a link has to be present in several places).
Another approach might be a syntax like this:
{
"objectClassName": "nameserver",
"ldhName": "ns1.example.com",
"ttl": {
"events": [ /* standard RDAP events */ ],
"links": [ /* standard RDAP links */ ],
"remarks": [ /* standard RDAP remarks */ ],
"values": {
"A": 3600,
"AAAA": 86400
}
}
}
Thoughts?
Other than the use of a bare identifier? :)
For clients that use mapping frameworks, some of those frameworks will have
problems with mapping unknown tags and therefore the client implementer will
have to specifically provide a mapping for every RR type.... therefore the
array approach is actually better for them especially if they are general
purpose clients that just display information to users. And given that
special-purpose clients probably already have special-purpose logic, I can't
imagine the arrays are difficult to handle. Therefore I think the current
approach in the draft is better.
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
