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

Re: A couple of JSON questions

Expand Messages
  • 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 1 of 9 , Jan 2, 2012
    View Source
    • 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 2 of 9 , Jan 2, 2012
      View Source
      • 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 3 of 9 , Jan 4, 2012
        View Source
        • 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.