Re: [Json] I-JSON Topic #2: Top-Level

Phillip Hallam-Baker <ietf@hallambaker.com> Thu, 29 May 2014 17:45 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BF31A048A for <json@ietfa.amsl.com>; Thu, 29 May 2014 10:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98AkdH8Rloyl for <json@ietfa.amsl.com>; Thu, 29 May 2014 10:45:27 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A871A0450 for <json@ietf.org>; Thu, 29 May 2014 10:45:27 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id k48so799615wev.3 for <json@ietf.org>; Thu, 29 May 2014 10:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kjqDLa/hGHRoejXakac88Od590nJEiH3F4o7rTi8RnE=; b=g1xrbQH3L0WdLHyf4TU0mKwYuyjJsZ6v8KRaJ7fRoDuGCJ8nHMDCbb5iv6tQzRmFmb Yz88POzdM/UKcuxs+cA0i9CxP9g+12qdgnHnFTSJxMfGqoCu3TNqG0iW7Lj3ptDmRfER UWw4qbOe0BaMr3wtSYJGqD2GYsMIR9/cTdmCo4wvvoKKBwUIXKXMC/daDLsrYTs6bJMY YiB+nCHRRs6tAvzZ0ZGav/j6hv77ETEgmdfDMTZFLFL/Lfc6X5cH2Fjoa5EDD5rUzVVN IT/QdhJCfVoxFbRHqgBwvwYPoIKJzV8DFY4H/7bNI5zKA9rRwthM+zcQw8B5S0a/PpPJ e07g==
MIME-Version: 1.0
X-Received: by 10.180.38.107 with SMTP id f11mr39204959wik.59.1401385522195; Thu, 29 May 2014 10:45:22 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.194.79.136 with HTTP; Thu, 29 May 2014 10:45:22 -0700 (PDT)
In-Reply-To: <CAK3OfOh_Y3EXhnjr8Tz+7T4irNwsF9MztXEavNAd0ehmjY0Aow@mail.gmail.com>
References: <535EB119.4000908@cisco.com> <53861E05.9070208@cisco.com> <CAOXDeqrXet967enqiqK-Yx5PRT7dW+6t=TxN0=o+W8bWGSpg-w@mail.gmail.com> <CAK3OfOh_Y3EXhnjr8Tz+7T4irNwsF9MztXEavNAd0ehmjY0Aow@mail.gmail.com>
Date: Thu, 29 May 2014 13:45:22 -0400
X-Google-Sender-Auth: H_cR_0NnmQYSCRHfyZIw8xMk7lU
Message-ID: <CAMm+LwjN8nBjT2aH1wvw0fVpb5Scqp7Zog36wrPzuNqLR6ypVw@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/json/0ZL-KXCYnuVq3DiRHOFXB3pXBFI
Cc: JSON WG <json@ietf.org>, Matthew Morley <matt@mpcm.com>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] I-JSON Topic #2: Top-Level
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 29 May 2014 17:45:29 -0000

For protocols, I find the most convenient approach to be that the
message type be a tag and the message data be the corresponding value.

So if I have a protocol 'Fred' the HTTP binding is going to look like this:

GET /.well-known/Fred/operation1
...

{ "operation1" : {
   "tag1" : "value1" ...
   }}

While it is possible to rely on the command value in the URI, this
makes authentication a lot harder as the URI part of a request is
likely to be 'damaged' by proxies and the like. So I much prefer that
the command be a part of the JSON payload.

This enables the use of message layer authentication. It also makes
schemes of the form 'take command from Alice and lob it over to Carol
along with the authorization from Bob'. It also removes the assumption
that HTTP is the only legitimate binding for Web Services.


I can see cases where it would be useful to have a scheme where the
binding allows for an array of Web Service messages per binding
message rather than just one.

When I look at what my applications actually use from HTTP, it is basically:

1) The URL part
2) The session authentication header I defined as an extension
3) The Content-Length header for framing
4) Possibly the Content-Type in the future

Everything else is just noise that is needed to get through proxies,
firewalls and other nonsense that will never ever add value because we
know the message type and the data is not static so it can't be
cached.


Rather than looking at HTTP/2 as the next platform for Web Services,
it seems to me that we could do rather better with no headers at all
rather than some whacky compression scheme.