Re: [media-types] IETF Multiple Suffixes Interim?

["Martin J. Dürst" <[e-mail]>]

I'm sorry if this has come up (and for some good reason rejected) 
before, but I think media types are first and foremost descriptions of 
content formats, not instructions for processing. So it would be good if 
that would also apply to suffixes.

Also, my understanding is that in practice, machinery in an OS or 
application (such as a web browser or email MUA) does mappings to 
applications based on the whole of the media type. Using only a suffix 
(or more than one suffix) is the exception.

Therefore, we shouldn't say that e.g. application/did+ld+json is 
processed in a pipeline as
    application/json -> application/ld+json -> application/did+ld+json
but we should say that application/did+ld+json can also be processed as
+json or +ld+json, in particular if there is no more specific 
application available, or some more general processing is desirable. If 
an application that can handle application/did+ld+json is registered, 
then we really shouldn't care about what that application does 
internally. It may indeed call a generic JSON parser, or it may do some 
strange voodoo with regular expressions to extract the information it 
needs for its purposes; we shouldn't have to care.

As for cases such as image/xml, which have the problem that they don't 
exist: I think it's better to say that suffixes such as +xml and +gzip 
and so on are essentially independent of top level types, in that they 
speak about the "how" of encoding, whereas the top level types speak 
about the "what".

It's very fine to say, in the registration of +xml, that this can be 
treated in the same way as application/xml if no more specific 
application for the whole type/subtype combination (e.g. image/svg+xml) 
is available. But that's just a shortcut to saying "treat something with 
suffix "+xml" as generic XML if you cannot (or don't want to) do 
better". Although I can't currently come up with a +suffix that doesn't 
have at least one corresponding generic type/subtype (XML has two, 
there's also text/xml), there's no need to exclude such a possibility.

Regards,   Martin.

On 2023-05-18 00:02, Orie Steele wrote:
> 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