Re: [Geojson] [art] renamed draft: "A Media Type Structured Syntax Suffix for JSON Text Sequences"

Sean Leonard <dev+ietf@seantek.com> Mon, 26 September 2016 02:27 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B105E12B05B; Sun, 25 Sep 2016 19:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 FHA2yRizLdAH; Sun, 25 Sep 2016 19:27:06 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E62A1288B8; Sun, 25 Sep 2016 19:27:06 -0700 (PDT)
Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB79950A85; Sun, 25 Sep 2016 22:27:04 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <9125c52c-ce66-2bff-0674-d2ce737b0014@dret.net>
Date: Sun, 25 Sep 2016 19:27:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CE4E75D-2185-4A81-B00F-6BD6717FF916@seantek.com>
References: <CAOodmJoxSWEZxwQg6vK650HEy+nBx3iOdVQ+6hbjqaMQd_NBmA@mail.gmail.com> <CALcoZioNMW0SbvnGtm9PtYNPuGdQZ9oTBeBTB8j_+10hkPKf5A@mail.gmail.com> <8CE835AF-B228-4623-BDDE-D4B7DD006A6B@dret.net> <31406b75-16fe-3aed-fa16-ca4ad46f255d@dret.net> <9125c52c-ce66-2bff-0674-d2ce737b0014@dret.net>
To: Erik Wilde <erik.wilde@dret.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/n6F8ca9LI8J64YgsbLjxfVBaY9w>
Cc: Sean Gillies <sean.gillies@gmail.com>, Mark Baker <distobj@acm.org>, geojson@ietf.org, media-types@iana.org, art@ietf.org
Subject: Re: [Geojson] [art] renamed draft: "A Media Type Structured Syntax Suffix for JSON Text Sequences"
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF GeoJSON WG <geojson.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geojson>, <mailto:geojson-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geojson/>
List-Post: <mailto:geojson@ietf.org>
List-Help: <mailto:geojson-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geojson>, <mailto:geojson-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 02:27:09 -0000

I read the draft.

I support the registration of the +json-seq structured syntax suffix.

Two concerns:
<1>
+json-seq could be used with text/*+json-seq, not just application/*+json-seq. This should be addressed. The underlying application/json-seq (RFC 7464) only supports LF as a delimiter; this should be noted that it could be (and likely will be) CRLF when in text/* based media types. I think.

<2>
The fragment identifier is not fully specified, but that section says some stuff anyway. I think it should say something concrete, simply because the registration says that anything not in +json-seq is fair game for FOO/BAR+json-seq. Therefore, designers of FOO/BAR+json-seq ought to know what “holes” there are in +json-seq to play with. That includes application/geo+json+seq even though apparently there is no need for specific fragment identifiers at this time.

May I suggest: #n[:xxx], where n is the index of the JSON item, in decimal 0-9 ASCII. It could be 0-based or 1-based, to taste. If [:xxx] is present, the xxx is the fragment identifier according to application/json (which, apparently, has no fragment identifier syntax).

This means that anyone developing a specific media type structured as +json-seq has broad reign over any fragment identifier sequence that doesn’t start with 1-9 (or 0-9, as the case may be).

...or, you could say nothing about fragment identifiers. application/json-seq doesn’t say anything, and it’s getting along just fine.

Regards,

Sean

> On Sep 23, 2016, at 12:48 AM, Erik Wilde <erik.wilde@dret.net> wrote:
> 
> hello all.
> 
> On 2016-09-20 01:32, Erik Wilde wrote:
>> https://tools.ietf.org/html/draft-json-seq-suffix
>> (i just realized that i have used the wrong shortname and will fix this
>> asap to say "draft-wilde-json-seq-suffix", but for now please have a
>> look at the draft that is linked above.)
> 
> https://tools.ietf.org/html/draft-wilde-json-seq-suffix is the renamed draft (just submitted today) that updates the incorrectly named previous one. nothing else has changed but the name.
> 
> any feedback about this would be very welcome. we need this proposed new media type structured syntax suffix for ongoing work in the GeoJSON WG. i hope that we can move this draft very quickly and get the suffix registered, so that we can use it here:
> 
> https://tools.ietf.org/html/draft-ietf-geojson-text-sequence-02#section-5
> 
> thanks a lot and cheers,
> 
> dret.
> 
> -- 
> erik wilde | mailto:erik.wilde@dret.net |
>           | http://dret.net/netdret    |
>           | http://twitter.com/dret    |
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art