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

Tony Hansen <tony@att.com> Wed, 16 October 2013 19:10 UTC

Return-Path: <tony@att.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E377021F996A for <json@ietfa.amsl.com>; Wed, 16 Oct 2013 12:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.042
X-Spam-Level:
X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnSyWgB4QfiP for <json@ietfa.amsl.com>; Wed, 16 Oct 2013 12:10:50 -0700 (PDT)
Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2054E21F9C6A for <json@ietf.org>; Wed, 16 Oct 2013 12:10:48 -0700 (PDT)
Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id r9GJAkb8007530 for <json@ietf.org>; Wed, 16 Oct 2013 12:10:47 -0700
Received: from [135.91.110.247] (ds135-91-110-247.dhcps.ugn.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20131016191046gw100q0g6je> (Authid: tony); Wed, 16 Oct 2013 19:10:46 +0000
X-Originating-IP: [135.91.110.247]
Message-ID: <525EE4B5.4040107@att.com>
Date: Wed, 16 Oct 2013 15:10:45 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: json@ietf.org
References: <20131016172450.GB9701@mercury.ccil.org>
In-Reply-To: <20131016172450.GB9701@mercury.ccil.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [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 19:10:57 -0000

On 10/16/2013 1:24 PM, 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.

That's RFC 6839 above (and below), not RFC 3869.

Are there any actual changes in what you have below? I'm not convinced
that "having everything json in one place" is sufficient in and of
itself to warrant this.

> 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 (apps-discuss@ietf.org)
>
>    Author/Change controller:
>
>       The JSON Working Group.  IESG has change control over this
>       registration.

IFF this were done, then jsonbis would have to add Updates: 6839 to it.
Tim, that would be an additional attribute of the <rfc> tag, as in

    <rfc updates="6839"

> Some coordination with APPSAWG will be needed to achieve this.

I'm not sure what coordination you are envisioning that would be required.

    Tony Hansen