From mcr+ietf@sandelman.ca Thu Apr 4 13:21:48 2024 Return-Path: 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 To: media-types@ietf.org CC: anima@ietf.org In-Reply-To: References: <2E20FEDE-C766-43EE-A6E2-1FB63E79CF0B@mnot.net> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2024 20:21:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable original, entire thread, for ANIMA people: https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZCl= Is/ 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,COS= E}) 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 decisi= on 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 assi= gn 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 thin= gs 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 wou= ld 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 t= he mnot> proven use case for media type suffixes. Suffixes should not be mnot> used to hint semantics; only syntax. We should have strong langua= ge 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 +j= wt 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 no= t) But, for many formats they only appear in a signed form in the wild, so may= be this just doesn't matter. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmYPC9UWHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZXsYCACheoQtWGI3AsFpfQhREzPlJi3R Cdr5XL6LJyKmiQziLwTwKuCgGnr657XlrJG3FsJiWL4y2YYGOA2NCTld9YcB6ttx MVqUWpXJ1gPQzIoWouRvXUm099TGj0FBQBCk99egPBwwx6j9i7OqfEqemP0aBtZj nhZLqhIwr1nlfw+lAxl+XAR4CExSTCaw6GZHvuf2nraSAlFhuYvyWYuG83POetGA l7Q76CxGHNslWroMunU6PfpCz5NN789H4CzwyVmSs5gPhIucwfFSMWcxgzQnY3JC soSIQaKSBBrWIuBPLEubh3EJ9/OjDB5lEfQUNPW83B+8dicVYd2AVn+G71ZC =jJRd -----END PGP SIGNATURE----- --=-=-=--