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

[Tim Bray <[e-mail]>]

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 <[e-mail]>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:[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
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>