People are going to use off-the-shelf JSON parsers because they're the obvious tool for the job. It seems like a general maxim that if we prohibit using the obvious tools without a really good reason (which I don't really see here), people are just going to ignore the prohibition.
--Richard On Wed, Sep 17, 2014 at 12:42 PM, Tim Bray <[email protected]> wrote: > The chance of the JOSE working group moving the vast world of deployed > JSON infrastructure round to 0.00. Thus putting a MUST reject in here > would essentially say you can’t use well-debugged production software, and > would be a really bad idea. > > On the other hand, if JOSE specified that producers’ messages MUST conform > to I-JSON, and a couple other WGs climbed on that bandwagon, and the word > started to get around, I wouldn’t be surprised if a few of the popular JSON > implementations added an I-JSON mode. That would be a good thing and > lessen the attack surface of all JSON-based protocols (which these days, is > a whole lot of them). > > > > On Wed, Sep 17, 2014 at 7:43 AM, Stephen Kent <[email protected]> wrote: > >> OK, now I have a clear answer to the question I posed earlier, i.e., this >> is a JSON parser problem, not specific to the JOSE-defined formats. >> >> I still believe it makes sense for the RFC(s) to mandate rejection of >> duplicates, >> as a way to "encourage" transition to better parsers, as others have >> noted. And >> I rely on Tero's judgement that the required changes are not onerous. >> >> Steve >> > > > > -- > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
