Re: [media-types] Media subtypes containing "+"

Mark Nottingham <mnot@mnot.net> Tue, 02 February 2021 23:46 UTC

Return-Path: <mnot@mnot.net>
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 D1CE53A0D64 for <media-types@ietfa.amsl.com>; Tue, 2 Feb 2021 15:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=MQVe2MMD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o4gmk2JI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8CYQS3NElWo for <media-types@ietfa.amsl.com>; Tue, 2 Feb 2021 15:46:40 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED5A3A0D5D for <media-types@ietf.org>; Tue, 2 Feb 2021 15:46:40 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E45785C02BD; Tue, 2 Feb 2021 18:46:38 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 02 Feb 2021 18:46:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=v TWeIM7Qmgz7lhGNwrpGIOFJhSsClQ3vWx/DX7IS+Zk=; b=MQVe2MMD2HOaOLoeE mry8yW4p4Ke/6c5zMzWmka8fJ4qDUcfPzHbtEwUJ62/kSd2b+u0SUVi2TeCnpPpO gPOCGSjoxSaD0UUwIzx4kmz1r185ejy1FUN6UDD4bT75KRB9UOXyJAP5RoDg5Egj JQwFoGeWkaBQDa8lfewMXMEY6Oc8up2sL/ykXK1pomD1u6cUKIkwcOBhdvfZD7Gk M6W5DTwL1gBLRsUzPhwOK1U+y+A1iAFXxpNom5QnlhWYD/YUqqFpoWfHP2tWbmp2 b9932m1xwjpqiG56YnteDK7K8ZpyOzgIH2Gzu5nzAO4nsH2oXMW3W60zXIzQK84r tIb+g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=vTWeIM7Qmgz7lhGNwrpGIOFJhSsClQ3vWx/DX7IS+ Zk=; b=o4gmk2JI8CJBZ60TeW2rfhUKo0ErxupZvUtZ3HDUOl4PYTTDD+kVydKSX NnC7zWE0muVPuXQLBneoLhdHypwfR+rFFFlQwxTMdRuVTdBrN2ixrIXt0fLrQrG4 WkuZUJ7e2MPIR4JRRDwT+rwCv4h75xW4vTU6xNiLnFUCXFDmHndFLfZm98Uws/yi bOw/8emk4tixdsqVon8fdhUQk2jVTQzw5Z8Aq9Ao/22LCJkxdzctnIDIpmacsj3E jk+HUs+Ey6iG0mke/FNp354K+yEygT747JevoINgYwNmI8oQn1oiltcZ9yOB/gzr 5PoipxEAWT6T0Z0Dv1xomgywo+w/A==
X-ME-Sender: <xms:W-QZYCb6P8jfd8vUsXMgr-uXv3EiYj5BlrlpGWqd96wtqrHLXmjWyg> <xme:W-QZYFbC-ZTJv4ZXcYl70h8Dn47yYHjb4DyHZ0axKbuXqT8OnOEvPqL0AKfPqeqVq aaavwKve-3nfP1Qlg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedugddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepteefleffjeffhfehheeffeegudelgfeujedukeeigedvgeehffefvdehffeileek necuffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhe dunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhn ohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:W-QZYM9amYX2HKu6sLH6rNm_ltQb-4BitaI1rIyE-_BL2esPTd8zwA> <xmx:W-QZYEoQmSdhGfFqmfb6G0NfuW0GSH-g_pLRioZDO5fJVA4ngRZmmA> <xmx:W-QZYNovSs2vTP7Tfbj_LrdgNIi4j4pdUoJQr-tIO62ilG9BbaLM3Q> <xmx:XuQZYEWe6Lo_NTx13ogfV_WOmvSB4chaj-YXws6WyIAc5bUiC9AeZQ>
Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id BDE841080064; Tue, 2 Feb 2021 18:46:34 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <DC0EB4DA-D45B-423C-8D37-04E854176D9B@tzi.org>
Date: Wed, 03 Feb 2021 10:46:32 +1100
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, media-types@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8727219-D3AA-411D-AC8A-45BF93E1AFA8@mnot.net>
References: <CAL0qLwZGum3X3SGH8EQGdH+cZuOjSsEyQad1Tk3Q=HyuthXvvQ@mail.gmail.com> <6E14C19A-AD5B-491F-90A0-218553CAD235@mnot.net> <DC0EB4DA-D45B-423C-8D37-04E854176D9B@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/xc3hscOOxK5QI0n2mu0rhd-RID0>
Subject: Re: [media-types] Media subtypes containing "+"
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 02 Feb 2021 23:46:43 -0000


> On 3 Feb 2021, at 8:49 am, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 2020-07-03, at 03:19, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> The argument for media type suffixes, as I understood it, was that it gave a way for generic parsers to somehow process the document based upon the more general conventions, even if they didn't know about the exact format in hand.
>> 
>> That always struck me as a fairly weak motivation;
> 
> Adding my .2 base points:
> 
> The argument that the argument for suffixes is weak is itself a little weak :-)

I suspect it's turtles all the way down, Carsten - see below.

> (1) If you don’t care about the suffixes, just use the whole of the subtype and ignore the plus signs.  Solved.
> 
> (2) If you do care about them, the hierarchy proposed does make a lot of sense.
> 
> (And, if you don’t care from a machine processing point of view, the scheme still generates a useful way to remember/decode media type names.)

Your argument seems to boil down to "it doesn't bother anyone, why not?"

If you can't articulate the actual utility brought by the proposed feature, alarm bells are ringing. While what you say above may be true, adding new features to the architecture is not zero cost; people have to take on the cognitive load to understand the new feature, and given that it's poorly articulated, it's likely that will be non-trivial. 

Furthermore, implementations will need to know how to handle ordering of suffixes; is application/foo+ld+xml the same as application/foo+xml+ld, or different? If someone registers one of them, can I still register the other? Are there different forms of comparison, as there is for URIs? Does the chain of suffixes imply a processing model? Can someone who defines a suffix use it to imply a processing model?

And so on.

> I’m a little disappointed that this is taking us so long; JSON-LD is a format that is relevant for IoT-oriented specifications, and I would prefer if we don’t throw around unneeded process obstacles for using it for new media types.


Process obstacles are an annoying problem when they're in my way too.

Cheers,

--
Mark Nottingham   https://www.mnot.net/