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

Re: [json] A couple of JSON questions

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.