Re: [Json] Scope: Wire format or runtime format?

Tim Bray <tbray@textuality.com> Sat, 15 June 2013 15:56 UTC

Return-Path: <tbray@textuality.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 867D521F9DDD for <json@ietfa.amsl.com>; Sat, 15 Jun 2013 08:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.663
X-Spam-Level:
X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Y9E7rnOhvViv for <json@ietfa.amsl.com>; Sat, 15 Jun 2013 08:56:16 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9586621F9DA5 for <json@ietf.org>; Sat, 15 Jun 2013 08:56:16 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id ib11so1142915vcb.3 for <json@ietf.org>; Sat, 15 Jun 2013 08:56:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uM6M4/+VHXE8l2JqN4EEVaQkV55aBj0IzDIyEqV+6Fo=; b=KUZ/suGVCzXzsdUzdFy1c36WV+xJ5B8G9/wElFFtxGTCMKbh6sbH7GY2cr4MjWyI4q XAM6paunEnxcNpN8f9/yUuQFDiwkSYR+PP2F4LXZHQyoMbWxSq6DvrKKZAgwNoLQhLfE 3fr2Ad0ssr8j9cDfrVxPRsBmQDPtW53pfzUmZd0rKqtX6VfBAVwxaPD4fBeBBXR+EwTi ADpfUEsaTZ7T3rYDNZJwbBoCopn6ClPhLRtm2b69v9l8OHhkgKAX3+yk3a3vRc8ob6VW 9eLq5hKX9XCYMMDN27BKHMocxuJw8QAdCZkOKpUFI/CmvEzhX68r9WnAzJ0iE6e1YHpw IvtQ==
MIME-Version: 1.0
X-Received: by 10.220.123.131 with SMTP id p3mr2410855vcr.69.1371311775325; Sat, 15 Jun 2013 08:56:15 -0700 (PDT)
Received: by 10.220.25.199 with HTTP; Sat, 15 Jun 2013 08:56:15 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org>
References: <6FC6B441-B74D-4B9F-B883-065C05890880@lindenbergsoftware.com> <0E2DB76C-3180-4D27-BD89-07C84A5D3599@vpnc.org>
Date: Sat, 15 Jun 2013 08:56:15 -0700
Message-ID: <CAHBU6ivpcDehKXCDT5C=CwtT8vduKqWuK423RvGTgTgBzVQ-GQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=089e013cbb223eaf5704df336748
X-Gm-Message-State: ALoCoQm2stfcjzO/s1w1JrzalClLrGZtB6rlbc7iMExt+OREi+8t9WmLSlYxkzkhQ2IwezxfugdV
Cc: Norbert Lindenberg <ietf@lindenbergsoftware.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Scope: Wire format or runtime format?
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: Sat, 15 Jun 2013 15:56:21 -0000

I think the IETF, at least at the Apps area, is in the business of network
protocols, so I see our job here primarily as getting the wire-format
aspects right.

 -T


On Sat, Jun 15, 2013 at 8:27 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On Jun 13, 2013, at 6:47 PM, Norbert Lindenberg <
> ietf@lindenbergsoftware.com> wrote:
>
> > In looking over older messages on this list, I found a message that made
> clear to me why we're having this endless discussion about Unicode
> surrogates - it's because we're not clear whether we're designing a wire
> format or a format that also for use at runtime:
> > http://www.ietf.org/mail-archive/web/json/current/msg00355.html
> >
> > Some people are coming from the runtime point of view, especially
> ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even
> non-text in strings. At least the ill-formed UTF-16 is legitimized by
> section 2.7 of the Unicode standard.
> >
> > Other people are coming from the wire protocol point of view, where
> clean formats are expected, in particular well-formed Unicode code unit
> sequences according to section 3.9 of the Unicode standard.
> >
> > So which one shall it be?
>
> Why not both? RFC 4627 deals with both; why should the update change to
> restrict that?
>
> --Paul Hoffman
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>