Loading ...
Sorry, an error occurred while loading the content.

A couple of JSON questions

Expand Messages
  • Paul C. Bryan
    I m hoping someone can help explain the rationale behind a couple of points in the JSON specification: 1. 8bit content-transfer-encoding for UTF-8 RFC 4627:
    Message 1 of 9 , Jan 1, 2012
    • 0 Attachment
      I'm hoping someone can help explain the rationale behind a couple of
      points in the JSON specification:

      1. 8bit content-transfer-encoding for UTF-8

      RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
      was 8bit selected rather than binary content-transfer-encoding? This
      limits the length of JSON strings to 994 octets.

      2. Non-unique object members

      RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
      selected rather than MUST?

      Paul
    • Tatu Saloranta
      ... Hmmh? Where does 994 come from? ... I assume this was to allow implementations to choose whether they keep track of all seen names or not: this can add
      Message 2 of 9 , Jan 1, 2012
      • 0 Attachment
        On Sun, Jan 1, 2012 at 9:50 PM, Paul C. Bryan <paul.bryan@...> wrote:
        > I'm hoping someone can help explain the rationale behind a couple of
        > points in the JSON specification:
        >
        > 1. 8bit content-transfer-encoding for UTF-8
        >
        > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
        > was 8bit selected rather than binary content-transfer-encoding? This
        > limits the length of JSON strings to 994 octets.

        Hmmh? Where does 994 come from?

        > 2. Non-unique object members
        >
        > RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
        > selected rather than MUST?

        I assume this was to allow implementations to choose whether they keep
        track of all seen names or not: this can add non-trivial overhead for
        storage requirements, especially when processing JSON data streams.

        -+ Tatu +-
      • John Cowan
        ... I think that statement is just a false assertion rather than a normative restriction. ... Nobody imposes any such limit. ... That s a very good question.
        Message 3 of 9 , Jan 1, 2012
        • 0 Attachment
          Paul C. Bryan scripsit:

          > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible."

          I think that statement is just a false assertion rather than a normative
          restriction.

          > This limits the length of JSON strings to 994 octets.

          Nobody imposes any such limit.

          > 2. Non-unique object members
          >
          > RFC 4627: "The names within an object SHOULD be unique." Why was
          > SHOULD selected rather than MUST?

          That's a very good question.

          --
          We are lost, lost. No name, no business, no Precious, nothing. Only empty.
          Only hungry: yes, we are hungry. A few little fishes, nassty bony little
          fishes, for a poor creature, and they say death. So wise they are; so just,
          so very just. --Gollum cowan@... http://ccil.org/~cowan
        • John Cowan
          ... From RFC 2045: 2.8. 8bit Data 8bit data refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line
          Message 4 of 9 , Jan 1, 2012
          • 0 Attachment
            Tatu Saloranta scripsit:

            > > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
            > > was 8bit selected rather than binary content-transfer-encoding? This
            > > limits the length of JSON strings to 994 octets.
            >
            > Hmmh? Where does 994 come from?

            From RFC 2045:

            2.8. 8bit Data

            "8bit data" refers to data that is all represented as relatively
            short lines with 998 octets or less between CRLF line separation
            sequences [RFC-821]), but octets with decimal values greater than 127
            may be used. As with "7bit data" CR and LF octets only occur as part
            of CRLF line separation sequences and no NULs are allowed.

            > > 2. Non-unique object members
            > >
            > > RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
            > > selected rather than MUST?
            >
            > I assume this was to allow implementations to choose whether they keep
            > track of all seen names or not: this can add non-trivial overhead for
            > storage requirements, especially when processing JSON data streams.

            Good point.

            --
            With techies, I've generally found John Cowan
            If your arguments lose the first round http://www.ccil.org/~cowan
            Make it rhyme, make it scan cowan@...
            Then you generally can
            Make the same stupid point seem profound! --Jonathan Robie
          • Paul C. Bryan
            ... Sorry, 996 octets. I think. Per RFC 2045 §2.8, 8bit data is ...represented as relatively short lines with 998 octets or less between CRLF line separation
            Message 5 of 9 , Jan 1, 2012
            • 0 Attachment
              On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:

              > Hmmh? Where does 994 come from?

              Sorry, 996 octets. I think.

              Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
              lines with 998 octets or less between CRLF line separation sequences..."

              Given that a JSON string must be encapsulated in quotation marks (2
              octets), this seems to limit the number of octets that can be expressed
              in a UTF-8 encoded JSON string to 996 octets.

              Paul
            • Tatu Saloranta
              ... I am quite sure this was not the intent -- such limit would indeed render JSON pretty useless. -+ Tatu +-
              Message 6 of 9 , Jan 1, 2012
              • 0 Attachment
                On Sun, Jan 1, 2012 at 11:32 PM, Paul C. Bryan <paul.bryan@...> wrote:
                > On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:
                >
                >> Hmmh? Where does 994 come from?
                >
                > Sorry, 996 octets. I think.
                >
                > Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
                > lines with 998 octets or less between CRLF line separation sequences..."
                >
                > Given that a JSON string must be encapsulated in quotation marks (2
                > octets), this seems to limit the number of octets that can be expressed
                > in a UTF-8 encoded JSON string to 996 octets.

                I am quite sure this was not the intent -- such limit would indeed
                render JSON pretty useless.

                -+ Tatu +-
              • douglascrockford
                ... JSON does not impose such a limit. ... This was so that ECMAScript s eval function could act as a JSON parser. I think it should have been MUST.
                Message 7 of 9 , Jan 2, 2012
                • 0 Attachment
                  --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
                  >
                  > I'm hoping someone can help explain the rationale behind a couple of
                  > points in the JSON specification:
                  >
                  > 1. 8bit content-transfer-encoding for UTF-8
                  >
                  > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
                  > was 8bit selected rather than binary content-transfer-encoding? This
                  > limits the length of JSON strings to 994 octets.

                  JSON does not impose such a limit.

                  > 2. Non-unique object members
                  >
                  > RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
                  > selected rather than MUST?

                  This was so that ECMAScript's eval function could act as a JSON parser. I think it should have been MUST.
                • Paul C. Bryan
                  Thanks for the explanations. A follow-up question below... ... Why isn t such a limit implied by specifying 8bit in the IANA Recommendations? ... Paul
                  Message 8 of 9 , Jan 2, 2012
                  • 0 Attachment
                    Thanks for the explanations. A follow-up question below...

                    On Mon, 2012-01-02 at 13:12 +0000, douglascrockford wrote:

                    > --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
                    > >
                    > > I'm hoping someone can help explain the rationale behind a couple of
                    > > points in the JSON specification:
                    > >
                    > > 1. 8bit content-transfer-encoding for UTF-8
                    > >
                    > > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible."
                    > Why
                    > > was 8bit selected rather than binary content-transfer-encoding? This
                    > > limits the length of JSON strings to 994 octets.
                    >
                    > JSON does not impose such a limit.

                    Why isn't such a limit implied by specifying "8bit" in the IANA
                    Recommendations?

                    > > 2. Non-unique object members
                    > >
                    > > RFC 4627: "The names within an object SHOULD be unique." Why was
                    > SHOULD
                    > > selected rather than MUST?
                    >
                    > This was so that ECMAScript's eval function could act as a JSON
                    > parser. I think it should have been MUST.

                    Paul
                  • Paul C. Bryan
                    Bump. Is specifying 8bit in the IANA recommendations not normative? Paul ... [Non-text portions of this message have been removed]
                    Message 9 of 9 , Jan 4, 2012
                    • 0 Attachment
                      Bump. Is specifying "8bit" in the IANA recommendations not normative?

                      Paul

                      On Mon, 2012-01-02 at 08:52 -0800, Paul C. Bryan wrote:

                      >
                      >
                      > Thanks for the explanations. A follow-up question below...
                      >
                      > On Mon, 2012-01-02 at 13:12 +0000, douglascrockford wrote:
                      >
                      > > --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
                      > > >
                      > > > I'm hoping someone can help explain the rationale behind a couple
                      > of
                      > > > points in the JSON specification:
                      > > >
                      > > > 1. 8bit content-transfer-encoding for UTF-8
                      > > >
                      > > > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit
                      > compatible."
                      > > Why
                      > > > was 8bit selected rather than binary content-transfer-encoding?
                      > This
                      > > > limits the length of JSON strings to 994 octets.
                      > >
                      > > JSON does not impose such a limit.
                      >
                      > Why isn't such a limit implied by specifying "8bit" in the IANA
                      > Recommendations?
                      >
                      > > > 2. Non-unique object members
                      > > >
                      > > > RFC 4627: "The names within an object SHOULD be unique." Why was
                      > > SHOULD
                      > > > selected rather than MUST?
                      > >
                      > > This was so that ECMAScript's eval function could act as a JSON
                      > > parser. I think it should have been MUST.
                      >
                      > Paul
                      >
                      >
                      >
                      >
                      >



                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.