From nobody Thu Jul 2 10:29:35 2020 Return-Path: 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 D5FFD3A0B12 for ; Thu, 2 Jul 2020 10:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IhqVYNrSHfgU for ; Thu, 2 Jul 2020 10:29:32 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163263A0B05 for ; Thu, 2 Jul 2020 10:29:29 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id q15so8966889uap.4 for ; Thu, 02 Jul 2020 10:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/oLvHPGKkeuT85banmcwNpMOSsQOiwVZlzzWTa6XSdQ=; b=T1Ja34GrzDoBhnS2rCEiSaoaVOGMSI6cMdscEJPKog1w8aAzZWTC6GKaupXqrF/h87 hrFspk3SK9Ro1sbVF2md738o4e+TIW9x671OQdULJncDD3uqMbJMG9sPfyboruIm0UMW nKkB196V4ekrc9NAJHxBIpH2U4hH92EincnrkKv1HWeP4KJJRhJQ6DWI7HgmmVMjvfsh L7VZOy7uS1v56MjzshYGwyj7VZ3Dsd3z3ySBW2rrxACVWBATuwdPqUWHfGnEYJIZWuod JQWsAr2tvp6s3PXbZz16jiSBwoOEizhyRoTcwEmdHGU1KZ+ovEW5fEOXXHpXsDYxTo3E EGag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/oLvHPGKkeuT85banmcwNpMOSsQOiwVZlzzWTa6XSdQ=; b=WE4tk3LLDliqpADRngwyaDAlqFvM3iPGLvGu/eTu9txgP+yeDKbAH+iktiHPaGZsrL Q/QmSEpc+RcxVUViU1os8eTkMVckSIXOsWS0S+bu35I34u1ArRefBYRAWHx5S4cwbo1A 5uUXI4Ygu7AulPkxXMc0l6VKlaBBpzyiGRD+gHkqC15fHB1dv8IaPoNYgPxJ6szB6to/ UISpRd3ohaI/YNm2qOFyUrTlXz0+EJhX2Wt5g9rFKTucHGgr4C0ZbWyOA4ZTxCsTeDwY NT8XSmFrGxejbl/2HRc/HcsfasEc2Ckkmy+ZcpFaLXlM5caYYVRUVN2p6cwlgBHl7flv pkfA== X-Gm-Message-State: AOAM530nacFZBj8JjgDr86oRe4Ue5oValWaGcKEab7q5d9NlJQ8nkpdC FMYxPMxAdEkx7jzPS6YSrJFQOj5FuXU3WfDYNZ0v9vQp X-Google-Smtp-Source: ABdhPJyIbh7PS8HHGQwZpD8mlnKWNbm1b+fgICAM+1h9T8y+UkWSuYaNTfkWTK8Wnk7Ij9SoufkAOIscSqUwRTVVICU= X-Received: by 2002:a9f:3806:: with SMTP id p6mr23746596uad.101.1593710968643; Thu, 02 Jul 2020 10:29:28 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Thu, 2 Jul 2020 10:29:17 -0700 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary="00000000000029230e05a978c09f" Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 17:29:34 -0000 --00000000000029230e05a978c09f Content-Type: text/plain; charset="UTF-8" Before I joined the IESG, we (the media type reviewers) processed a request for a media type that included a "+" character. Specifically, the request was to register "application/ld+json", and an implied media type suffix of "+ld+json". This was a revision to an existing media type. It included an implicit media type suffix registration, i.e., prose that said: "Other specifications MAY create further structured subtypes by using +ld+json as a suffix for a new base subtype, as in application/example+ld+json. Unless defined otherwise, such subtypes use the same fragment identifier behavior as application/ld+json." We had the applicant remove this text and instead suggest that they need to register "+ld+json" independently as a media type suffix, but that such a registration would likely be denied until such time as the community has had a chance to discuss its implications. The question is around nested suffixes like this. There's already a "+json", of course, but we should probably be clear someplace (maybe an "updates" document to 6838, maybe a revision) about how to process these if we're going to allow them. One might think that "+json+zstd", for example, would do the "obvious" thing, but that's not the kind of thing that should be left to interpretation. More generally, if I were to see application/foobar+a+b+c, should I be looking for one suffix called "+a+b+c", or three individually named suffixes, or other combinations, and in what order would they be applied, etc.? -MSK --00000000000029230e05a978c09f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Before I joined the IESG, we (the media type reviewer= s) processed a request for a media type that included a "+" chara= cter.=C2=A0 Specifically, the request was to register "application/ld+= json", and an implied media type suffix of "+ld+json".=C2=A0= This was a revision to an existing media type.

It= included an implicit media type suffix registration, i.e., prose that said= :

"Other specifications MAY create further structured subtypes = by using +ld+json as a suffix for a new bas= e subtype, as in application/example+ld+json. Unless defined otherwise, such subtypes = use the same fragment identifier behavior as appli= cation/ld+json."

<= div>We had the applicant remove this text and instead suggest that they nee= d to register "+ld+json" independently as a media type suffix, bu= t that such a registration would likely be denied until such time as the co= mmunity has had a chance to discuss its implications.

<= div>The question is around nested suffixes like this.=C2=A0 There's alr= eady a "+json", of course, but we should probably be clear somepl= ace (maybe an "updates" document to 6838, maybe a revision) about= how to process these if we're going to allow them.=C2=A0 One might thi= nk that "+json+zstd", for example, would do the "obvious&quo= t; thing, but that's not the kind of thing that should be left to inter= pretation.

More generally, if I were to see applic= ation/foobar+a+b+c, should I be looking for one suffix called "+a+b+c&= quot;, or three individually named suffixes, or other combinations, and in = what order would they be applied, etc.?

