Re: [Json] Counterproposal on work items

The "SHOULD" versus "MUST" caused the JOSE specs to have to include this language in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-08#section-4:

   The Header Parameter Names within this object MUST be unique;
   JWSs with duplicate Header Parameter Names MUST be rejected.

Whereas, if we were referencing a RFC4627bis with the MUST, this language could be softened to be a caution about older JSON parsers, and probably moved to the Security Considerations section.

				-- Mike

-----Original Message-----
From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of Matt Miller (mamille2)
Sent: Wednesday, February 20, 2013 9:43 AM
To: json@ietf.org
Subject: Re: [Json] Counterproposal on work items

On Feb 20, 2013, at 10:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On Feb 20, 2013, at 9:27 AM, Tim Bray <tbray@textuality.com> wrote:
> 
>> My proposal is: do nothing.
>> 
>> I use JSON for protocol design and work all the time, and have not observed any interop problems in the wild which originate at the JSON parson or construction level.  I give the incoming text to the library and it Just Works or reliably reports a syntax botch.  I give my data structures to the JSON serializer and cheerfully send off whatever comes out. I read specs and build clients and servers and, when things break, it's because I'm stupidly using a bogus name or value in some field, not because of the serialization.
>> 
>> I suggest that there is not a problem here that needs the investment of precious IETF time.
> 
> -1.
> 
> There are places where RFC 4627 has SHOULDs where some processors do one thing and others do something different. That should be cleaned up in a standards-track RFC, and it should be done with lots of JSON developers and users having a discussion that comes to rough consensus.

Just to reinforce Paul's point; while things seem to more-or-less work out, there are serious questions occasionally asked about the appropriateness of JSON for use in security protocols given those differences.  It might seem like re-arranging the deck chairs, but that arrangement can be important for acceptance.

- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json