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

[Sean Leonard <[e-mail]>]

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