Are all structured suffixes required to be registered?

[msporny]

This issue was raised at IETF 118, during the MEDIAMAN WG meeting:

The current specification does not require that all structured suffixes are registered before a media type can be registered:

https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-06.html

For example, for the media type:

application/vc+ld+json, the expectation is that +ld+json and +json suffixes will be registered (allowing the media type to be properly registered).

However, there is also an application/vc+ld+json+jwt media type registration under consideration, and there does not seem to be a desire to register the +ld+json+jwt or the +json+jwt structured suffixes (but there is a desire to register application/vc+ld+json+jwt).

The question to the group is: Do we require that all structured suffixes are required to be registered before a media type can be registered? Or is it okay if some structured suffixes are not registered when a media type is registered?

[msporny]

We have a few options here:

1. Do not require that all structured suffixes need to be registered when a media type is registered. Processors that do partial processing skip structured suffixes that are not registered.
2. Require that all structured suffixes are registered when a media type that uses them is registered.
3. Leave the decision wrt. whether or not all structured suffixes need to be registered up to the Designated Expert, where the registrant needs to have a /really good reason/ for why the other structured suffixes don't need to be registered.

[TallTed]

Option (2) is the way to go (though simultaneous registration should be allowed, possibly being flagged for more stringent review).

Much like application/jpg.zip should not exist and an application/zip may be processed to deliver an application/jpg, application/vc+ld+json+jwt should not exist, and an application/jwt document may be processed to deliver an application/vc+ld+json document.

major/w+x+y+z is a subtype of major/x+y+z which is a subtype of major/y+z which is a subtype of major/z. In other words, a document of type major/w+x+y+z may be processed by a handler of major/w+x+y+z or major/x+y+z or major/y+z or major/z; a document of type major/x+y+z may be processed by a handler of major/x+y+z or major/y+z or major/z; a document of type major/y+z may be processed by a handler of major/y+z or major/z; a document of type major/z may be processed by a handler of major/z.

We seem to be on a cycle of understanding the above and then forgetting it. Perhaps I should be more involved with the IETF rounds. What do I need to do to legitimately join these sessions (and what dates/times should I add to my calendar)?

[msporny]

major/w+x+y+z is a subtype of major/x+y+z which is a subtype of major/y+z which is a subtype of major/z.

I'm having a hard time understanding the above, which is rare for me to not understand what you're saying, @TallTed. The part I'm most concerned about is whether or not you disagree w/ what is in the spec today (new version posted yesterday):

https://ietf-wg-mediaman.github.io/suffixes/

Perhaps I should be more involved with the IETF rounds. What do I need to do to legitimately join these sessions (and what dates/times should I add to my calendar)?

The mailing list and this issue tracker are the only venues to provide input between in-person IETF meetings. There are no regular meetings/calls.

You can attend the in-person IETF meetings virtually by dialing in three times per year (it costs ~$175 to attend).

[TallTed]

I will try to get to the current full text later today.

Possibly a quickly written response directly to part of your last post here will help.

For example, for the media type:

application/vc+ld+json, the expectation is that +ld+json and +json suffixes will be registered (allowing the media type to be properly registered).

Yes. And the reason for that expectation is that any application/vc+ld+json document is also an application/ld+json document, and any application/ld+json document is also an application/json document.

A processor which can handle an application/json document, can also handle an application/vc+ld+json document or an application/ld+json document, because the latter two are also JSON. However, a processor which relies on and expects the special features of an application/vc+ld+json document cannot be expected to handle any arbitrary application/ld+json or application/json document. Also, that application/json document processor is not expected to handle any special features of either application/vc+ld+json or application/ld+json — because it really only understands JSON, not JSON-LD, nor VCs presented as JSON-LD.

However, there is also an application/vc+ld+json+jwt media type registration under consideration, and there does not seem to be a desire to register the +ld+json+jwt or the +json+jwt structured suffixes (but there is a desire to register application/vc+ld+json+jwt).

It should be noted that the registration request for application/vc+ld+json+jwt has been abandoned, replaced by the similarly problematic application/vc+ld+json+sd-jwt.

IMNSHO, both the application/vc+ld+json+jwt and application/vc+ld+json+sd-jwt registration requests should be summarily rejected, because the media type of such a document is really just application/jwt or application/sd-jwt; the content of that application/jwt or application/sd-jwt document might be an application/vc+ld+json document.

An application/sd-jwt is akin to an application/zip, and should not expose the media type of the document(s) it contains in its own media type. The media types of the contained documents should only be revealed/discovered when such contained document(s) are extracted or sniffed. Just as there is no application/jpg+zip nor application/txt+zip nor application/jpg+zip, there should be no application/vc+ld+json+sd-jwt (nor application/ld+json+sd-jwt nor application/json+sd-jwt).

[vasilakisfil]

Personally I think all structured suffixes should be required to be registered before being able to register a Media Type that uses them. My main concern is that registering ld+json+jwt after registered Media Types using it, might create conflicting issues to one or more existing registered Media Types using ld+json+jwt. And of course, in no case do we want an already registered Media Type using ld+json+jwt as a structured suffix to affect the specification of the actual ld+json+jwt, to avoid the aforementioned conflicts.

Another reason is that I don't think the missing structured suffixes are that many. json+jwt sounds common, same goes with ld+json+jwt. Sounds like we should start looking registering them, it will be a lengthy process for sure these structured suffixes seem quite generic and common.

Finally, I think registering a Media Type should be a lengthy and a conservative process. Anyone can specify a Media Type offline, but registering it and making it official, we should really be careful. Maybe an unpopular opinion but requiring structured suffixes, that a potential to-be-registered Media Type uses, to be already registered will slow down things a bit which I think is a good thing for something that is defined once and lives forever.

[msporny]

Thanks for the feedback @vasilakisfil -- it sounds like your position is what a number of others want as well.

[msporny]

@TallTed wrote:

I will try to get to the current full text later today.

@TallTed, we are very behind schedule in getting your suggested text via a PR or issue or anything at this point. I don't want to leave things until the last second and submit things a week before the next IETF -- that has led to numerous delays. We need to close the window on changes to this specification and get it to the next step and in order to do that, we need to propose a final version to the MEDIAMAN WG.