-MSK
--00000000000029230e05a978c09f-- From nobody Thu Jul 2 18:20:05 2020 Return-Path: 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 185C33A0A68 for ; Thu, 2 Jul 2020 18:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.001, RCVD_IN_MSPIKE_WL=0.001, 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=EW+Ixajo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pb2YuFrG 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 gN_T_ysC1Dcg for ; Thu, 2 Jul 2020 18:20:03 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDB73A0A7B for ; Thu, 2 Jul 2020 18:20:02 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 326925C016A; Thu, 2 Jul 2020 21:20:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 02 Jul 2020 21:20:02 -0400 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=fm3; bh=I dHlMGHvwPDa0/rDHzFZK2foqfepFGV99FvkYsmKHVo=; b=EW+IxajoHxJv4KBs8 jLvwzFC2crX9KfshuSaJfCy8FPfONfoxovC3VpemYzlv4g6tmGUtGhAdbu5RaLTH Q5e074Lne5tOVe6TY998Z75+Tq4A6jmvi7ZxtJU48Nn1W5bpQL9xN7rZ/qoDIdbh dh3P4lLMrTVVWbdmfm/xUiSkuvVR9CtshqBkpQENY/+P6k4GmtM9NwP8xWR5DW8Q TVrBJePOeIriqO7lYccyYfWqrmRZp5Q/tZYXBQjStuGdVJ0wJ0uL0vOXWIrk1S0A 1fH7Pc6VM6aNN122szejx3y9zxWNllni141YwrMlmBp3GtE2iyXvge/meiZHaHIu pHq/w== 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=fm3; bh=IdHlMGHvwPDa0/rDHzFZK2foqfepFGV99FvkYsmKH Vo=; b=Pb2YuFrGFQVRNxf8zS1BGIOnVXbkeJS89TEnMkyP8H1BufzWGs2Dqlg8o jOiNzE/TS2vnOp7QkCFM6kEl8+3EzXVK9uY10Sro3vuPiZe0YMARU4SSCYwoFmGa a87/LkG/UIF4dLvsl8uDkX3lOwWm0ZMJgkIrYFuR7f8/8+558mF92v3N6XOFhpkX 9g1Z4B4e8J59z8oau3cujVBmrGw+xlF7QIpo/ajhtP5XlSvSU1IrfdPxPEcDz+3T JQ5rV9LFEtxTnWEVoq7h82CNQE33Ro9c7DWczyx/YULrHYbhdOCCMDGWUKCMS0eY mAvA6oVyDA+NtnEgYz4n9NyekUXsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdehgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekuddvleejgeethfevkefhtdevkeelve ekfeegleduiefhudegvdeiuefftddthfenucffohhmrghinhepihgvthhfrdhorhhgpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 963B83280059; Thu, 2 Jul 2020 21:20:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Fri, 3 Jul 2020 11:19:57 +1000 Cc: media-types@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E14C19A-AD5B-491F-90A0-218553CAD235@mnot.net> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 01:20:05 -0000 Hi Murray, 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; for example, the most = one can do with XML is make sure it's well-formed, pretty-print it, and = if you're lucky, apply a stylesheet or check a schema if they're inline. = You can also colourise the elements and attributes, I suppose. For JSON, = there's even less (e.g., there aren't any rigorously defined hooks for = applying a stylesheet or attaching semantics). So I'm not excited about adding more complexity to names, or leading = people to believe that the structure actually does something useful. The = questions you ask are relevant, and are similar to other issues we've = faced (e.g., when people try to make field name prefixes meaningful). I = suspect people want to do this sort of thing mostly because it gives = their format convention more visibility (because it will appear in more = places) than any technical reason -- but I'm happy to be proven wrong = there. So I'm -0.5 on accommodating this; there may not be any great harm, but = specifying it consumes resources and makes things more complex. Getting some more data about how media type suffixes in general have = fared, as well as details about the use cases being promoted, might = change my mind. Cheers, > On 3 Jul 2020, at 3:29 am, Murray S. Kucherawy = wrote: >=20 > Before I joined the IESG, we (the media type reviewers) processed a = request for a media type that included a "+" character. Specifically, = the request was to register "application/ld+json", and an implied media = type suffix of "+ld+json". This was a revision to an existing media = type. >=20 > It included an implicit media type suffix registration, i.e., prose = that said: >=20 > "Other specifications MAY create further structured subtypes by using = +ld+json as a suffix for a new base subtype, as in = application/example+ld+json. Unless defined otherwise, such subtypes use = the same fragment identifier behavior as application/ld+json." >=20 > We had the applicant remove this text and instead suggest that they = need to register "+ld+json" independently as a media type suffix, but = that such a registration would likely be denied until such time as the = community has had a chance to discuss its implications. >=20 > The question is around nested suffixes like this. There's already a = "+json", of course, but we should probably be clear someplace (maybe an = "updates" document to 6838, maybe a revision) about how to process these = if we're going to allow them. One might think that "+json+zstd", for = example, would do the "obvious" thing, but that's not the kind of thing = that should be left to interpretation. >=20 > More generally, if I were to see application/foobar+a+b+c, should I be = looking for one suffix called "+a+b+c", or three individually named = suffixes, or other combinations, and in what order would they be = applied, etc.? >=20 > -MSK > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jul 2 22:41:06 2020 Return-Path: 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 66B0D3A0CEC for ; Thu, 2 Jul 2020 22:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 FCEh4nuEsY-b for ; Thu, 2 Jul 2020 22:41:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957573A0CE9 for ; Thu, 2 Jul 2020 22:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593754855; bh=2nmoWJsv4QbcpXymM6Oq0ExHkRwmIS9bVS7+6ih5jhI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=PEFv3fT0/qwtjTeVQFqgu+fPjYm9ufbgt/V+tknlj+SmCVOInLXxozgO3BZQbGP2G +S4ugdoqfdgrEPfGWOzBdMaP/AcIdWA9adcHIPhOUY8PBhLDUy8t12ms/YZ11KTekh 0s1AY+l3kwyV7fmfKlu1DxSLwuDPWrMG/PgZphc4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.156.104]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhD6W-1jCxwj2S4w-00eOoC; Fri, 03 Jul 2020 07:40:55 +0200 To: Mark Nottingham , "Murray S. Kucherawy" Cc: media-types@ietf.org References: <6E14C19A-AD5B-491F-90A0-218553CAD235@mnot.net> From: Julian Reschke Message-ID: <74172cad-6750-b33a-2bc9-41fbc0ae7b94@gmx.de> Date: Fri, 3 Jul 2020 07:40:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6E14C19A-AD5B-491F-90A0-218553CAD235@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:e+TES2U7qa9OgNAsR4+q6SJI3AibVgW6WEz4eG/zQzyz01dED8R eJqVVDzxLCiy1NDI2VRqaxe18fc6POat7DYaogFdUnKc1TGMl8ZaHpAhK+GlQ5G5Mcv0vGC I1IA67idDRQ8IE7Yq6XGz92W09stFBOvlh3dKLy+btSz+nmUq2TZrUJDl/riR/EEOSflZoP 7wcTJrH7QCxGjVXzgWjdw== X-UI-Out-Filterresults: notjunk:1;V03:K0:wId+/W6BKvg=:Q6UbT+uUOQSVCe3XrIFh1l Mz6Qe6qG4+MAl0jSF/x9/vz65aRskBz6hj0svGPvjP5Im6EZ6xopjPpuyXuJXen5ReGI+UoVw mUADWUY9ReTg/Xfk6bmY33gfpDhGbA8lKxvpl7fblKaUcBTvRd5DTPJl6d71TWEbkAADxMjbR xRRYqlPUehSsiHOzXuLpDYBLMl+PE6JXJhrkXgdDY10EjbZRA2Nw52+VkfPPgbfl8O7FBPACl EV3zFQRTIexNB78vUbSf/URhxW995pJvMQCDFIhDDbdfXBFHoHHqfyEgXhT5GgDYcPPLnqBMa OZdL4Hbe22OfAwnRYPRv8IZkImShnWRBsBut4ubGG0mvdkSp/M+rWA19VOj0f/JaMd1Vlsebq Ss545K3oSGHzbZx1MrYx9CKl+zlh1Mvd345DuQ2p1Eegl5L47x4engdeB4pipmlBCx4yYJdRG iZDLl040HQI/iVRCdrxFnGhEdJecotvuaSs0sX0OQU6fztVUEfk/qLQNHSAHqNnEiXblGE1bf 0gi03Jpi2cqvvhoOU6bc/AgTRXKToKqAXwrz5+isTGAzcilNrOUCScUVSoxh6yKDrpzRgqfbE jHvVuEqqOVa4uRJoKLyZjFMxO4Fp29KYaggioPdqUrlP3TMw3HFWrbuL165dE2BLAwNqp0jO9 3kqHLihTJVf8EkmQSiYQNtxe2VWaqRmkh3IGEYvw9xVEjdclx/es+Li3Rn2Xe1Bl0zTrHfMP9 jpEMy7Tsucoe5zC4DQZYsiRw5l6CzfZgF9wiSn4oiyUVwiqvDVDuX+aFWNYNx/ItOtKGyHhqi 431WC/hGKjbD08Iec2uLYphDkSIUMeeL4jb+SkIIGbnS3P2EyXmwtUvDLwIXj+PYarFZLXmMq CNYF9vGSgwTeeNG/6xFfdO58wjkWDwWklrGkHcI8xAsuKy1jAIQYvY927dbI8WUiD44/DlGPS G133fNPvbh/Y6JsXumEFA//fSW/jTAVWDCGwTFIBQxnkkPPVGlPDnhJ/uoelsEt9ICF/QiWDe uvOIijHaKmaLcGsOfCkvb8tu554UNr4Y85qkVQY/pCpjkGO6tNfXORx7+ZHlYonCEsiv+BKRc PC/tUL76JFjVhoQzQGZ2Eym2NQnhYaOP/swO11OeDj4lQ+N5cYzFdnJ0KwuDRpKFV+Nf95+fa /YGy6SoZ/n/oNCuaNei8CrN/3Ux7j6o3DuKFqvrVkuH/xAoyzFmT1E4DFIZ3T5Miy1I7nieJh uNRxTgwFJkaOQtiIg Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 05:41:04 -0000 On 03.07.2020 03:19, Mark Nottingham wrote: > Hi Murray, > > The argument for media type suffixes, as I understood it, was that it ga= ve a way for generic parsers to somehow process the document based upon th= e more general conventions, even if they didn't know about the exact forma= t in hand. > > That always struck me as a fairly weak motivation; for example, the most= one can do with XML is make sure it's well-formed, pretty-print it, and i= f you're lucky, apply a stylesheet or check a schema if they're inline. Yo= u can also colourise the elements and attributes, I suppose. For JSON, the= re's even less (e.g., there aren't any rigorously defined hooks for applyi= ng a stylesheet or attaching semantics). > ... ...or . Best regards, Julian From nobody Wed Jul 8 10:15:42 2020 Return-Path: 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 564223A0F77 for ; Wed, 8 Jul 2020 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EPtpj10M2WUK for ; Wed, 8 Jul 2020 10:15:39 -0700 (PDT) Received: from mail.digitalbazaar.com (mail.digitalbazaar.com [96.89.14.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81203A0F62 for ; Wed, 8 Jul 2020 10:15:38 -0700 (PDT) Received: from [192.168.0.156] by mail.digitalbazaar.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jtDfV-0004v9-8o for media-types@ietf.org; Wed, 08 Jul 2020 13:15:37 -0400 To: media-types@ietf.org From: Manu Sporny Message-ID: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> Date: Wed, 8 Jul 2020 13:15:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.0.156 X-SA-Exim-Mail-From: msporny@digitalbazaar.com X-SA-Exim-Scanned: No (on mail.digitalbazaar.com); SAEximRunCond expanded to false Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 17:15:41 -0000 Murray S. Kucherawy wrote: > We had the applicant remove this text and instead suggest that they need to > register "+ld+json" independently as a media type suffix, but that such a > registration would likely be denied until such time as the community has > had a chance to discuss its implications. Hi Murray, Mark, and Julian, Let me try to shed some light on how this choice is affecting the W3C WGs working on the JSON-LD, Verifiable Credentials, and Decentralized Identifiers specifications. Way back in the day, when we were working on JSON-LD 1.0, we had to register a media type and the suggestion given by the powers that be at the time was to put the syntax we were using last. We were encoding Linked Data in JSON format, so the natural choice became "application/ld+json" as the media type and subtype. Fast forward four years and we were working on Verifiable Credentials, which have an abstract data model that could be expressed in various formats (JSON-LD or CBOR-LD), but JSON-LD was the primary way, and we didn't have a dire need to go do something like "application/vc+ld+json", and we were concerned that attempting that would just be rejected: https://github.com/w3c/vc-data-model/issues/421 At that point, there was a suggestion that we do "jsonld" as the media type, which would have had negative consequences on all of the software that is deployed in production today and goes against the tribal suggestion that "ld+json" is the right thing to do anyway. Doing "jsonld" was just a hack to get around the question being asked in this thread -- which is, how deep do the subtypes go? https://github.com/w3c/json-ld-syntax/issues/287 We ended up not registering a MIME Type for Verifiable Credentials and instead it was suggested, by the JSON-LD WG, that we register a "Profile Type" for JSON-LD in this registry: https://www.iana.org/assignments/profile-uris/profile-uris.xhtml No one has done that to date, because you can't easily transmit a Profile Type in a variety of the use cases we were looking at (such as MIME Type associated with a file on disk based on file extension -- most operating systems don't support more than just a string expressing MIME Type). Fast forward another four years and we're now engaged in the same discussion in the W3C Decentralized Identifier Working Group (This isn't going away, it's only going to get worse -- we have a handful of other specs in the works with the same problem). In the DID WG specifically, we're not going to be able to dodge the question like we did in the VCWG and JSON-LD 1.1 WG because there are at least four MIME Types being contemplated where JSON-LD Profiles won't work: application/did+json application/did+cbor application/did+ld+json application/did+ld+cbor ... and there is a growing need for a MIME Type for Verifiable Credentials (as they're starting to be serialized to disk and there are use cases that put these things in directories on desktops and laptop OSes): application/vc+ld+json application/vc+ld+cbor So, we're getting cornered into having to pick something and it's going to come down to: application/did+jsonld application/did+cborld OR application/did-ld+json application/did-ld+cbor OR (this seems to be the most tenable one) application/did+ld+json application/did+ld+cborld The W3C JSON-LD 1.1 WG is at the end of it's life, and has not been able to push this decision forward at IETF, so we can't easily register a new MIME Type at this point. I'm sure there are some standards shenanigans that could be played to do that between W3C Staff and IETF ADs, but registering a new MIME Type for "jsonld" is broadly held as the wrong thing to do. If we go down that path, IETF might consider rejecting all new subtype submissions and JSON-LD will become a cautionary tale of where subtypes went wrong... or perhaps there can be guidance given on when *not* to use a subtype that would have prevented the JSON-LD folks (specifically, me as the Editor at the time) from suggesting "application/ld+json" in the first place. The alternate path is that "application/did+ld+json" is allowed, with a clear rationale on why that's a good thing. We have already tested a variety of popular MIME Type parsers across multiple languages out there in the wild and they seem to do the right thing. We go into CR in the W3C DID WG in the next couple of months and we'd like to register all of the relevant MIME Types for the Decentralized Identifier specification by that time. We'd like to register at least this one: application/did+ld+json What would break on the Internet if we were to do that? Are there other options that we're not seeing? -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches From nobody Wed Jul 8 13:18:09 2020 Return-Path: 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 2E84C3A07AF for ; Wed, 8 Jul 2020 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=webr3-org.20150623.gappssmtp.com 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 e11rh6VmzcYP for ; Wed, 8 Jul 2020 13:17:50 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D753A07B0 for ; Wed, 8 Jul 2020 13:17:50 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id a1so51844356ejg.12 for ; Wed, 08 Jul 2020 13:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webr3-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sSjckJXW5zrabamVcgnOyQaq+6sy9HRpFWsAlUDdSN4=; b=csPqhSC1jFzwWHg7n9g+tAkTTSIseahGgrRVlYFMlGx+I5Bb9r2lPPbVf8uPamEHId 0Rsu+OQdkUzubtvTB3m/YNIL9b1Lo2L1jinZ6Yd4yHhtyc92LlPuz+ucT6xOj4w9j6vV n7yEHdiJEKXyiV+0axNpf0+6Me4LWLivFcP/63MHkvtPQO7KB/3r2PE2VcaQ+u50nMI2 A9RDrDVh0UnKQ/WOgjC4QSZLbSw4s1mYoXiNLt0piSGQBanwsO+ST28u15zgM3Gt5/vE D7OSLdiO5rXmy1Pn4ydyC0Kniysv8iUDGmuO2KP2ExX75heWCnEwFWee7R2lRyufI2I3 NS6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sSjckJXW5zrabamVcgnOyQaq+6sy9HRpFWsAlUDdSN4=; b=R+pjdBp+YVVn5SWnIUZJIyh0Xe7OM/UJu+yqJG1Fc+JJJANNEkz2E97M4KaPjSh1cj 2fsdWLbYh23aR2QMAhV5Ho+3HleqFvX547k0r/Xb52m7kACon1HwJBGjSDwAVnP5lUE8 ExWH+00Lr+xjIN2dd5uUJU9wD7MboVLuZ/ckIPS/tEJmvwSj40C2bRorPSSAGXQumNNz K3BJyOocMC80+w7aPS6IU+AkpoQcEeNo82Tz1AAP2mDPlEi+7vZ2BsRNVpy2MYnUNkMi h8578xeYNOTJ3dlZ4B9WWSDXtavV4pr0QhdX2Ul86vsGpAceKD+3iJXZp+8ycg7bQgNu X31Q== X-Gm-Message-State: AOAM533aSEVwI37BEX7MuHKy3YuFsXe0sZLHqYtVg9TmzQlun/SIKDra Rq72O5Acmc7IN4DtEIB3ylpkxIEln9rkSOlx6FcGkoHN X-Google-Smtp-Source: ABdhPJy2vDfcr/WVfsX1GsYK/jzAX+UBUMfRutKr/FzhaHePT3K3yrJ615i8NjEGQKJ14A0WHhe90ZU4owNfO/Ovyb0= X-Received: by 2002:a17:906:c452:: with SMTP id ck18mr56043382ejb.415.1594239468526; Wed, 08 Jul 2020 13:17:48 -0700 (PDT) MIME-Version: 1.0 References: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> In-Reply-To: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> From: Nathan Rixham Date: Wed, 8 Jul 2020 21:17:38 +0100 Message-ID: To: Manu Sporny Cc: media-types@ietf.org Content-Type: multipart/alternative; boundary="00000000000035715b05a9f3cd50" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 20:17:53 -0000 --00000000000035715b05a9f3cd50 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 8, 2020 at 6:15 PM Manu Sporny wrote: > "application/ld+json" > A very small point, which I realise is probably years too late, but in usage "application/json+ld" is far more practical to use, for example in a media selector, similarly "application/json+ld+did" follows the same principal, subtyping reverse requires a great deal of both explantation and code to handle, and gets ever more complex. Finding all "application/json*" is much easier. --00000000000035715b05a9f3cd50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 8, 2020 at 6:15 PM Manu Sporn= y <msporny@digitalbazaar.co= m> wrote:
"application/ld+json"

