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

Manu Sporny <msporny@digitalbazaar.com> Sun, 07 April 2024 02:27 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 3947FC14F684 for <media-types@ietfa.amsl.com>; Sat, 6 Apr 2024 19:27:08 -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 CvTScC0TXCxL for <media-types@ietfa.amsl.com>; Sat, 6 Apr 2024 19:27:04 -0700 (PDT)
Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 55B24C14F683 for <media-types@ietf.org>; Sat, 6 Apr 2024 19:27:04 -0700 (PDT)
Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-4da955e6276so1403502e0c.1 for <media-types@ietf.org>; Sat, 06 Apr 2024 19:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitalbazaar.com; s=google; t=1712456823; x=1713061623; 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=GteGiTDs83EFWNkgwHAr8oxZyj/h7EMc1pskdpfmTPY=; b=fZAmoD9Il1rUv4uicYoDabzQgaAkgBk1hkVgNORmTFCfKKqN2qt9sTbWhbBcFlYQ5L GC+zP1hEEWkRys9LmYHE2n7rVe2Md8mipMPboYsRjF6x+oc5vrb36x1YYjvCmFq0G9qx pl+VwiThhxZhdH5RNkf9F6ENLLX9I8KCyDggsS+/mei57qLXecUEYgcKOhjW49HKs8BW gy3oYNz+fzWjtXHg0kuKnwgtY/yII53d2VTVpMvR28WWH7WSmyQgeValSuCBRed3phV2 DOBDCNKn490DIoa5JLIBLqsjieU55sV47xWbYnYSygnpoj+i9OCN3tGeEHlNGuo1kT08 O/8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712456823; x=1713061623; 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=GteGiTDs83EFWNkgwHAr8oxZyj/h7EMc1pskdpfmTPY=; b=ZeFyVA9Y+CHbhIaNUsIXSaITRrKVhQ9666StHxCcinLq6YyCSh1BucZsLuPoOrS1wX hytIb2sMHE79/0268ILDgndCyVqqSkEuKZ0NP4YBGMA+6TZw0EH4Yyu38tIx8W45Kemx akIQwy7VvrSXmtwOlPxuriEClcJ/KkAt0dBHASSetD/GM3ynMZkmvsD2K3dixJrnibpw YixS9Y9ZpDriQv8PGlEWDmvJGc5YYtWZ6Wc7LHU6iWydLkhWOhr3Z8MaOT1zqYcM+2HE UkZ6CKEv2woKD7Fh89XBxln9AvfRIVL/Y/86KAUtrBryMYVPLd9FU4UDM2EZjx79pUTH XRBg==
X-Gm-Message-State: AOJu0YwC0jHM9ll3CglSZwqejnZCBbzPsqouadw7DezbLCfVCm2c/G4E wl5k7M9j/NfrgQLEKvqSDCVFYUu2dsZwX0ecTyNRLI8o1q/sHg2UNWUt9193xlFpO2Dt21FDoTu 82cnc6fQQ7/HT0AuOFdAIZbLmO5KbQge8HKNGqxGjZTmrUciHB1w=
X-Google-Smtp-Source: AGHT+IGCnNJ1EYn7X0lSSPNk7Wk9iJSXpxXy4f+F3illjp+1P2TSP2XSFe6jcrpujmvFI2os23D9nGOyvBBwI/oyRTY=
X-Received: by 2002:a05:6122:4497:b0:4d3:34f4:7e99 with SMTP id cz23-20020a056122449700b004d334f47e99mr4104373vkb.0.1712456822776; Sat, 06 Apr 2024 19:27:02 -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>
In-Reply-To: <C2B4B44B-1282-4818-9B49-01E6B67593E0@mnot.net>
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 06 Apr 2024 22:26:26 -0400
Message-ID: <CAMBN2CT0qaYFqp1gMUZsBxepxZ=nzpKbAW+cAhHyHdASZHupgA@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/fNGAXO52wz0PYOilsy_IWMaBEcM>
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: Sun, 07 Apr 2024 02:27:08 -0000

On Sat, Apr 6, 2024 at 9:37 PM Mark Nottingham <mnot@mnot.net> wrote:
> > On 6 Apr 2024, at 23:24, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > * Syntax suffix pattern (+json, +xml)
> > * Container suffix pattern (+zip, +jwt)
> > * Multiple suffix pattern (vc+ld+json, did+ld+json)
> >
> > I can take an action to do that if folks are supportive.
>
> I think that's workable, and will try to help. I suspect we're going to end up with text something like:
>
> ...
>
> And so on.

Yep, all that sounds aligned with what I was thinking.

I'll also note that there are just two registrations of +gzip (that
didn't feel compelling, calling into question the value of +gzip as a
structured suffix), but 27 registrations of +zip (many of which seemed
to depend on it for its "container" properties primarily, and its
"compression" properties as a secondary effect).

> What we need to sort out now, I think, is what implications this has for the multiple suffixes draft. I tend to think that it supports the 'bag of tags' approach that I outlined earlier; that puts the fewest constraints on how suffixes are defined (so that they can define their own constraints, as per above).

I'm not fully following, but I think you're saying that "the suffix to
the left needs to say how it serializes itself to the the suffix to
the right"? Or you might be saying "if you peel the suffix to the
right off, everything to the left needs to be a valid media type"?

> We also probably want to explicitly list what things a suffix registration needs to document.

+1

Sounds like we have some concrete things to write, thank you for being
willing to help. I've raised issues to gather normative statements (or
just loose thoughts) for each pattern here:

Document "Syntax suffix" pattern:
https://github.com/ietf-wg-mediaman/suffixes/issues/26

Document "Compression suffix" pattern:
https://github.com/ietf-wg-mediaman/suffixes/issues/27

Document "Container suffix" pattern:
https://github.com/ietf-wg-mediaman/suffixes/issues/28

Document "Multiple suffix" pattern:
https://github.com/ietf-wg-mediaman/suffixes/issues/29

... we might be able to merge these down (or have to create new ones)
as we work our way through this process. I don't quite know where to
put your "bag of tags" suggestion yet, Mark. Feel free to add it to
the "Multiple suffix" pattern, or create a new issue to document the
"Bag of tags" pattern.

-- manu

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