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

John Cowan <cowan@mercury.ccil.org> Wed, 16 October 2013 17:25 UTC

Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 06DC511E822D for <json@ietfa.amsl.com>; Wed, 16 Oct 2013 10:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q7TlXp+Bl+TZ for <json@ietfa.amsl.com>; Wed, 16 Oct 2013 10:25:33 -0700 (PDT)
Received: from earth.ccil.org (earth.ccil.org []) by ietfa.amsl.com (Postfix) with ESMTP id 0D26311E82B4 for <json@ietf.org>; Wed, 16 Oct 2013 10:24:54 -0700 (PDT)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VWUq4-0000Gw-Dz for json@ietf.org; Wed, 16 Oct 2013 13:24:52 -0400
Date: Wed, 16 Oct 2013 13:24:52 -0400
From: John Cowan <cowan@mercury.ccil.org>
To: json@ietf.org
Message-ID: <20131016172450.GB9701@mercury.ccil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Subject: [Json] Moving the +json suffix registration to 4627bis
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 17:25:53 -0000

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

   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

   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

         For cases not defined in +json, then process as specified in

   Interoperability considerations:  n/a

   Security considerations:  See Section 12

   Contact:  JSON Working Group (apps-discuss@ietf.org)

   Author/Change controller:

      The JSON Working Group.  IESG has change control over this

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           http://www.ccil.org/~cowan
vaccinated with a phonograph needle.            cowan@ccil.org
        --Rufus T. Firefly