Re: [media-types] Thoughts on suffixes, single and multiple

Manu Sporny <msporny@digitalbazaar.com> Mon, 08 April 2024 15:53 UTC

Return-Path: <msporny@digitalbazaar.com>
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 6D09CC15154A for <media-types@ietfa.amsl.com>; Mon, 8 Apr 2024 08:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digitalbazaar.com
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 ePf5OUicI2yu for <media-types@ietfa.amsl.com>; Mon, 8 Apr 2024 08:53:38 -0700 (PDT)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 74305C15107A for <media-types@ietf.org>; Mon, 8 Apr 2024 08:53:38 -0700 (PDT)
Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-4daa1be011dso1301493e0c.0 for <media-types@ietf.org>; Mon, 08 Apr 2024 08:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitalbazaar.com; s=google; t=1712591617; x=1713196417; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bXAGRC7S6gFj42wYfpS2iBqQI3EiCV0zthRMNk0hoJ4=; b=m8Zf7tovNGq9mIOToXwINUJ4uYcSxKtISrQKE//Jr+BhvWkytkUSznVPjdykKN/Sh1 efScJRgJDNQtTPGzeM8TSW3cx7wG7w5SG047bTl/pJjAMd3NeRF14Q12HP5YGlKgdEJn dk78kPCah5LEDLsDiil6hN0LyjJXDswmjkAvKLrbxLgWV1lW8ZP9KIWJZatYZbKGSBUP AKyHnbCZI+pZUlgHomEhrpQPF4N978BC1Nkn6PJRl3N/sruEx80BUbfVZ/eakKwfF/uo vX/Bu5XWwHiFpZ9t7uozoh5EKMCaOxG3vVldJutSoai+dO9+FwsZNEBKAFheoAt4WLkH EI+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712591617; x=1713196417; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bXAGRC7S6gFj42wYfpS2iBqQI3EiCV0zthRMNk0hoJ4=; b=cKhS/FZbVBGHKgCMlT/7Aofo2C/5G3UCa/u9QhB9LrB1U5a61gntmM0wHTwWb+hMzJ oDvnckqPnmQzh6u97MFVIvE032jDtdtGlMtyUzvTYlDv9a5ooeD068l8iy0b1z3LmseK Jbiu/rxZbbeIrDnI6IbSzl176wGmhp/93vNaa0cQYOjszrRYEbfJasE+g65EY0AWrzIm r79QJmvXq2uY2zfKcda0a83xBuO2Otfo+uRoDHs43Grd5xPDMoW/VB4DUIVmLlYIM6bo DrBVQE8vLMxZ1nOS10So7uInTgZWL8kkq+u+h4GUaRRSiQpDVCc4WBeU05xcJFWpenNB vYxQ==
X-Gm-Message-State: AOJu0YzynkQejQgNWRE3lke2HE5bx2HCqHm1KVvAHLd57i+kpvcVkB+j Eil4lM6xPiFKG8yivctgScJrtl0XH88jPZIRWdUUOv2BOy1++oLCMZdb9ccXRV8nBM4oWZkvTj4 nyxOwAZzu+lkIjhmmq7/m5jdNKZHCeo/XbkFpCOIYlqnUpCl8a7g=
X-Google-Smtp-Source: AGHT+IGAMvfIgY8VDMEWOvoOYMa4xDrUSp+K5GDXWnO/WIle3/R1Dmyd/PvqsIUU/TOUbYs6OngTL2MN6X+AtmUJc/E=
X-Received: by 2002:a1f:fe83:0:b0:4d4:42c6:b08d with SMTP id l125-20020a1ffe83000000b004d442c6b08dmr4829153vki.5.1712591616946; Mon, 08 Apr 2024 08:53:36 -0700 (PDT)
MIME-Version: 1.0
References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> <1c404c4d-437c-464a-b414-4e0d39c1d8ea@alvestrand.no> <E83E80FF-5810-4A53-85D8-E5095F9C1C1C@openlinksw.com> <837B503B-B9F9-40F7-8078-7D1BCD66D076@mnot.net> <CAMBN2CTMk8GDeUT0ObHcW=xxaRMzd75PrtWwLa_YB-4JoF_FxA@mail.gmail.com> <F58ABF0E-56F3-462B-AA00-192A75AFEE41@mnot.net> <CAMBN2CSbxjX8GCi2E1gTwnaWNLvbNc7SWd=mStWDnj0eeZpgpQ@mail.gmail.com> <C2B4B44B-1282-4818-9B49-01E6B67593E0@mnot.net> <CAMBN2CT0qaYFqp1gMUZsBxepxZ=nzpKbAW+cAhHyHdASZHupgA@mail.gmail.com> <25A01CF2-7529-4E8B-9B80-116D4C6FB4E9@mnot.net>
In-Reply-To: <25A01CF2-7529-4E8B-9B80-116D4C6FB4E9@mnot.net>
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 08 Apr 2024 11:53:00 -0400
Message-ID: <CAMBN2CTDoM1aRPZ9ura9Uy0-e3qukMwahBqhvyPyAPxZW4+nVQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF Media Types <media-types@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/vC8SZRxzHbASsTvN-cf6VyDnHe0>
Subject: Re: [media-types] Thoughts on suffixes, single and multiple
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: Mon, 08 Apr 2024 15:53:42 -0000

On Sun, Apr 7, 2024 at 10:15 PM Mark Nottingham <mnot@mnot.net> wrote:
> No - what I'm saying is that whatever we put into the multiple suffixes draft, it should be extremely generic, so that it can accommodate all of these different uses.

Got it, some thoughts on that concept below...

> - No requirement to register combinations of suffixes; only each individual suffix is required to be registered

We had floated a variation of that proposal two IETFs ago and it did
not achieve consensus from the Designated Experts. That is what led to
the "MUST register all suffixes to the right" language in the multiple
suffixes specification today.

While it does answer the question for "+xml+gzip", it doesn't quite
cover the question regarding "+ld+json", does it (there is no such
thing as a +ld suffix)?

> - No default constraints on how suffixes are composed / how they relate to each other / what the semantics of their ordering or position means

Yes, that seems workable as long as we say that the specification that
registers the suffix must specify what the semantics of the ordering
and position means. Maybe we add this as a field that's required in
the registration request to ensure that multiple suffix usage has
clear guidelines for how they are interpreted.

> Does that make sense? I could see an argument for still requiring combinations of suffixes to be registered, but am hoping that if we do a good job on describing the individual suffix constraints, that won't be necessary.

Yes, it makes sense. As I mentioned earlier, there are multiple valid
interpretations that make logical sense, we just need to find a path
(or paths) that everyone can agree to. Whether or not combinations
(such as +ld+json) need to be registered will be important to decide,
but can be somewhat orthogonal to some of the other "simpler" multiple
suffix usages such as "+xml+gzip".

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/