IETF Logo Mail Archive

Re: [media-types] (No subject)

Rahul Gupta <cxres+ietf@protonmail.com> Mon, 18 March 2024 12:55 UTC

Return-Path: <cxres+ietf@protonmail.com>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9F4C180B52 for <media-types@ietfa.amsl.com>; Mon, 18 Mar 2024 05:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=protonmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQXaAqD1qxUZ for <media-types@ietfa.amsl.com>; Mon, 18 Mar 2024 05:55:04 -0700 (PDT)
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) (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 C89B9C151985 for <media-types@ietf.org>; Mon, 18 Mar 2024 05:55:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1710766501; x=1711025701; bh=G2m/s2LEXoXLYKZQdtTl5BE+z5dirWcyw2c2A8K0Z64=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=B35t2+CQP+8DLByj1jDPCvsY+8ABuTxcnaaWwyTT+3kuzCOo7Uk35qKMNdw3e+Ujt EdygHEwgCdUA79M3q6m4Tc4XBOiPod1JbJkNd8EEz9szUzOANNbNYtwdrKDIWF+Ve2 f449xkbdb7haH47dzJ0kXZhanR9+Ua9uQjLt2EfkzdJkRB/Mfxp+nw/QPZdKQCg3Tk bzpnw/s441vEd8OyPoVs3DnFg/DQzzqWth2US6gMMKkbZL9zSahTZ5VuSmHUARoziu eTb+I/l4KEaaXEqiYzQ4i56GUsw6oK3uNTh9E8rsNkG+JAPxrex8IBGe7iY/rHaZ/n shQUZ/TOdnerQ==
Date: Mon, 18 Mar 2024 12:54:49 +0000
To: John R Levine <johnl@taugh.com>
From: Rahul Gupta <cxres+ietf@protonmail.com>
Cc: media-types@ietf.org
Message-ID: <K8RzqeIcCsMuy_L1SYRTLg-ykoT1XcaqfN8yPxGEagHfkmf3xrKfO0fjF35WePCCHwTWDvU6L-MEgS3nHBqFR2k_QPaGY3EyFNIf1GnZKmM=@protonmail.com>
In-Reply-To: <ac2361a6-0f58-a85f-a200-1b774ab775ce@taugh.com>
References: <20240317162649.0A1C4858A949@ary.qy> <ytJX8k3f2L3DXL4A13WkjpnIS-YDNscJHM67ExwNXZbkVOXlNMVkzeKLAMqLvJ7INahfyula81upmpOYDOScFDPz49rcnmR88cKLbe6BDBw=@protonmail.com> <ac2361a6-0f58-a85f-a200-1b774ab775ce@taugh.com>
Feedback-ID: 919445:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------21a227711c2b913fea1dc9a75bc6bd7aec380e11f04873ed848b6b55201093f9"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/jfW7hFo_mdIaNuo65nu3HEljins>
Subject: Re: [media-types] (No subject)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 12:55:08 -0000

I think you are right! Not knowing for certain that the new syntax, if sent, will be processed or not, is a problem.

Unfortunately, defining a new top-level media type for message encapsulation much more of a hassle, because one would obviously want to design it in a manner that is a bit better (absorbing the 30 years of wisdom) than the existing multipart. That I am doing it only so that notification are supported in HTTP/1.1 as well, where they will never scale in practice, makes it twice the hassle. And there will be the inevitable "holy wars" if I even try building consensus on such a new format (already seeing this). Sigh!

In any case, I appreciate your input!

BR/Rahul

On Monday, March 18th, 2024 at 11:05 AM, John R Levine <johnl@taugh.com> wrote:

> On Mon, 18 Mar 2024, Rahul Gupta wrote:
> 

> > Based on the feedback you and Alexey have given, I have updated the
> > draft with a paragraph that makes it explicit that this specification is
> > optional. Existing recipients should and will simply reject this syntax,
> > based on the absence of "boundary" parameter in the `Content-Type`
> > header. Only if the recipient chooses to parse the message (after seeing
> > the parameters), do they need to process the multipart body according to
> > the proposed syntax. I hope this allays all backward compatibility
> > fears.
> 

> 

> Unfortunately, that doesn't help at all. Since you cannot predict what
> software the other end will be using, if you want to interoperate, you
> cannot use this syntax at all, ever.
> 

> If you happen to have a private agreement with the other party where you
> both know you can handle this, you can use it, but if you have a private
> agreement, you don't need a standard.
> 

> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

v2.23.0 | Report a Bug | By Email