Re: [Anima] Fwd: [media-types] Thoughts on suffixes, single and multiple
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 04 April 2024 20:21 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F1C1519AB; Thu, 4 Apr 2024 13:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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_DNSWL_MED=-2.3, 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=sandelman.ca
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 auixMwaNu4qx; Thu, 4 Apr 2024 13:21:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (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 EFF91C1519A6; Thu, 4 Apr 2024 13:21:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D96CD3898D; Thu, 4 Apr 2024 16:21:43 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QObbDZSNIEJQ; Thu, 4 Apr 2024 16:21:42 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EC1633898C; Thu, 4 Apr 2024 16:21:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1712262101; bh=M8XOE8HP9GKyi77bhPo6GlgSgralIpJM3msFQNi28N0=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=u/ThDwOtu0/OgqGTu9674wVojshLvhUSt5RF8lZtd3IobDewz78rw0cWUfsx2utPi f29W92dI1nlXRExffrZkDOz0mxOTtXoXmFfPZ0lWZ6PYUhtjCDOfrSrx46snE07U6K uyM5+K7w6Y7kjAC9WsNR8M49wqB0nkd24C7pC0EvTZjHix9ywr8EyblDadxgbRuv5N pZCWvsdhIdMhRvs2JBIiHOaHJGBB3k+ZnSB6SCPzJT+8I2DMf8ihyjei/teD7OjGl/ T7EOx4ATIGjf+bcxs6hr5/X66hnenCRgJGP1h9l6UD+ssmJEew1o2brTZAM3vtIvQh Kql9nCLQ1CefQ==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E4C8B111; Thu, 4 Apr 2024 16:21:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: media-types@ietf.org
CC: anima@ietf.org
In-Reply-To: <CAN8C-_JWg8MOOwxo-yxASO5K8nkS9ADOvOJoAGEV2Mxxae6YAQ@mail.gmail.com>
References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> <CAN8C-_JWg8MOOwxo-yxASO5K8nkS9ADOvOJoAGEV2Mxxae6YAQ@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 04 Apr 2024 16:21:41 -0400
Message-ID: <1810.1712262101@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wTTdtRSCpYG8JfOlVHgT_4McvhQ>
Subject: Re: [Anima] Fwd: [media-types] Thoughts on suffixes, single and multiple
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 20:21:48 -0000
original, entire thread, for ANIMA people: https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/ mnot> After the meeting in Brisbane, some of us went aside to continue to mnot> the multiple suffixes discussion. There, we quickly came to the mnot> conclusion that we should deprecate the concept of suffixes in mnot> media subtypes -- i.e., they would still be syntactically allowed, mnot> but would have no meaning or registry. Martin Thomson and I took an mnot> action to write something down about this. uhm. okay. We in ANIMA have been struggling because we have an artifact, a voucher (YANG defined in RFC8366, being revised/extended in 8366bis), which can be in two major formats: JSON and CBOR (in theory, XML too), but can be signed by three formats (CMS, JWS, COSE). That gives us three major variations today: 1) application/voucher-cms+json aka voucher+json+cms? 2) application/voucher+cose or? voucher+cbor+cose? 3) application/voucher-jwt+json aka voucher+json+jwt? (because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X {JWS,COSE}) We didn't know if we should resort to multiple suffixes or not, and the lack of apparent progress on this has been a pain. So, thank you for the decision as it takes the options off the table, I guess, even if I'm bit surprised by it. mnot> The widespread use of +xml and +json in particular made me more mnot> cautious about deprecating suffixes altogether -- especially since mnot> we still sort-of believe that they are indeed used by (or at least mnot> potentially useful to) things like editors to hint syntactic mnot> conventions. Also, +gzip makes it pretty clear you can maybe do something with it, if you just know how to decompress. mnot> 1) Disallow more than one "+" sign in media subtypes, as floated at mnot> the meeting. This would put a fair amount of pressure on the mnot> registry's ability to reflect reality, depending on how widely mnot> deployed some things get (although we could grandfather some types mnot> in to ease the pressure here). I suggest keeping +gzip and +xml. mnot> 2) Syntactically allow suffixes before the last one, but not assign mnot> them any meaning or register them; e.g., application/foo+bar+xml mnot> would be an XML format, but who knows what bar is; effectively, mnot> it's just part of "foo+bar". This would allow people to define mnot> suffix-like things, but wouldn't give them any recognition or mnot> coordination -- potentially leading to the need to formalise things mnot> more down the road, just as we did in the first round of suffixes. It doesn't seem any different than foo-bar+xml to me. mnot> 3) Consider multiple suffixes, when they occur, to be unrelated mnot> hints as to the syntax of the format -- i.e., there is no mnot> processing model, there is no ordering (although a registrant would mnot> have to choose an order; registrations with different orderings mnot> should be refused). Effectively, suffixes would just be a 'bag of mnot> hints' about the format being used. Not that useful, but I could live with it. mnot> ### Defining What Suffixes Are For (no matter how many there are) mnot> After the discussion in Brisbane, I strongly believe that suffixes mnot> should ONLY be for hinting about the syntax or format convention in mnot> use, as an aid eg to editors, syntax highlighters, etc. This is the mnot> proven use case for media type suffixes. Suffixes should not be mnot> used to hint semantics; only syntax. We should have strong language mnot> about the dangers of using suffixes to hint particular kinds of mnot> processing; cf the previous discussion on the 'polyglot problem' mnot> and the potential security issues around performing processing mnot> based upon suffixes. Well, it also helps forensics and dissectors; but I accept that in essence, those are just specialized kinds of "editors" mnot> The suffix registration process should be designed to assure that mnot> only such suffixes are registered. mnot> Note that in this view, "+ld" is very likely unregistrable. ! mnot> ### Cleaning Up Existing Suffixes mnot> +gzip and +zstd are problematic; the former should be disallowed mnot> for new registrations, and the latter should be removed or mnot> obsoleted in the registry. Likewise, I am highly suspicious of +jwt mnot> and +cose. +zip _is_ a format convention, so I suppose it's OK? So, +jwt and +cose says, "this is a signed object, and if you look in the payload slot, you might find something you might know how to decode" (or not) But, for many formats they only appear in a signed form in the wild, so maybe this just doesn't matter. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- Re: [Anima] [media-types] Fwd: Thoughts on suffix… Michael Jones
- Re: [Anima] Fwd: [media-types] Thoughts on suffix… Michael Richardson
- Re: [Anima] [media-types] Thoughts on suffixes, s… Mark Nottingham
- Re: [Anima] [media-types] Fwd: Thoughts on suffix… Michael Richardson
- Re: [Anima] [media-types] Thoughts on suffixes, s… Michael Richardson
- Re: [Anima] [media-types] Thoughts on suffixes, s… Esko Dijk
- Re: [Anima] [media-types] Fwd: Thoughts on suffix… S Moonesamy