[media-types] Multipart without boundaries

Rahul Gupta <cxres+ietf@protonmail.com> Fri, 15 March 2024 14:19 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 E0DC5C14F702 for <media-types@ietfa.amsl.com>; Fri, 15 Mar 2024 07:19:04 -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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=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 7weR08tsfUh2 for <media-types@ietfa.amsl.com>; Fri, 15 Mar 2024 07:19:00 -0700 (PDT)
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) (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 BC461C14F5E7 for <media-types@ietf.org>; Fri, 15 Mar 2024 07:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1710512337; x=1710771537; bh=iBZOp7tnIutAYdm1BGY1AVxTt6nZBx+KriEEWJP5Weg=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=wCYUUfRR36pl3obWTgZDBpwYYqMwF9mZE5689Ic/cBR4d/cYIcNek+/YxCEHUc65H HQ/iu7KsH9xSJDtmmQ1SdJx9eGTzq08CYD3QS3o0T813+N64RqoUN8GHt8gUUza+lR Tf84DGc9fd0ntqf951jIxif7DXBrwkpp0iGW4Boyne77Yo1Rh+uivs2gGgRP12kfzo /0nqP3v1yoF9Lz3bWh0eI9kSXF3o93PtvyZY4sECuRqHfz16ewx0qjyxF96juG9i7H xnAxkEtRwuqXTgJIUySScyel09rwYD2Qhzo60+gV0snBErmu1QcRJMYcQQtEb9y1P1 w883HSFSZvVKQ==
Date: Fri, 15 Mar 2024 14:18:53 +0000
To: "media-types@ietf.org" <media-types@ietf.org>
From: Rahul Gupta <cxres+ietf@protonmail.com>
Message-ID: <DPpVLsMpOTXGKBc_0YGGl1OLVitXsltzuXX7S-ACdXvkVATr8nokumY3UXzSsIFcWF-szUouy-0Sb3iJLdonZaQGqNQPs9LWH1Tb1geKIUU=@protonmail.com>
Feedback-ID: 919445:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------9a4e038ce134dab3d07bd7a3b93f6cee8f435f1ac55a767d0c4bcfb6db8182c3"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/ny3jYWdb6K72a8u-wyUOePo9PxQ>
Subject: [media-types] Multipart without boundaries
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: Fri, 15 Mar 2024 14:19:05 -0000

Hello Media-type enthusiasts,

I am proposing a new Internet-Draft "Multipart without Boundaries".
https://cxres.github.io/multipart-without-boundaries/draft-gupta-mediaman-multipart-without-boundaries.html

Like the title says, it proposes a new syntax that uses `Content-Length` in each part and thus does not use boundary delimiter to separate encapsulated parts. As explained in the draft, this solves an outstanding issue when parts are dynamically generated (and generally simplifies parsing), especially when used in notification protocols (It is inspired from Braid's subscription response, but respects existing HTTP content-type conventions).

One issue that I faced while writing this draft is that I could not find a IANA registration for the "boundary" parameter for "multipart" media-type in any of the registries. So I am not sure of what instructions to give to IANA for the "no-boundary" parameter.

This is a tiny draft that solves a very specific and limited issue. I know that I am too late for I-D submission and publishing it almost on the eve of the Brisbane round, but I would still appreciate it if the Chair could please sneak it in at least as an announcement (or 5 minute discussion) in the Mediaman session.

Thanks in advance,

Best Regards,
Rahul