Re: [media-types] Multipart without boundaries

Harald Alvestrand <harald@alvestrand.no> Sun, 17 March 2024 00:08 UTC

Return-Path: <harald@alvestrand.no>
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 07823C14F6A1 for <media-types@ietfa.amsl.com>; Sat, 16 Mar 2024 17:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 vQ9hzN4-4Mpv for <media-types@ietfa.amsl.com>; Sat, 16 Mar 2024 17:08:28 -0700 (PDT)
Received: from smtp.alvestrand.no (smtp.alvestrand.no [65.21.189.24]) (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 597AFC14F5E2 for <media-types@ietf.org>; Sat, 16 Mar 2024 17:08:28 -0700 (PDT)
Received: from [31.133.131.210] (dhcp-83d2.meeting.ietf.org [31.133.131.210]) by smtp.alvestrand.no (Postfix) with ESMTPSA id B0D8F4E646; Sun, 17 Mar 2024 01:08:25 +0100 (CET)
Message-ID: <e4a5042e-45bf-4fbe-90d0-582629fdaf79@alvestrand.no>
Date: Sun, 17 Mar 2024 10:08:22 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Rahul Gupta <cxres=2Bietf=40protonmail.com@dmarc.ietf.org>, "media-types@ietf.org" <media-types@ietf.org>
References: <DPpVLsMpOTXGKBc_0YGGl1OLVitXsltzuXX7S-ACdXvkVATr8nokumY3UXzSsIFcWF-szUouy-0Sb3iJLdonZaQGqNQPs9LWH1Tb1geKIUU=@protonmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <DPpVLsMpOTXGKBc_0YGGl1OLVitXsltzuXX7S-ACdXvkVATr8nokumY3UXzSsIFcWF-szUouy-0Sb3iJLdonZaQGqNQPs9LWH1Tb1geKIUU=@protonmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/X8ydjsvLsx1YGKmKlsRDFs-TCsU>
Subject: Re: [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: Sun, 17 Mar 2024 00:08:32 -0000

Thanks for your submission!

The definition of new media types is outside of the charter of MEDIAMAN, 
though.

Personally, I think that using "content-length:" for generic multipart 
content is likely to be a design mistake - there's too much processing 
that subtly alters the length of the message. It would only be 
dependable if you were to pair it with a message checksumming mechanism 
such as Content-MD5 so that content modifications could be detected - 
and it would still not allow you to reconstruct the original message if 
the signature was broken by a transform.

Content delimiting is a subject with long traditions - the "chunked" 
content-transfer-encoding and the delimiting of message bodies in 
HTTP/1.1 are just two of the areas in which it has been approached.


On 3/15/24 10:18, Rahul Gupta wrote:
> 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
>
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types