[media-types] IETF Multiple Suffixes Interim?

[Orie Steele <[e-mail]>]

Given the verifiable credentials core data model requests the registration
of a new media type that uses 2 plus signs:

https://w3c.github.io/vc-data-model/#media-type

... and the multiple suffixes draft is still not an RFC:

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

Perhaps we might request an interim meeting from IETF to discuss changes to
the suffixes draft and ensure that W3C does not publish another TR with
unregistrable media types?

There are a few ideas floating around on how to complete the work, which I
will summarize but hopefully @Manu Sporny <[e-mail]> and @Ted
Thibodeau <[e-mail]> can add their thoughts.

1. Get consensus on processing rules.

Is there agreement that processing for the following examples looks like
this:

In general:

type/subtype+suffix1+suffix2 yields an attempted processing pipeline:

type/suffix2 -> type/suffix1 -> type/subtype

1.0 application/did+ld+json

application/json -> application/ld+json -> application/did+ld+json

1.1 image/svg+xml+gzip

image/gzip -> image/xml+gzip -> image/svg+xml+gzip

2. Are there more cases like image/xml that we should be considering?

Here is the list to review:

- https://www.rfc-editor.org/rfc/rfc6838
- https://www.iana.org/assignments/media-types/media-types.xhtml
-
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml

Are we ok saying "processing errors are expected, for cases like image/xml"
in the same way they would be expected for cases like:

image/svg+xml  profile="https://www.w3.org/ns/activitystreams"

- See for example: https://www.w3.org/TR/activitystreams-core/#media-type

   https://www.iana.org/assignments/media-types/application/ld+json

   Media types MAY elect to use one or more media type parameters, or
   some parameters may be automatically made available to the media type
   by virtue of being a subtype of a content type that defines a set of
   parameters applicable to any of its subtypes.  In either case, the
   names, values, and meanings of any parameters MUST be fully specified
   when a media type is registered in the standards tree, and SHOULD be
   specified as completely as possible when media types are registered
   in the vendor or personal trees.

- https://www.rfc-editor.org/rfc/rfc6838#section-4.3

It seems like a poor combination of plus signs will yield errors in very
similar ways that a poor choice of media type parameters will yield errors
...
... that is to say, the behavior will be unexpected, unless
explicitly specified when the media type is registered, as "profile" was
for ld+json.

This partially kicks the responsibility back to the entity doing the
registration to explain themselves,
instead of trying to reverse engineer an algorithm that will gain consensus
for all media types and suffixes registered to date.

In general the guidance should be: No, don't add multiple plus signs,
unless you have met a high bar, similar to how ld+json has paragraphs of
text explaining "profile".

For example, the W3 VCWG has resolved that vc+ld+json is compacted... so I
assume we do not need to use profile="http://www.w3.org/ns/json-ld#compacted
"

And yet our requested registration of "vc+ld+json" will need to spell this
out to avoid confusion... In a similar way, it will need to spell out
processing of multiple suffixes.

Regards,

OS


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>