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

Harald Alvestrand <harald@alvestrand.no> Wed, 20 March 2024 03:45 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EFFC151084 for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnwviINX2gY9 for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:45:12 -0700 (PDT)
Received: from smtp.alvestrand.no (smtp.alvestrand.no [65.21.189.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E19C14F5F1 for <media-types@ietf.org>; Tue, 19 Mar 2024 20:45:12 -0700 (PDT)
Received: from [31.133.131.210] (dhcp-83d2.meeting.ietf.org [31.133.131.210]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 227674E77C for <media-types@ietf.org>; Wed, 20 Mar 2024 04:45:09 +0100 (CET)
Message-ID: <7e741a4c-3d3e-41d4-8f11-377265950c91@alvestrand.no>
Date: Wed, 20 Mar 2024 13:45:07 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: media-types@ietf.org
References: <CAMBN2CQbfAW2pmmxZZgbBOTUzY+TdYe5S8ve5cX_R30PXZJ=+w@mail.gmail.com> <CAN8C-_JGre8jtAenDCrV7JSwJWPhf9K7K6HiC4_cX6E+YLru+Q@mail.gmail.com> <CAMBN2CQy6GzJiZvU2fkvrDSLGpk=K-HUxv1Gwd8cDxEhjojtHw@mail.gmail.com> <PH0PR02MB7430A03285ECC49CADF584FAB7232@PH0PR02MB7430.namprd02.prod.outlook.com> <68739467-3819-4D6C-81F4-17AFE3D0A3E9@tzi.org> <CAMBN2CQVKmc9=hmm+rK2wK4aNVJfR_YDMEYUQJadzUiZCVTCkA@mail.gmail.com> <39D0F672-53F7-4AE6-8FCE-B0CA18355E05@tzi.org> <CAN8C-_K5EvziAE6h4AMnLtmFsfdNxi=ar16pzWZzfaj9cGBAtA@mail.gmail.com> <CAMBN2CS9+7Q20-Wyi__RmHe1L74nHTytSfenjBFrtiFcvDQb2Q@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <CAMBN2CS9+7Q20-Wyi__RmHe1L74nHTytSfenjBFrtiFcvDQb2Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/MlgVZDc9CRkYED3-qcfqUsFRBlI>
Subject: Re: [media-types] Last tracker issue for mediaman-suffixes
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 03:45:18 -0000

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.


On 3/8/24 09:06, Manu Sporny wrote:
> On Thu, Mar 7, 2024 at 1:38 PM Orie Steele <orie@transmute.industries> 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
>