Subject: [art] new draft: "A Media Type Structured Syntax Suffix for JSON Text Sequences"

From: Erik Wilde <[email-masked]>
Date: Mon, 19 Sep 2016 19:32:40 -0400

hello.

On 2016-09-19 11:17, Erik Wilde wrote:
> hello mark
>> On Sep 19, 2016, at 10:46, Mark Baker <[email-masked]> wrote:
>> Are you intending to register "+json-seq" as a new suffix? If not,
>> then that name falls afoul of the naming requirements;
> you're of course right, but shouldn't there be a suffix, even if the spec itself didn't define one? should we register the suffix in the geojson seq spec? if not, i'd be willing to whip up a very short draft just registering that suffix. any thoughts about these options?

given that JSON text sequences possibly will become the foundation for 
other media types (this thread was triggered by the discussion of the 
application/geo+json-seq draft), i have created a short draft for 
registering +json-seq as a structured syntax suffix for media types:

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.)

i hope there is nothing (too) controversial in there, and have mostly 
looked at RFC 6839 for inspiration, in particular for the issue of how 
to define the fragment identifier semantics.

any feedback is greatly appreciated! cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Erik Wilde <[email-masked]>
Date: Fri, 23 Sep 2016 09:48:11 +0200

hello all.

> 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.

---

From: Sean Leonard <[email-masked]>
Date: Sun, 25 Sep 2016 19:27:03 -0700

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 <[email-masked]> wrote:
> 
> hello all.
> 
> 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:
> 
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Mark Baker <[email-masked]>
Date: Mon, 26 Sep 2016 14:06:06 -0230

Erik - I don't see any issue with the registration per se, but I do
wonder about the value. Is there anybody else using this approach? And
why did the line get drawn at JSON-object-per-line rather than, say,
the more generic data-per-line approach which already has a history
(text/csv or text/uri-list, off the top of my head).

---

From: Erik Wilde <[email-masked]>
Date: Mon, 26 Sep 2016 18:42:00 +0200

hello mark.

> (text/csv or text/uri-list, off the top of my head).

it sounds to me as if you have an issue with RFC 7464 itself. for our 
use of it, we simply have a JSON-based format to start with (GeoJSON, 
RFC 7946), and then using RFC 7464 is very straightforward if you're 
interested in representing sequences of whatever you're representing in 
JSON. if that's not what you want to do then other formats may be 
alternatives, but for us RFC 7464 is a good match. all we're looking for 
is a way to mint a media type that can use a structured syntax suffix 
for RFC 7464.

cheers,

dret.

---

From: Mark Baker <[email-masked]>
Date: Mon, 26 Sep 2016 14:50:26 -0230

Ah, I hadn't forgotten all about RFC 7464. Yes, registering the suffix
in that light makes ample sense. Thanks, Erik.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 27 Sep 2016 17:57:43 +0200

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.

> +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…

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.

> ...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.

thanks and cheers,

dret.

---

From: Sean Leonard <[email-masked]>
Date: Tue, 27 Sep 2016 11:56:15 -0700

On 9/27/2016 8:57 AM, Erik Wilde wrote:
>> +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.
>
> 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.
>
> 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.
>
> 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

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Sep 2016 08:48:12 -0700 (PDT)

> top-level media types is not clear. Can anyone explain how this is

What rules do there need to be? Structured suffixes provide a means - one that
is recommended but not required - of indicating that a given type employs some
underlying syntax.

A given type is either, say, XML based, or it isn't. If it is it should have an
name ending in +xml, if isn't it can't.

That's the only rule. The rules for whether not not a given type belongs
under application, video, text, model or whatever are essentially orthogonal to
this.

> interactions with message, although they are a bit esoteric.)

As RFC 6838 says, the text top-level type is indended for material that is
"principally textual in form". This tends to conflict with the type employing a
structured syntax, since most structured syntaxes don't result in material
that's "principally textual". But nothing prevents there from being a
structured syntax designed for use by text types, although AFAIK we don't have
one yet.

				Ned