Re: [Json] Moving the +json suffix registration to 4627bis

Tim Bray <> Wed, 16 October 2013 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EE2811E8289 for <>; Wed, 16 Oct 2013 10:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TTITvm8Usadk for <>; Wed, 16 Oct 2013 10:28:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 85A2411E822D for <>; Wed, 16 Oct 2013 10:28:41 -0700 (PDT)
Received: by with SMTP id ie18so542361vcb.33 for <>; Wed, 16 Oct 2013 10:28:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x5bf23jsCE3QQSsqOd3JflqWWE2XwA/MwS/xZnN4HjE=; b=mhHb24xLWqA/uIN3EFbywBAh7XUm2aLEnbZXAWDYqZAwx1HHljC2KL43TMeUwZLpXP pzrF8S47P3Ad8OsdCkwHqL60HfrH41KgYulR/IABXoJFTtSiCVKbDD++8gsQ+T4HKk0R TdL0WA9y4/CbApvcf0g4MUiIdJbLDpFFnlNDXjg/HO0ZLwd3TIKsKpYt5X454mQgczOz 6T5leNhFP5eArp6DWVCKO7bb3YrcxDYc9bnT/JbtofJaSExdt04p5Mr3GrbvV7GyYShk ONZiqBdraK3XPCYvWbGj2EbCb9FGX1ZGvIq5H+f5Q1A2ahAFnSYxScEpt5KyIAcsWUfN Ocdg==
X-Gm-Message-State: ALoCoQkFrCQ6M3RO43E3PDHDEvigECKt2+SqwjsnZ/Qz7jDIrR5VtTIXD42Y2UH4vhl+4J3eeys/
MIME-Version: 1.0
X-Received: by with SMTP id ab5mr1093485vdc.31.1381944519754; Wed, 16 Oct 2013 10:28:39 -0700 (PDT)
Received: by with HTTP; Wed, 16 Oct 2013 10:28:39 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
Date: Wed, 16 Oct 2013 10:28:39 -0700
Message-ID: <>
From: Tim Bray <>
To: John Cowan <>
Content-Type: multipart/alternative; boundary=089e016339d833179f04e8df08bb
Cc: "" <>
Subject: Re: [Json] Moving the +json suffix registration to 4627bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2013 17:28:53 -0000

If we’re going to do this, could we add a “profile” parameter for a future
i-json or whatever?

On Wed, Oct 16, 2013 at 10:24 AM, John Cowan <> wrote:

> I know it's late in the process, but I think we should consider replacing
> the registration of the "+json" suffix in RFC 3869 with a fuller version
> in the next draft of 4627bis.  At the moment, there are already 13 media
> types matching 'application/*+json' registered at IANA.  Most of them
> in the vendor tree, but jrd+json, json-patch+json, and ld-json are are
> the IETF tree.  Having everything relevant to JSON media types in one
> place will be convenient.
> Here is proposed text, drawn from draft-ietf-appsawg-xml-mediatypes-03,
> the current proposal for RFC3023bis, and suitably adjusted:
>    This section supersedes the earlier registration of the "+json" suffix
>    [RFC6839].
>    This specification recommends the use of a naming convention (a
>    suffix of "+json") for identifying JSON-based media types, in line
>    with the recognition in [RFC6838] of structured syntax name suffixes.
>    This allows the use of generic JSON processors and technologies on
>    a wide variety of different JSON document types at a minimum cost,
>    using existing frameworks for media type registration.
>    When a new media type is introduced for an JSON-based format,
>    the name of the media type SHOULD end with "+json" unless generic
>    JSON processing is in some way inappropriate for documents of the
>    new type.  This convention will allow applications that can process
>    JSON generically to detect that the MIME entity is supposed to be an
>    JSON document, verify this assumption by invoking some JSON processor,
>    and then process the JSON document accordingly.  Applications may match
>    for types that represent JSON MIME entities by comparing the subtype
>    to the pattern '*/*+json'.  (However note that the "application/json"
>    media type defined in this specification also represents JSON MIME
>    entities while not conforming to the '*/*+json' pattern.)
>       NOTE: Section 5.3.2 of HTTPbis [HTTPbis] does not support Accept
>       headers of the form "Accept: */*+json" and so this header MUST
>       NOT be used in this way.
>    JSON generic processing is not always appropriate for JSON-based
>    media types.  For example, authors of some such media types may wish
>    that the types remain entirely opaque except to applications that are
>    specifically designed to deal with that media type.  By NOT following
>    the naming convention "+json", such media types can avoid JSON-generic
>    processing.  Since generic processing will be useful in many cases,
>    however -- including in some situations that are difficult to predict
>    ahead of time -- the "+json" convention is to be preferred unless
>    there is some particularly compelling reason not to.
>    The registration process for specific "+json" media types is described
>    in [RFC6838].  The registrar for the IETF tree will encourage new
>    JSON-based media type registrations in the IETF tree to follow this
>    guideline.  Registrars for other trees SHOULD follow this convention in
>    order to ensure maximum interoperability of their JSON-based documents.
>    Similarly, media subtypes that do not represent JSON MIME entities
>    MUST NOT be allowed to register with a "+json" suffix.
> Then the actual registration text can come from RFC 3869 with adjustments:
>    The media type structured syntax suffix registration form follows.
>    See [RFC6838] for definitions of each of the registration form
>    headings.
>    Name:  JavaScript Object Notation (JSON)
>    +suffix:  +json
>    References:  See Section 15
>    Encoding considerations:
>       As explained in Section 8.1, JSON is allowed to be represented
>       using UTF-8, UTF-16, or UTF-32.  When JSON is written in UTF-8,
>       JSON is 8bit compatible ([RFC2045]).  When JSON is written in
>       UTF-16 or UTF-32, JSON is binary ([RFC2045]).
>    Fragment identifier considerations:
>       The syntax and semantics of fragment identifiers specified for +json
>       SHOULD be as specified for "application/json".  (At publication of
>       this document, there is no fragment identification syntax defined
>       for "application/json".)
>       The syntax and semantics for fragment identifiers for a specific
>       "xxx/yyy+json" SHOULD be processed as follows:
>       For cases defined in +json, where the fragment identifier resolves
>       per the +json rules, then process as specified in +json.
>          For cases defined in +json, where the fragment identifier does
>          not resolve per the +json rules, then process as specified in
>          "xxx/yyy+json".
>          For cases not defined in +json, then process as specified in
>          "xxx/yyy+json".
>    Interoperability considerations:  n/a
>    Security considerations:  See Section 12
>    Contact:  JSON Working Group (
>    Author/Change controller:
>       The JSON Working Group.  IESG has change control over this
>       registration.
> Some coordination with APPSAWG will be needed to achieve this.
> --
> You know, you haven't stopped talking           John Cowan
> since I came here. You must have been 
> vaccinated with a phonograph needle.  
>         --Rufus T. Firefly
> _______________________________________________
> json mailing list