I am attacking you. Why would I care about what the restrictions on producers are?
From: Tim Bray [mailto:[email protected]] Sent: Wednesday, June 26, 2013 10:24 PM To: Mike Jones Cc: Jim Schaad; [email protected]; [email protected] Subject: Re: [jose] #27: member names MUST be unique needs additional text 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
