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

[John Cowan <[e-mail]>]

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 ([e-mail])

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