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

Re: [json] A couple of JSON questions

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