[Json] terminology issues in RFC4627 JSON

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 12 March 2013 13:20 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
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 AA0C321F8A27 for <json@ietfa.amsl.com>; Tue, 12 Mar 2013 06:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KFnNc+izJuEw for <json@ietfa.amsl.com>; Tue, 12 Mar 2013 06:20:34 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com []) by ietfa.amsl.com (Postfix) with SMTP id C291421F8941 for <json@ietf.org>; Tue, 12 Mar 2013 06:20:27 -0700 (PDT)
Received: (qmail 14112 invoked by uid 0); 12 Mar 2013 13:19:58 -0000
Received: from unknown (HELO box514.bluehost.com) ( by cpoproxy3.bluehost.com with SMTP; 12 Mar 2013 13:19:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=uI/pcfrPhUc19MoOKYZxljlwnN3R0gejARGX+dSwAz8=; b=fgxf/Bhv3vxNhu9jApeZq4FByx/WdsM8g1VfMnj7dKLcdo8H+VfEXM3y7ZW7jQ1cAfqdKuVsWWvu2QRNBDjvbyJs3jRv7oycjbSVfZOvHA9aLgq4ILp3NmgcKVVaHTo/;
Received: from [] (port=55511) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1UFP7W-0000i9-1P for json@ietf.org; Tue, 12 Mar 2013 07:19:58 -0600
Message-ID: <513F2B7D.7070105@KingsMountain.com>
Date: Tue, 12 Mar 2013 06:19:57 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: json@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth authed with jeff.hodges+kingsmountain.com}
Subject: [Json] terminology issues in RFC4627 JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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: Tue, 12 Mar 2013 13:20:36 -0000

the message below tacitly identifies some issues with RFC4627's terminology, 
especially the term "JSON object" (I've trimmed the below to include only the 
json-specific portion) There's other issues with RFC4627's terminology to 
highlight, I can try to do that (in company with other folks' observations).



Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Fri, 21 Dec 2012 14:41:49 -0800
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: IETF oauth WG <oauth@ietf.org>

  > Aah – I now see that this is the real misunderstanding.  The “string
  > representing a JSON object” is not the base64url encoded form – it’s the
  > string representation that’s parseable into a JSON object.

Thanks, yes, this is a key aspect of my difficulty in parsing the spec.

Though my misunderstanding is subtlety different than you characterized it above.

Rather, it's that my understanding from RFC4627 is that a "JSON object" /is a
string/. Thus "string representing a JSON object" reads as "string representing
a string", which implied to me that the base64-encoded form was implied.

Since you don't mean to imply that, then yes, my suggestions re terminology were
somewhat incorrect (apologies).

However, I have these revised suggestions..

  > The reason for the syntactic construction “string representing a JSON object”
  > is that its string representation is distinct from the abstract JSON object
  > itself.

In RFC4627 there isn't an "abstract JSON object". It says..

     JavaScript Object Notation (JSON) is a text format for the
     serialization of structured data.
     A JSON text is a serialized object or array.

..from which I understand the latter to mean..

     A JSON text is a string-serialized abstract object or array.

Unfortunately, the overloaded term "JSON object" appears to be used in some
contexts to refer to programmatic artifacts (eg the "window.JSON" javascript
object implemented in browsers), and in other contexts (such as Section "8.
Examples" in RFC4627) to refer to JSON texts.

So I suggest defining the term "JSON text object", which from nosing around
seems to be also used in various other places/documents to refer to JSON texts
that match the "object" ABNF production in RFC4627 "Sec 2.2. Objects" (note that
by definition a JSON text is a "serialized object or array" [RFC4627])..

     JSON text object   A JSON text matching the "object" ABNF production
        in Section 2.2 of [RFC4627]. JSON text objects MUST UTF-8 encoded.

So instead of using the "string representing a JSON object" construct, the JW*
specs could use "JSON text object" to refer to the non-base64-encoded things.
Then you have..

     JWT Claims Set  A JSON text object containing a set of claims. ...

     JWT Header  A JSON text object describing the
        cryptographic operations applied to the JWT. ...