Re: [media-types] Last tracker issue for mediaman-suffixes

[Orie Steele <[e-mail]>]

We is me/my company... We use DIDs and VCs, and their media types as
currently requested for registration (containing multiple +).

We also refers to folks we collaborate with on open source tests for these
technologies.

I've not seen any code that processes structured suffixes other than
browsers.

Browsers appear to basically use the suffix to decide to render instead of
download... I wonder if there is a relationship to the content disposition
header lurking in this.

OS

On Sun, Mar 24, 2024, 6:48 AM Martin J. Dürst <[e-mail]>
wrote:

> Hello Orie,
>
> Thanks for your explanations.
>
> On 2024-03-22 20:46, Orie Steele wrote:
> > Sorry I was not able to attend the session today.
> >
> > My original point was that people should register media types that they
> > plan to use, and that filling gaps for things nobody plans to use only
> for
> > the sake of consistency, doesn't make sense.
> >
> > In cases where we have used media types with multiple suffixes, we have
> > processed the entire media type as an opaque string.
> >
> > We don't have any code that string matches on suffixes.
>
> Can you say who "we" is in this case?
>
> Regards,    Martin.
>
> > OS
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 22, 2024, 5:37 PM Martin J. Dürst <[e-mail]>
> > wrote:
> >
> >> See below.
> >>
> >> [This may be somewhat outdated if the change of direction that was "in
> >> the air" in Brisbane gets confirmed on the mailing list.]
> >>
> >> On 2024-03-20 12:45, Harald Alvestrand wrote:
> >>> Registration entries are (relatively) cheap.
> >>>
> >>> There seems to be no significant value to not registering all legal
> >>> sequences of suffixes, when the avoidance of doubt can be achieved by
> >>> registering them.
> >>>
> >>> I think we currently have:
> >>>
> >>> - if application/foo+bar+baz is to be used, it must be registered.
> >>>
> >>> - +bar+baz must be registered
> >>>
> >>> - +baz must be registered
> >>>
> >>> - There is no registration required for application/foo or
> >>> application/foo+bar - these have no standard interpretation.
> >>
> >> For those such as Orie and Manu who would prefer having gaps in the
> >> registration chain, it might make sense to allow comments to
> >> registrations saying that suffix or combination of suffixes on their own
> >> doesn't make sense without further additions.
> >>
> >> Regards,   Martin.
> >>
> >>> On 3/8/24 09:06, Manu Sporny wrote:
> >>>> On Thu, Mar 7, 2024 at 1:38 PM Orie Steele <[e-mail]
> >
> >>>> wrote:
> >>>>> Otherwise, I think this issue has been addressed by previous
> >>>>> feedback, and there is no new information that warrants reopening it.
> >>>> Thank you for that summary, Orie. I agree with all of it.
> >>>>
> >>>> We tried it in the way Orie said he felt made sense (allow gaps in the
> >>>> suffixes registry, because some "intermediate suffixes", like
> >>>> "+json+jwt", probably won't be used). I (personally) prefer the same
> >>>> approach as Orie (to allow gaps in the suffixes registry).
> >>>>
> >>>> However, there were strong objections to that approach during the last
> >>>> meeting, so the only thing left to do is not allow gaps in the
> >>>> suffixes registry. So far, we haven't gotten the strength of
> >>>> objections to this "no gaps" approach that we did the other "allow
> >>>> gaps" approach; on the contrary, it seems like those that would prefer
> >>>> the "allow gaps" approach (Orie and myself) are willing to hold our
> >>>> noses and go forward with the "no gaps" approach.
> >>>>
> >>>> -- manu
> >>>>
> >>>
> >>> _______________________________________________
> >>> media-types mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/media-types
> >>
> >> _______________________________________________
> >> media-types mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/media-types
> >>
> >
>