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

[Ned Freed <[e-mail]>]

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

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.

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

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