IETF Logo Mail Archive

Structured data over TCP?

Patrik Fältström <patrik@frobbit.se> Wed, 27 May 2009 05:44 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152103A6E85 for <apps-discuss@core3.amsl.com>; Tue, 26 May 2009 22:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.06
X-Spam-Level:
X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZIXWsmP4V+J for <apps-discuss@core3.amsl.com>; Tue, 26 May 2009 22:44:35 -0700 (PDT)
Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 8D1583A6B30 for <apps-discuss@ietf.org>; Tue, 26 May 2009 22:44:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 9FCBC5468BB7 for <apps-discuss@ietf.org>; Wed, 27 May 2009 07:46:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JsBiCYxuJDh for <apps-discuss@ietf.org>; Wed, 27 May 2009 07:46:15 +0200 (CEST)
Received: from [192.168.1.114] (64-103-25-233.cisco.com [64.103.25.233]) by srv01.frobbit.se (Postfix) with ESMTP id F36465468BB0 for <apps-discuss@ietf.org>; Wed, 27 May 2009 07:46:14 +0200 (CEST)
Message-Id: <FCEED61A-9D4E-4964-827F-6666BA888256@frobbit.se>
From: Patrik Fältström <patrik@frobbit.se>
To: apps-discuss@ietf.org
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-5-955485352"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Structured data over TCP?
Date: Wed, 27 May 2009 07:46:13 +0200
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 05:44:37 -0000

It was many years ago popular to use line breaks as delimiters in  
data, and on each line have essentially attribute/value pairs.

Then we got XML that today seems to be what people want to use  
(because there are libraries, and tons of programmers that can (not?)  
implement XML parsers). We also have "content-length prefixed" XML  
data, that make things sort of simpler.

Sort of in parallell, we have xmlrpc, that to some degree solve  
slightly different problems.

Personally, I have lately looked at JSON, and after serializing data  
and then use Netstrings (http://cr.yp.to/proto/netstrings.txt), I must  
say I really like it.

For those that do not know Netstrings, here is an example from the spec:

> For example, the string "hello world!" is encoded as <31 32 3a 68 65  
> 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The  
> empty string is encoded as "0:,".

Implementing is very simple, and you know how many bytes to read. An  
example JSON-netstring thing can look like (for a 3-object array with  
a hash as the third object, where the hash as one entry):

29:[1, "info", {"msg": "Hello"}],

In the DNS provisioning world we have come up with epp (RFC 3730) that  
has a binding to TCP (RFC 3734). The binding is a prefixed-based XML  
blob that is passed over the wire:

> EPP Data Unit Format (one tick mark represents one bit position):
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                           Total Length                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         EPP XML Instance                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now, we need some more protocols here (between DNS operator and the  
registrar), and the question is whether the same mechanism is  
recommended, or whether one should use something else?


Do Apps Area have any general feeling about this?

    Patrik

v2.23.0 | Report a Bug | By Email