+1 - my original feedback was: > - Because this specification requires use of I-JSON, it should be clarified > whether non-conforming messages are required to be rejected. See RFC7493 > Section 3. I'd suggest this NOT be required (but we still need to be explicit > about that).
... for the reasons you point out. Cheers, > On 19 Feb 2026, at 8:40 am, Vladimír Čunát > <[email protected]> wrote: > > Hello, reading through the draft again: > >> If the EXTRA-TEXT field does not conform to the I-JSON requirements >> [RFC7493], the client MUST treat the data as invalid and MUST NOT process it >> according to this specification. > > > I wonder if these hard requirements are a bit impractical. Do the > JSON-parsing libraries commonly expose options which detect *exact* > conformance to that RFC? > Also my reading of the RFC7493 gives me vibes of primarily being meant for > JSON producers (to voluntarily restrict to outputs which are more > interoperable), less for JSON parsers to reject more inputs. > I know I'm a bit late, and I'm not much on client side of EDE myself, so... > no hard feelings if this remains. Also, maybe I've missed a message > explaining the reasons for this; I'm sure I haven't read all of them about > this draft. > > --Vladimir | knot-resolver.cz > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
