John R Levine wrote:
>
> I'm close to that. If a field is odd but it's a minor variant of something
> else, such as the hex fields with optional hyphens or dots, it's easy enough
> to include. Or if it seems like it might be useful in the future, like a
> trailing list of
When I looked at this in 2012 I concluded that the best approach would be
to keep the generic language REALLY simple, and that RDATA with special
needs would have to have a custom-coded parser/serializer.
I'm close to that. If a field is odd but it's a minor variant of
something else, such as
John R Levine wrote:
>
> That's the eventual plan, although there is a long tail of funky field types
> found only in RRs that nobody uses any more.
When I looked at this in 2012 I concluded that the best approach would be
to keep the generic language REALLY simple, and that
If you want to do that, you could probably piggyback it on my recently
revived draft-levine-dnsextlang.
Interesting. I vaguely remember someone (Olafur?) also had a similar
approach to dynamically describing RTYPE in the DNS itself. Or maybe
it was actually this draft that I am thinking of?
Shane Kerr wrote:
> At 2016-09-05 11:22:48 +0100
> Tony Finch wrote:
> > Shane Kerr wrote:
> > >
> > > It occurs to me that maybe we want an option to have arrays of RRset
> > > instead of arrays of RRs?
> >
> > If you do
In your letter dated Mon, 5 Sep 2016 15:47:37 +0800 you wrote:
>Finally, I note that the RIPE Atlas system uses a type of DNS JSON
>representation when you use their API to query for DNS measurement
>results. You can get a sample here:
>
In your letter dated Tue, 6 Sep 2016 06:26:58 + you wrote:
> I was more commenting on the fact that it is escaping in a format
> that already support escaping. The JSON output would be double
> escaped and implementations would need to unescape it themselves
> rather then let JSON handle it.
Hi Paul,
On 09/05/16 17:40, Paul Hoffman wrote:
> On 5 Sep 2016, at 1:42, Jerry Lundström wrote:
>
>> - Non-ASCII octets escaping "\DDD" may lead to broken implementations
>> and/or encoding problem (oh so many printf()'ed JSON implementations out
>> there)
>
> Sure, but I'm not sure what to do