Re: [jose] #27: member names MUST be unique needs additional text

["Jim Schaad" <[e-mail]>]

When the volume is high is when one needs to keep track of the what is going on.  If the volume is low then you can ignore it.

There have not been any recent discussions on parsers but I don't know what you mean by improved so I cannot make a statement one way or the other on that.  I have always had the mail moved into a folder and go in and read it in one big shot once or twice a day unless I am currently involved in a discussion.  I find that technique works well.

Jim


> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 9:07 PM
> To: Jim Schaad; [e-mail]
> Cc: [e-mail]
> Subject: RE: [jose] #27: member names MUST be unique needs additional text
> 
> 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:[e-mail]]
> Sent: Wednesday, June 26, 2013 8:18 PM
> To: Mike Jones; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, June 26, 2013 12:30 PM
> > To: Jim Schaad; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > Sent: Wednesday, June 26, 2013 11:30 AM
> > To: 'jose issue tracker';
> > [e-mail];
> > Mike Jones
> > Cc: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On Behalf
> > > Of jose issue tracker
> > > Sent: Tuesday, June 25, 2013 5:41 PM
> > > To: [e-mail];
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [jose] #27: member names MUST be unique needs
> > > additional text
> > >
> > > #27: member names MUST be unique needs additional text
> > >
> > >
> > > Comment (by [e-mail]):
> > >
> > >  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-
> > >   [e-mail] |  [e-mail]
> > >      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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/jose
>