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

Re: [json] A couple of JSON questions

Expand Messages
  • Tatu Saloranta
    ... I am quite sure this was not the intent -- such limit would indeed render JSON pretty useless. -+ Tatu +-
    Message 1 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 2 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 3 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 4 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.