Re: [media-types] [Geojson] [art] renamed draft: "A Media Type Structured Syntax Suffix for JSON Text Sequences"
Sean Leonard <dev+ietf@seantek.com> Tue, 27 September 2016 18:55 UTC
Return-Path: <dev+ietf@seantek.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4755512B321 for <media-types@ietfa.amsl.com>; Tue, 27 Sep 2016 11:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=unavailable 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 rfdOa26yKYnq for <media-types@ietfa.amsl.com>; Tue, 27 Sep 2016 11:55:11 -0700 (PDT)
Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3168512B04A for <media-types@ietf.org>; Tue, 27 Sep 2016 11:54:56 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id u8RIsZGt030918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <media-types@iana.org>; Tue, 27 Sep 2016 18:54:55 GMT
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D8EA2509B6; Tue, 27 Sep 2016 14:54:33 -0400 (EDT)
To: Erik Wilde <erik.wilde@dret.net>
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> <5CE4E75D-2185-4A81-B00F-6BD6717FF916@seantek.com> <ad96246d-1e6a-5ee9-b9f0-3d174739cc2a@dret.net>
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <31afbaba-7097-d2a4-4d26-c0d873aeae83@seantek.com>
Date: Tue, 27 Sep 2016 11:56:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <ad96246d-1e6a-5ee9-b9f0-3d174739cc2a@dret.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Delayed for 40:27:29 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Tue, 27 Sep 2016 18:54:55 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/DGz2VzwitBqUn8hsOv6ORVTVWzY>
Cc: Mark Baker <distobj@acm.org>, art@ietf.org, geojson@ietf.org, media-types@iana.org, Sean Gillies <sean.gillies@gmail.com>
Subject: Re: [media-types] [Geojson] [art] renamed draft: "A Media Type Structured Syntax Suffix for JSON Text Sequences"
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 18:55:12 -0000
On 9/27/2016 8:57 AM, Erik Wilde wrote: > hello sean. > > thanks for your feedback, and i think both of your comments are > interesting. but i also think that they would be misplaced in this > particular draft. > > On 2016-09-26 04:27, Sean Leonard wrote: >> 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. > > RFC 7464 does not say anything about text/json-seq (it only registers > the application/json-seq media type) and thus it would be > inappropriate to make the suffix be more encompassing than the > underlying media type. The rules for how structured syntax suffixes get applied to diverse top-level media types is not clear. Can anyone explain how this is supposed to work? Regardless, no text/* media type registrations use structured syntax suffixes at this time. I do not wish to belabor the point, so will concede it based on lack of use. (However, +xml and others are used by other TLMT, such as in image, message, and model. And +xml does have interactions with message, although they are a bit esoteric.) > >> <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. > > again, RFC 7464 does not say anything here. i think your idea with > providing simple indexing into the sequence is a really nice one, but > i think the right place to define this would be the media type, not > the suffix. > > if there is a next revision of RFC 7464, then it probably should > register the suffix and maybe it also should adopt your idea of an > index fragment identification scheme. but to me, that's something that > would need to be done for the media type. That's fine. If it's a good idea, then the proposed draft can update the application/json-seq media type registration, along with defining the +json-seq suffix. Carry on... Regards, Sean
- [media-types] Review request for application/geo+… Sean Gillies
- Re: [media-types] Review request for application/… Mark Baker
- Re: [media-types] Review request for application/… Erik Wilde
- [media-types] new draft: "A Media Type Structured… Erik Wilde
- [media-types] renamed draft: "A Media Type Struct… Erik Wilde
- Re: [media-types] [art] renamed draft: "A Media T… Sean Leonard
- Re: [media-types] renamed draft: "A Media Type St… Mark Baker
- Re: [media-types] renamed draft: "A Media Type St… Erik Wilde
- Re: [media-types] renamed draft: "A Media Type St… Mark Baker
- Re: [media-types] [art] renamed draft: "A Media T… Erik Wilde
- Re: [media-types] [Geojson] [art] renamed draft: … Sean Leonard
- Re: [media-types] [art] [Geojson] renamed draft: … Ned Freed
- [media-types] moving forward with Erik Wilde
- Re: [media-types] [art] moving forward with Dale R. Worley
- Re: [media-types] [art] moving forward with Mark Baker