A very small point, which I realise is probably years = too late, but in usage "application/json+ld" is far more practica= l to use, for example in a media selector, similarly "application/json= +ld+did" follows the same principal, subtyping reverse requires a grea= t deal of both explantation and code to handle, and gets ever more complex.= Finding all "application/json*" is much easier.
--00000000000035715b05a9f3cd50-- From nobody Wed Jul 8 13:44:08 2020 Return-Path: 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 687FC3A07C0 for ; Wed, 8 Jul 2020 13:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XSo4iVU7poJ4 for ; Wed, 8 Jul 2020 13:44:04 -0700 (PDT) Received: from mail.digitalbazaar.com (mail.digitalbazaar.com [96.89.14.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827803A07BE for ; Wed, 8 Jul 2020 13:44:04 -0700 (PDT) Received: from [192.168.0.156] by mail.digitalbazaar.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jtGvC-0001ii-Lo for media-types@ietf.org; Wed, 08 Jul 2020 16:44:02 -0400 To: media-types@ietf.org References: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> From: Manu Sporny Message-ID: <121c5bca-9082-c6bc-68b8-ed7330341904@digitalbazaar.com> Date: Wed, 8 Jul 2020 16:44:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.0.156 X-SA-Exim-Mail-From: msporny@digitalbazaar.com X-SA-Exim-Scanned: No (on mail.digitalbazaar.com); SAEximRunCond expanded to false Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 20:44:07 -0000 On 7/8/20 4:17 PM, Nathan Rixham wrote: > A very small point, which I realise is probably years too late, but in > usage "application/json+ld" is far more practical to use, for example in > a media selector, similarly "application/json+ld+did" follows the same > principal, subtyping reverse requires a great deal of both explantation > and code to handle, and gets ever more complex. Finding all > "application/json*" is much easier. Very true, which is why the first MIME Type attempted for JSON-LD was in fact: "application/json+ld" ... that is, until I was corrected by people that knew better. :) Every now and then I go back and scan through a sea of specifications and mailing lists in an attempt to understand the reasoning behind the choice... find it (at least, that's what I keep telling myself), and then promptly forget because the path is so twisted and meandering. In any case, that ship sailed long ago. -- manu PS: Hi Nathan! It's been years -- hope you're well. :) -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches From nobody Wed Jul 8 16:28:28 2020 Return-Path: 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 CD49D3A0977 for ; Wed, 8 Jul 2020 16:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 k-ky-06QUGgj for ; Wed, 8 Jul 2020 16:28:25 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400130.outbound.protection.outlook.com [40.107.140.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97C03A096E for ; Wed, 8 Jul 2020 16:28:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FCDEKHia0+eKJdZI7A7wuL6vHMUptahBv7ScCBFQ2/1SIX7qk+25w5xjJnBC5WQXgo/xcRQVdOeSbSOubDNqGLPq5gASSaM9yrGmZtO1Q2OouHoBu/xQPHeJ1W9JdOebFrWL/9511obEQCoHv/sPMwdI/IiptDNrRDVGQd5N5EXfaqGCaCb+aoeX4e/415V3wzswAVUnBRwGPTQWi7+BLlqONORNu9/wbvvbYlARZTpBhwYeKop2R4I1kj8mHb/r4eyTzVjy1+UX5gD5GCbv3YHuLGPxvMapZ7iaJxCiaUx9yRp0OBYd9OI9le67htiZE0kPSDPaUqeSg9JvTAanXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VhjAvHRBGsrRBJ08ZVTT0tTdvl5njqevCjm9KDnpjpg=; b=AW0iZLzS6ZFoliWa8LSqIbCgoHiuweFqaIPTlzcEA/stoEnfx6j8nw14CaucxT/uWQ/aAmGmS8OoGX6CllTrN7bC5aIzKiUQSKbC1YP5KCZYCSKYG80IkgTJ12kB0TCwESdTXAHG22DRxF6AbcEg2x1ic8VRxFv/MP1TZ7Qwd8/tpUBiU8ct82fe+m+yeN08sYCyK4zJCrwL9iQ201EZOemBMoeMmU2saJAeAiKPHYTSvlrIo+iSdppzpmRBOOKscMyY4PHwwP6gL9nlM1VKG94elPje6oMnEa7tbUMPaJRar/Awl9kqU2AAw3pSDlooazIXEzlhGVjGTCipGpgjQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VhjAvHRBGsrRBJ08ZVTT0tTdvl5njqevCjm9KDnpjpg=; b=HW96P9rlTU5seKeXO5O41pFkqb8bCZZ0bkILeYMbgLdj6eEBVjhd2adrWWbeRiu+9CrIx2oNixfKLvhYkBVIA4RZCew3HqLmjxKHpOuIUdAL+pOlAUZdAEdWlmML4DxhesvzIjtqrWI9iWw0UdnCDcUm9sU4Ik0aYg2DG0hSyDQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSAPR01MB4753.jpnprd01.prod.outlook.com (2603:1096:604:6a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Wed, 8 Jul 2020 23:28:22 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3174.022; Wed, 8 Jul 2020 23:28:22 +0000 To: Manu Sporny , media-types@ietf.org References: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> <121c5bca-9082-c6bc-68b8-ed7330341904@digitalbazaar.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <4db712b4-394c-9a75-22fb-27709c405480@it.aoyama.ac.jp> Date: Thu, 9 Jul 2020 08:28:19 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <121c5bca-9082-c6bc-68b8-ed7330341904@digitalbazaar.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYXPR01CA0056.jpnprd01.prod.outlook.com (2603:1096:403:a::26) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (125.203.82.4) by TYXPR01CA0056.jpnprd01.prod.outlook.com (2603:1096:403:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20 via Frontend Transport; Wed, 8 Jul 2020 23:28:21 +0000 X-Originating-IP: [125.203.82.4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d8ba5bcd-0ee3-4446-a5ce-08d823969ab9 X-MS-TrafficTypeDiagnostic: OSAPR01MB4753: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04583CED1A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tchGiZNOeen9BBIA66OyMCJSa2mc8hhr3XDEpJwDI7o9iddDGo6CTzlj6zkcqemJZkwfU0Nyl686y+069MgMW4XTDn3tRJjMLUQfVilv6u2kpx9ix8xaMPwgbEBE4FuicLN3iV1x8ZIsiEY1Y+uIQzE5qMPMzR3eordyNw522Y0um5+eZIM6JDjUDLbksu/b1ZFrpdkWQAEeyRenExSKW5GSRPzQo5GPS37NlhipYlyrm64rqzqM/56CjIMyJPin9Jhv0iDVl5QH1jZwo7pBpTF0RLwIKRi8ZUYpW421BTDKaNSyyMu3erJugaHQLvd4IjOkKZ6L9tPSBsohhhWRpAWw+yrNL8VYwd+29/0Kgottsfjps79nhj8xs2xz4MJTikMLN+00sOo30P6pOalhZ4/sVk6lz/OMiCIuMTanzsdLh0U/KU3RBS21PTX+ZbiYpCIX0fjG2RSF0aU1ZfCEtg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(346002)(376002)(39840400004)(366004)(396003)(66556008)(66476007)(66946007)(31696002)(5660300002)(86362001)(83380400001)(31686004)(2906002)(2616005)(956004)(316002)(786003)(16576012)(52116002)(8676002)(8936002)(6486002)(53546011)(36916002)(16526019)(26005)(508600001)(966005)(186003)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: cx9qYu9DI+C2V+gAllJR98H6h5s5vuVzPxq5K7J6UGJOfAQd64/bm29jtwBBWpTvMqUuMYcX5YgpmFa54OkESYjGXN8IwZUCxoYQmNBErc4Fy6PJ8Gb0aWSxc1zqNueGyWn8N5u4atVllJbaUa5ep2uCEmXnfjal3qhbdsEFgLjHYYQ6FAEYn0fVPzCyNlTZK42rZ5htJ5AazmJMIyWFiWNi79odoZR14ZifmqAY/tg0biGbpqcgIp8RmMbJ1vNjqM51V0CNAreW8jRnc/vi+fGINNilXaQzizkcTkogq0bOEXXQ3hsWutsZI0Voq3ZSQBOIQRX6uZIAkccD+t9n7dDQL4Ev71W2dvBYAFIi8ETQe3IsluN6HLtKbvROa+IVPok2KvHSB0ZDJ21WorfcZtDquhdIn5WLeH4wzrWvAPkjzXOSZHMKUVFJWN7qeM6PN012KJGJ3LlBx12DJsBe/Orl92DgYvjwZMAfBdu4Eg0= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d8ba5bcd-0ee3-4446-a5ce-08d823969ab9 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2020 23:28:22.3088 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Jv0ua8D2k2aOw3L2dLNVzOkvdJTpJ8XInUVpiaa1dEWj7eGsyvh3AfgIdN8JEZ5md+Kfr6S7HrJzvThRkpYIzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB4753 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 23:28:27 -0000 On 09/07/2020 05:44, Manu Sporny wrote: > On 7/8/20 4:17 PM, Nathan Rixham wrote: >> A very small point, which I realise is probably years too late, but in >> usage "application/json+ld" is far more practical to use, for example in >> a media selector, similarly "application/json+ld+did" follows the same >> principal, subtyping reverse requires a great deal of both explantation >> and code to handle, and gets ever more complex. Finding all >> "application/json*" is much easier. > > Very true, which is why the first MIME Type attempted for JSON-LD was in > fact: > > "application/json+ld" > > .... that is, until I was corrected by people that knew better. :) > > Every now and then I go back and scan through a sea of specifications > and mailing lists in an attempt to understand the reasoning behind the > choice... find it (at least, that's what I keep telling myself), and > then promptly forget because the path is so twisted and meandering. > > In any case, that ship sailed long ago. Yes indeed. And the reason for the syntax is also quite clear and easy. It came up with XML. For XML, there isn't only application/, there are also image/, message/, and model/ (see https://www.iana.org/assignments/media-types/media-types.xhtml), and font/svg+xml would also be possible even though it isn't registered currently. Similar considerations apply to other suffixes, in particular also those related to compression schemes. Major types and suffixes are not hierarchical. A suffix was easier to pick out than something in the middle. Even for json, there's model/gltf+json, so if you want to deal with all json, you would have to match for "/json", not for "application/json", in a scheme that would but what are now suffixes at the start of the subtype. Regards, Martin. > -- manu > > PS: Hi Nathan! It's been years -- hope you're well. :) > From nobody Wed Jul 22 12:55:43 2020 Return-Path: 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 7AD723A091A for ; Wed, 22 Jul 2020 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com 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 MbEP4HT_cxJa for ; Wed, 22 Jul 2020 12:55:41 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CDC3A08E4 for ; Wed, 22 Jul 2020 12:55:41 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id h190so852981vkh.6 for ; Wed, 22 Jul 2020 12:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yiX57h4aAe+CALpcd7sRzyncv3/D6EHYniPeFqUmnpg=; b=QE7faSvMPENRRTXLuk73BzEJZ2/qu5aZXXlmROc1qyLzffhKsMgikRhYiWqA/xRG7M 1pf5zLDp5gbDGONVCl40ih7Uj/BPJtD9i3v3K9FhGLyGffV0dFaQbS2Q4oisjwqwk+ue qW/iUrf82JQPUWCry7fXnUBbJavkVB/PE3jzz6mdNaMKlwnVIrHp5GKKjW6N89OXdur4 C1+H04bREqcX6enIs0JURQrUIdz8xnMfukuFoQueqoeYUhScB1swLNxuHJJMKLbG6xc5 T+POivUr/xUWQYEBmrjnstSswLNbWVhmhXnj6CZb7v/RkgjpkdKMxNyeM/HYV1Fh2cg/ OxsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yiX57h4aAe+CALpcd7sRzyncv3/D6EHYniPeFqUmnpg=; b=bm97iEPGsIBjT538SCXyCj85HocnfXa6UEsFA9kaQFQI+7b3OgbyZLfushEi8CdGTt Yd17gKq6kJxezW9GXH2kIl6TEhDEmZAKQ3+TST/vbewgMi9CE3bPA3IE/MdepH5U6l7c AlsxIqsf6eHXttwk3ZHKZB+bgI6p3dww+RGr4rFBnDWYIZjB2SdGcpFhMjljebvN9MFQ kpCpXwZW7R1VsyRC7zRsbXnvCfOfF5Fc2oQz71QYZePLtNhzGz0rbrwMj5AwjWv77ql5 v6C3CQ4NDo8PH2UT9faOc6gRclCJ3us07gzaw7oz4iPRcF+kyJiMxem9g78vhBub1/sa sfZQ== X-Gm-Message-State: AOAM533oxKyeE0cOddUOJATk87yRNbk5gYjN1a5NPUN3Bn6C9xkb0RJz N+4YGkMYBg4CxU9ceQqUcYuTcM/XU67YoXPumPM= X-Google-Smtp-Source: ABdhPJxc+3wb719270CEAQ+/S/zkOEmNBBEXL8DylU0RMhjGPGXhmSZ2tiSLHUgXB6WWRpYtf/c1Q93HYzPFGUSi4js= X-Received: by 2002:ac5:c76e:: with SMTP id c14mr1222732vkn.60.1595447739933; Wed, 22 Jul 2020 12:55:39 -0700 (PDT) MIME-Version: 1.0 References: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> In-Reply-To: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> From: "Murray S. Kucherawy" Date: Wed, 22 Jul 2020 12:55:28 -0700 Message-ID: To: Manu Sporny Cc: media-types@ietf.org Content-Type: multipart/alternative; boundary="000000000000cbe8f905ab0d1fb6" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 19:55:42 -0000 --000000000000cbe8f905ab0d1fb6 Content-Type: text/plain; charset="UTF-8" Hi Manu, thanks for chiming in. On Wed, Jul 8, 2020 at 10:15 AM Manu Sporny wrote: > So, we're getting cornered into having to pick something and it's going > to come down to: > > application/did+jsonld > application/did+cborld > > OR > > application/did-ld+json > application/did-ld+cbor > > OR (this seems to be the most tenable one) > > application/did+ld+json > application/did+ld+cborld > > The W3C JSON-LD 1.1 WG is at the end of it's life, and has not been able > to push this decision forward at IETF, so we can't easily register a new > MIME Type at this point. I'm sure there are some standards shenanigans > that could be played to do that between W3C Staff and IETF ADs, but > registering a new MIME Type for "jsonld" is broadly held as the wrong > thing to do. If we go down that path, IETF might consider rejecting all > new subtype submissions and JSON-LD will become a cautionary tale of > where subtypes went wrong... or perhaps there can be guidance given on > when *not* to use a subtype that would have prevented the JSON-LD folks > (specifically, me as the Editor at the time) from suggesting > "application/ld+json" in the first place. > > The alternate path is that "application/did+ld+json" is allowed, with a > clear rationale on why that's a good thing. We have already tested a > variety of popular MIME Type parsers across multiple languages out there > in the wild and they seem to do the right thing. > > We go into CR in the W3C DID WG in the next couple of months and we'd > like to register all of the relevant MIME Types for the Decentralized > Identifier specification by that time. We'd like to register at least > this one: > > application/did+ld+json > Mark is asking the right question, I feel: Do we know how well suffixes have fared, in terms of having been a benefit? I'm not sure how one would go about determining this. I would love to hear suggestions. What would break on the Internet if we were to do that? Are there other > options that we're not seeing? > I also don't know how to answer this, other than to claim that we tend to err on the side of being cautious about making assumptions. Having never implemented a browser or something else that has to handle media types, I don't know if I would look for a suffix by searching for a "+" from the left or from the right, and thus I don't know what would break because the results here are obviously quite different. My inclination is to ask that we debate a draft that's an update to RFC 6838, which describes media type suffixes more precisely in a way that explains how to use what looks like a nested suffix structure like this. That is, make it clear that "application/did+ld+json" is to be interpreted as a type of "application" and a subtype of "did" with a suffix of "+ld+json", or a subtype of "did+ld" with a suffix of "+json", or a subtype of "did" with two ordered suffixes. Is someone from the W3C willing to put such a draft together? -MSK --000000000000cbe8f905ab0d1fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Manu, thanks for chiming in.
=
On Wed= , Jul 8, 2020 at 10:15 AM Manu Sporny <msporny@digitalbazaar.com> wrote:
<= /div>
So, we're gettin= g cornered into having to pick something and it's going
to come down to:

application/did+jsonld
application/did+cborld

OR

application/did-ld+json
application/did-ld+cbor

OR (this seems to be the most tenable one)

application/did+ld+json
application/did+ld+cborld

The W3C JSON-LD 1.1 WG is at the end of it's life, and has not been abl= e
to push this decision forward at IETF, so we can't easily register a ne= w
MIME Type at this point. I'm sure there are some standards shenanigans<= br> that could be played to do that between W3C Staff and IETF ADs, but
registering a new MIME Type for "jsonld" is broadly held as the w= rong
thing to do. If we go down that path, IETF might consider rejecting all
new subtype submissions and JSON-LD will become a cautionary tale of
where subtypes went wrong... or perhaps there can be guidance given on
when *not* to use a subtype that would have prevented the JSON-LD folks
(specifically, me as the Editor at the time) from suggesting
"application/ld+json" in the first place.

The alternate path is that "application/did+ld+json" is allowed, = with a
clear rationale on why that's a good thing. We have already tested a variety of popular MIME Type parsers across multiple languages out there in the wild and they seem to do the right thing.

We go into CR in the W3C DID WG in the next couple of months and we'd like to register all of the relevant MIME Types for the Decentralized
Identifier specification by that time. We'd like to register at least this one:

application/did+ld+json

Mark is asking = the right question, I feel: Do we know how well suffixes have fared, in ter= ms of having been a benefit?=C2=A0 I'm not sure how one would go about = determining this.=C2=A0 I would love to hear suggestions.
What would break on the Internet if we were to do that? Are there other
options that we're not seeing?

I al= so don't know how to answer this, other than to claim that we tend to e= rr on the side of being cautious about making assumptions.=C2=A0 Having nev= er implemented a browser or something else that has to handle media types, = I don't know if I would look for a suffix by searching for a "+&qu= ot; from the left or from the right, and thus I don't know what would b= reak because the results here are obviously quite different.

=
My inclination is to ask that we debate a draft that's an up= date to RFC 6838, which describes media type suffixes more precisely in a w= ay that explains how to use what looks like a nested suffix structure like = this.=C2=A0 That is, make it clear that "application/did+ld+json"= is to be interpreted as a type of "application" and a subtype of= "did" with a suffix of "+ld+json", or a subtype of &qu= ot;did+ld" with a suffix of "+json", or a subtype of "d= id" with two ordered suffixes.

Is someone fro= m the W3C willing to put such a draft together?

-MSK
--000000000000cbe8f905ab0d1fb6-- From nobody Wed Jul 22 16:33:55 2020 Return-Path: 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 4C8773A0993 for ; Wed, 22 Jul 2020 16:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vUCxc3ixrIQd for ; Wed, 22 Jul 2020 16:33:52 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [192.0.33.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E423A098E for ; Wed, 22 Jul 2020 16:33:52 -0700 (PDT) Received: from vuizook.err.no (vuizook.err.no [IPv6:2a02:20c8:2640::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by pechora4.lax.icann.org (Postfix) with ESMTPS id CE18E70063E3 for ; Wed, 22 Jul 2020 23:33:51 +0000 (UTC) Received: from cm-84.212.193.114.getinternet.no ([84.212.193.114] helo=hjemme.reinholdtsen.name) by vuizook.err.no with smtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jyNZg-0002dv-MT; Wed, 22 Jul 2020 22:50:59 +0000 Received: (nullmailer pid 28313 invoked by uid 10001); Wed, 22 Jul 2020 22:50:52 -0000 From: Petter Reinholdtsen To: media-types@iana.org In-Reply-To: <6a4647588a6f4bf2afc458bceb753fb4@pco.de> References: <6a4647588a6f4bf2afc458bceb753fb4@pco.de> Date: Thu, 23 Jul 2020 00:50:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Delayed for 00:42:28 by milter-greylist-4.6.2 (pechora4.lax.icann.org [0.0.0.0]); Wed, 22 Jul 2020 23:33:52 +0000 (UTC) Archived-At: Subject: Re: [media-types] New subtype "image/vnd.pco.b16" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 23:33:53 -0000 [Jan Zeman] > Hello, > > I would like to register the new media subtype "image/vnd.pco.b16" > for the proprietary B16 file format with the extension ".b16", > developed by the camera producer PCO (www.pco.de) for saving > images from the cameras. Do you think I could ask IANA for that > with the appended proposal? I have no authority on the topic, but after having lurked on this mailing list for a while, I recommend you go ahead and submit your proposal to IANA, as it is unlikely you will get any relevant feedback here in a timely fasion, and the IANA team seem to be quite quick to respond. :) -- Happy hacking Petter Reinholdtsen From nobody Wed Jul 22 18:47:23 2020 Return-Path: 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 0E0C53A0B12 for ; Wed, 22 Jul 2020 18:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 KITkP6AptWxN for ; Wed, 22 Jul 2020 18:47:20 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410131.outbound.protection.outlook.com [40.107.141.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD533A0B0B for ; Wed, 22 Jul 2020 18:47:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e9YW9w+3A5opNSwyIiaA3pNBoZ8ygO70hzudCtAcPOICR5TUHV62hggfckjGbhJicWCPCOjjzYai1JUI4cfdHbdALjdVxkch5hVYBL+3VyBJYCN5j5vhI2HkNRMGPQ/e4ZQhtHRW8eA9E9VyrMZHK7l134EtntiRg2BDGSk0xr7Ivy2p3H3AwSM9A2R59Uv976Q9HDY+iPG5XrQCWLQ+RdJ0+LXeikjUTl3csYtGwFe8M0GjToLBL8a2MzPSTEjLJX3018bG1TtrQkUgpTH5qvix9tI/x0fene0DYDkZLLDr+kfbHl/YyRuUlN2JWHNrjFCjI+7I5/Nc69yagLv5WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iq+cubmpTHBAZfkQTtregkE9bY8eQbFB4L+1egNc4nw=; b=Ixlw/hP0uCLhFKzE2L0OMKOqJdtk0b+vXB7uMN2Tl98byQIB0W+Hfje3323w/Yb0JYlMSFtxbR+YOihUdbnEncxCl/MQigeOsDl+kd87kxXgmO85Ur/x6AyXwFFZKHTtocLmvAv3LkGCYve6RrHDyOUVzcNewpwFKR31RQTbbmjrSmqLI5ZFMDy1W3DRvz2m8zqCAORyEx8xUfQL076b01WyOZzuqQJrA/CQA71fvCmEjVMAP/IEfpOEecvEkjhIwXdwyKp1xbhSZDcg7tFsuO9Gbm2BeIvpKWnQZR43kfMlGqeYutqRr/yrFsVFmsB/rHolA78nD4AysNiVZmbdcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iq+cubmpTHBAZfkQTtregkE9bY8eQbFB4L+1egNc4nw=; b=iHZGZv9DGHS4gDeMZbtVobKLvr3Kajn8j10U8UyA3uT7/jA6KZus272QZgvzyWHydrI6nMJZcLTxbyrQhS3us5pzxAVvIB8N+GEWBLHIFaYzgoeh/3u/Nvejx1hV/Wivu35rZWzNyvpx2gT9hi+hsXNimeXA0FmQZDFGyryG3e8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB2726.jpnprd01.prod.outlook.com (2603:1096:604:11::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Thu, 23 Jul 2020 01:47:15 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3216.020; Thu, 23 Jul 2020 01:47:15 +0000 To: "Murray S. Kucherawy" , Manu Sporny Cc: media-types@ietf.org References: <3d459015-b748-9ee9-21ca-89e7229d030e@digitalbazaar.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <4340985a-8bf7-ec0d-0f94-14f873773177@it.aoyama.ac.jp> Date: Thu, 23 Jul 2020 10:47:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0105.jpnprd01.prod.outlook.com (2603:1096:404:2a::21) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.4] (60.35.95.99) by TYAPR01CA0105.jpnprd01.prod.outlook.com (2603:1096:404:2a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20 via Frontend Transport; Thu, 23 Jul 2020 01:47:14 +0000 X-Originating-IP: [60.35.95.99] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7adad4ff-c41c-4d21-7251-08d82eaa5352 X-MS-TrafficTypeDiagnostic: OSBPR01MB2726: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jrrh7Vkbx7qDtVwyAxcevkZlviPUqK7bhspksT0vnZYetlIrS3j8sOGkiIq6bjW32sG5C2rprrATUO7+48ekA1sZF06/VELQEM40clzIbcBXuxT5+qbhB/jAxT92hYxTbIlLy7Z14AT7nguDPywZe+cuw+6Na057shFVNgyb0sbjYAp79/w8XtNY5OLoBgvLFTeyH+/Y7udI5kA38k2xtNnC8h/6VtuPBM4cNS9fqtVqpqMvDko+oxkCDzlUvoE60RqqrfcgrSERKD+l7YcDoJ6WRr3GJ4/r+2TOl90hbHjDG6sMS8w/GqVhCaQgr3UAePWme4mXK+4oq5R39qZywn4naN3FKxtLzgD8vm76ySN3Tu7bBRYiHrjkjhbttm0r7v8RqPZ8/t+rYdiep3M2COK5sCOs2cu7mjwr4OicmQGmvRchTh7zOgBMYpEq0FtHGEOrZ2fVcErZr/2yxnIkqg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(136003)(396003)(39840400004)(366004)(346002)(31696002)(66556008)(66476007)(86362001)(966005)(4326008)(508600001)(8676002)(2906002)(16526019)(5660300002)(110136005)(66946007)(16576012)(786003)(316002)(52116002)(36916002)(31686004)(26005)(66574015)(2616005)(956004)(83380400001)(53546011)(6486002)(8936002)(186003)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: tt8+x2Uhy5MLpkpJ37gSPfr9AknSLdSRMPnPQHQaJR+/5spiIVLPevBqqdzL7QMrO9HVe2wgl4WSDiMvsGngjEvyRBEg+6IHPWgXZsexysTvR59QMvrqZRHonnmnKJdKmS17Kxd/E7WRSADRLF7j1oso+az21GQuAZzTndMWaA9NuaIDxD/mqu9wW+eAGdRbBiWSG0+IPDQD8HhRgGq4e++dx8qmclDFXdPThvy9e3+WjAX0OwfMLzFQjZkfLHNSQ72+keUr1G5lMvpvVbm2tf+QpVtG+W6kDiZ4p9VD22KOzWfEwmTTBAgf+/x3r1/QzIgUEJHzh/BTRk+gjKktwklueY47rBSqqMER3lvQhi0pFWaQvNDiKAMJ0jYnUQm60HLlLttKWVtGE+fMjiP7m7tCCnVmmENOpWaibcqvtepLlMmPGgJrDuis2X3cqYyjQR97myTMm8y9d0atYB2hDpbnGxbwDD4FsIXOoZ5rkV4= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 7adad4ff-c41c-4d21-7251-08d82eaa5352 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2020 01:47:15.1894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dFQ37cu1fK6TBRVcQZ5zMiKNghuiLrlm4afWViw0NpKl7x/4Cq7Trj/oSMWLsEbdPgJHghqjdOJAh7oF1zCFlA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2726 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 01:47:22 -0000 On 23/07/2020 04:55, Murray S. Kucherawy wrote: > Hi Manu, thanks for chiming in. > > On Wed, Jul 8, 2020 at 10:15 AM Manu Sporny > wrote: > >> So, we're getting cornered into having to pick something and it's going >> to come down to: >> >> application/did+jsonld >> application/did+cborld >> >> OR >> >> application/did-ld+json >> application/did-ld+cbor >> >> OR (this seems to be the most tenable one) >> >> application/did+ld+json >> application/did+ld+cborld >> >> The W3C JSON-LD 1.1 WG is at the end of it's life, and has not been able >> to push this decision forward at IETF, so we can't easily register a new >> MIME Type at this point. I'm sure there are some standards shenanigans >> that could be played to do that between W3C Staff and IETF ADs, but >> registering a new MIME Type for "jsonld" is broadly held as the wrong >> thing to do. If we go down that path, IETF might consider rejecting all >> new subtype submissions and JSON-LD will become a cautionary tale of >> where subtypes went wrong... or perhaps there can be guidance given on >> when *not* to use a subtype that would have prevented the JSON-LD folks >> (specifically, me as the Editor at the time) from suggesting >> "application/ld+json" in the first place. >> >> The alternate path is that "application/did+ld+json" is allowed, with a >> clear rationale on why that's a good thing. We have already tested a >> variety of popular MIME Type parsers across multiple languages out there >> in the wild and they seem to do the right thing. >> > >> We go into CR in the W3C DID WG in the next couple of months and we'd >> like to register all of the relevant MIME Types for the Decentralized >> Identifier specification by that time. We'd like to register at least >> this one: >> >> application/did+ld+json >> > > Mark is asking the right question, I feel: Do we know how well suffixes > have fared, in terms of having been a benefit? I'm not sure how one would > go about determining this. I would love to hear suggestions. I'm also not sure how we would do this. But one thing that occurs to me is that it may differ quite a bit depending on the actual suffixes. In particular, the benefits for +ld+json should be rather high, because JSON LD can be interpreted as RDF, and RDF data from different sources and with different vocabularies can be integrated rather easily (at least so the story goes). So I'm not surprised to see such a proposal come from such a WG. Another point is that these suffixes are not only for machines. They may help humans, too. They may help people understand how a document is structured. And they may also help direct people who design new types to use existing types and build upon them, rather than invent their own clundges. > What would break on the Internet if we were to do that? It's easily possible that there is some software that is looking for the first or the last '+' in a subtype, with the expectation that it's the only one, or that checks that there is at most one '+'. > Are there other >> options that we're not seeing? >> > > I also don't know how to answer this, other than to claim that we tend to > err on the side of being cautious about making assumptions. Having never > implemented a browser or something else that has to handle media types, I > don't know if I would look for a suffix by searching for a "+" from the > left or from the right, and thus I don't know what would break because the > results here are obviously quite different. The 'correct' (according to a comment in the ABNF in RFC 6838, see https://tools.ietf.org/html/rfc6838#section-4.2) is that one should look for the last '+'. >>>> restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix >>>> > My inclination is to ask that we debate a draft that's an update to RFC > 6838, which describes media type suffixes more precisely in a way that > explains how to use what looks like a nested suffix structure like this. This seems to make sense. > That is, make it clear that "application/did+ld+json" is to be interpreted > as a type of "application" and a subtype of "did" with a suffix of > "+ld+json", or a subtype of "did+ld" with a suffix of "+json", or a subtype > of "did" with two ordered suffixes. I'd propose it be interpreted as two suffixes, along the following hierarchy: application application/json application/ld+json application/did+ld+json The change of direction is unfortunate, but we already have it here and e.g. in URIs. And we have to be careful with the term 'subtype'. In RFC 6838, that refers to everything after the slash, i.e. 'did+ld+json'. Regards, Martin. > Is someone from the W3C willing to put such a draft together? > > -MSK