A Discussion of Multiple Suffixes

Alexey Melnikov and I had a chat about
https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes

I am sharing a summary of our discussion for the benefit of the list,
obviously this was just a discussion, and the media types working group
will need to decide if or how to address any of these topics.

Regarding media type parameters, there should be no automatic inheritance.

There can be parameters that come from the top level, the subtype, the
first structured suffix, or the last structured suffix.

An interesting parameter to consider would be "profile" which is common.

There should be commentary on media type parameters, especially
regarding cases where:

application/ld+json and application/json might both have chosen to register
a common parameter name, such as "charset" or "profile".

+ld+json seems to be fine.

+jwt is confusing, since it's ambiguous which part, the header, payload, or
signature will be passed along.

The validation rules here, are also problematic, in that they don't
directly address this case:

https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.5.1

We think the ambiguity here could be resolved, for JWT or CWT, the payload
is the natural part that is relevant, and this aligns with the current
intended use case within W3C.

For example, W3C specs current request registration of:

typ: application/vc+ld+json+sd-jwt
cty: application/vc+ld+json

Where decoding the payload produces application/vc+ld+json.

We should comment on this explicitly and warn implementers planning to use
multiple suffixes with:

+jwt
+cwt
+sd-jwt
+jose
+cose

 ... or future similar structured suffixes...

To do their best to conform to this behavior, or explain why they deviated
clearly, in their registration request.

An alternative recommendation might be to flatten the suffixes, when
pairing with envelope content types, for example:

application/vc-ld-json+sd-jwt

This would also reduce unnecessary registrations, and simplify the guidance
to designated experts regarding subtypes
with multiple structured suffixes that are each envelope formats (for
example, +cwt  / +jwt)

When flattening is not an option, we recommend registering all suffixes, to
ensure consistency, safety checks, and to be explicit over implicit.

For application/vc+ld+json+jwt and application/vc+ld+json+sd-jwt this would
mean registering:

for application/vc:

- +ld

- +ld+json

- +ld+json+jwt
- +json+jwt

- +ld+json+sd-jwt
- +json+sd-jwt

Some of these registrations could be made with a warning, saying, do not
use at this time.

On the section regarding adjudication of registrations on the same subtype,
for the case where:

application/vc+ld+json is registered and the change controller is W3C.

https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-suffixes-06#section-2.3

We feel that the designated expert should have the ability to overrule the
change controller, but that their decision should be appealable to IESG.

We should reach out to IESG regarding this proposal in case they have
comments.

We think the common case will be that the designated expert will consult
the change controller, and agree with their position,
in the case the designated expert feels there is some unreasonable position
being taken by the change controller,
they should be allowed to overrule the change controller, and that decision
should be appealable.
In the case of W3C, this would likely involve working with W3C Liaisons and
the IAB as well.

In the case of other organizations, it might be helpful to be able to
consult the IESG on the best course of action.

In the case that the designated expert agrees with the change controller,
the registrant should seek a non conflicting subtype,
for example vc2, or a flattened subtype, for example vc-ld-json

We discussed content formats, and we don't think there are any issues with
that registry, and the approach taken by multiple suffixes.

In summary, I think the main item remaining is the guidance on "skipping
registrations" or "flattening" or "registering and recommending against
use".

This was also the last comment on the topic during the session at IETF 118.

My personal preference would be to recommend the following to the group,
regarding intermediate suffixes:

1. flatten whenever possible.
2. register and recommend against using.
3. skip registration and deploy without considering interpretation of
intermediate suffixes.

Alexey, please correct anything I miscommunicated.

Regards,

OS

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>