I think it’s a nice clean minimal solution to say that producers MUST NOT generate dupes, end of story. I don’t think saying anything beyond that adds value. -T
On Wed, Jun 26, 2013 at 9:07 PM, Mike Jones <[email protected]>wrote: > The alternative is to say that producers MUST NOT produce JSON with > duplicate member names and that consumers are strongly RECOMMENDED to > reject input with duplicate member names and leave it at that. > > I understand not wanting to require customer parsers if the underlying > platform parsers are deficient. But I really hope that the JSON WG will > have more sense than to allow the current madness to continue. As I > understood it, the primary motivation for the JSON WG in the first place > was to change the SHOULD to a MUST. If they don't do that, I'm really not > sure what the point of it is. > > -- Mike > > P.S. I am a subscriber to the JSON mailing list, but unfortunately, the > volume got so high a few weeks ago that trying to keep up with it became an > impediment to getting real work done. At that point I created a rule to > file those messages into a folder, which I only rarely look at. Has that > situation improved? > > -----Original Message----- > From: Jim Schaad [mailto:[email protected]] > Sent: Wednesday, June 26, 2013 8:18 PM > To: Mike Jones; [email protected] > Cc: [email protected] > Subject: RE: [jose] #27: member names MUST be unique needs additional text > > I would strongly encourage everyone in the JOSE list to join the JSON list > and read what was is there and participate. > > That being said there are situations where you might not be able to do an > independent parser. And in fact what you have stated is that there is now > a requirement that a JOSE library supply a JSON parser. Is that really > what we want to say? How far from creating a set of generator and parser > requirements that are non standard and requiring a parser/generator are we > from that? > > > -----Original Message----- > > From: Mike Jones [mailto:[email protected]] > > Sent: Wednesday, June 26, 2013 12:30 PM > > To: Jim Schaad; [email protected] > > Cc: [email protected] > > Subject: RE: [jose] #27: member names MUST be unique needs additional > > text > > > > The operable sentence in my suggested text below is this one: "If the > > platform's JSON parser does not reject input with duplicate member > > names, the input will first need to be separately parsed to reject > > these invalid inputs before using the platform's parser". In other > > words, if the JSON parser in the development platform you are using > > does not reject inputs with duplicate member names, you will need to > > write a separate JSON parser that detects this invalid input and rejects > it. > > > > This parser could either just be a validator, returning TRUE or FALSE > > for whether the JSON is valid for JOSE - in which case you'd then pass > > any inputs validating as TRUE to the platform's JSON parser, or it > > could be a replacement parser, in which case your code would not use > > the development platform's JSON parser at all. I suspect people would > > be more likely to do the former than the latter, but both approaches are > equivalent. > > > > BTW, if it's your sense that there's a problem occurring in the JSON > > working group with respect to enabling strict JSON parsing, we > > probably need to become active there. For instance, even if the spec > > allows duplicate member names like the ECMA spec does, the RFC could > > recommend or require that parsers support a "strict" mode, which rejects > these unnecessarily lax inputs. > > Then JOSE implementations could use that. > > > > -- Mike > > > > -----Original Message----- > > From: Jim Schaad [mailto:[email protected]] > > Sent: Wednesday, June 26, 2013 11:30 AM > > To: 'jose issue tracker'; > > [email protected]; > > Mike Jones > > Cc: [email protected] > > Subject: RE: [jose] #27: member names MUST be unique needs additional > > text > > > > <no hat> > > > > I consider myself to be reasonably competent in both English and > > Technical English. I have no idea what I am supposed to be doing to > > deal with the text below. Does this mean that I need to write an > > independent parser? What about cases where it is coming in on a > > stream and I don't get to see the data before the parse occurs? How > > are they interpreted differently? What exactly is this supposed to be > > addressing. Much of this could be skipped when we said don't do it. > > Since this is no longer a viable statement due to the state of parsers, > we need to be more explicit and say what is going on. > > > > No I don't consider the suggested text to be adequate. > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf > > > Of jose issue tracker > > > Sent: Tuesday, June 25, 2013 5:41 PM > > > To: [email protected]; > > > [email protected] > > > Cc: [email protected] > > > Subject: Re: [jose] #27: member names MUST be unique needs > > > additional text > > > > > > #27: member names MUST be unique needs additional text > > > > > > > > > Comment (by [email protected]): > > > > > > The JWS draft currently says: > > > > > > The Header Parameter Names within the JWS Header MUST be > unique; > > > JWSs with duplicate Header Parameter Names MUST be rejected. > > > > > > How about changing this to: > > > > > > The Header Parameter Names within the JWS Header MUST be > unique; > > > JWSs with duplicate Header Parameter Names MUST be rejected. > > > This is necessary to prevent attacks in which the same JWS > > > might be interpreted > > > in different ways by different implementations and to > > > prevent > > attackers > > > from hiding extra content in duplicate member values. > > > If the platform s JSON parser does not reject input with > > > duplicate member names, > > > the input will first need to be separately parsed to reject > > > these invalid inputs > > > before using the platform s parser. > > > > > > -- > > > -------------------------+------------------------------------------ > > > -------------------------+-- > > > -------------------------+-- > > > -------------------------+--- > > > Reporter: | Owner: draft-ietf-jose-json-web- > > > [email protected] | [email protected] > > > Type: defect | Status: new > > > Priority: major | Milestone: > > > Component: json-web- | Version: > > > signature | Resolution: > > > Severity: - | > > > Keywords: | > > > -------------------------+------------------------------------------ > > > -------------------------+-- > > > -------------------------+-- > > > -------------------------+--- > > > > > > Ticket URL: > > > <http://trac.tools.ietf.org/wg/jose/trac/ticket/27#comment:1> > > > jose <http://tools.ietf.org/jose/> > > > > > > _______________________________________________ > > > jose mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
