Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard

Tim Bray <tbray@textuality.com> Wed, 12 March 2014 03:49 UTC

Return-Path: <tbray@textuality.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 22DCD1A03A7 for <json@ietfa.amsl.com>; Tue, 11 Mar 2014 20:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 9DNbRJrGJ2d9 for <json@ietfa.amsl.com>; Tue, 11 Mar 2014 20:49:11 -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 060D81A07C8 for <json@ietf.org>; Tue, 11 Mar 2014 20:49:10 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id la4so6207625vcb.3 for <json@ietf.org>; Tue, 11 Mar 2014 20:49:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jj8A1MIvdNLXDI+RD/u5FX3O0DhjD1mN/s/xUnt5ljw=; b=D4mHwXVwpL6MVXWucW4jBYw10Z3JRKWWL9jfShLlvlrZwWeVOI1q9jJv70rvsfWUD9 tGl6qrl4SR0eh5qrjGPjl56//LgWV5jhgrYNpFAuId/tAHxoNrg8uEJQWq89FGD1Tzh5 Ot4M7NYGSBUxSDo1H4hQ1Nsv1w/2O84uHhzJIX6X8t/3qRr/26Ls2R+UJfzKxhmyzAaj dkp9Xo8ff1k9WSO3lzn9juSXStweR0MH2yh/sBoeuHd42zA0oytwwJfosiFgIWcBmnrw p7b6YD2bWbniWQ6uAK/z/hz1Sb9kx1Rp/v+Ief0CiJPMO0tnlqeI69RTyoxwNA0HtmN1 sBlQ==
X-Gm-Message-State: ALoCoQlC4WctnlIpk7gKmLByo3TFfjCG362zW9doABQt88kfUV3hVFNp2//pg1K3loYEITwP0/4u
MIME-Version: 1.0
X-Received: by 10.52.34.137 with SMTP id z9mr8513084vdi.12.1394596144910; Tue, 11 Mar 2014 20:49:04 -0700 (PDT)
Received: by 10.220.98.73 with HTTP; Tue, 11 Mar 2014 20:49:04 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <CAK3OfOjZ4nDQ7OBpbF-0D9dK9+08MhXiRe9VxKvWTXwBosd-RA@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 11 Mar 2014 20:49:04 -0700
Message-ID: <CAHBU6isGGLCVkc53sPoOVPktQvR4ATYBWpxSmG2TRsMSQ605gg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary=20cf30780f62d2d82604f460b769
Archived-At: http://mailarchive.ietf.org/arch/msg/json/P3DuV8tYk8D-3FpHOfd5e9UbWdk
Cc: Nico Williams <nico@cryptonector.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard
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: Wed, 12 Mar 2014 03:49:13 -0000

Yeah, the options are:

1. zero or more whitespace characters
2. 1 or more whitespace characters
3. A specific required set of whitespace characters, for example \s*\n\s*
or just \n


On Tue, Mar 11, 2014 at 8:12 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:

> > > I agree that a newline is the best separator for creators to include,
> > and always including it is best.
> > >
> > > Some (most?) receivers will be more lenient and accept values
> > separated by any whitespace, or with no separator (for objects, arrays,
> > and/or strings). Perhaps it is best for interop to say receivers MUST
> > be this lenient.
>
> > Good point.  Sequence parsers MUST be able to handle newline text
> > separators and SHOULD be able to handle other whitespace, as well as
> > no separator in the unambiguous cases.  Sequence encoders SHOULD use a
> > newline separator and MAY use other whitespace (with some guidance as
> > to why newline is best); no need to mention when the separator may be
> > omitted.
>
> You don't quite guarantee interop with "encoders MAY use other whitespace"
> and "parsers SHOULD be able to handle other whitespace".
>
> The spec needs to say: either "encoders MUST use a newline separator"; or
> "decoders MUST be able to handle any whitespace (including none in the
> unambiguous cases)".
>
> --
> James Manger
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>