Re: [media-types] Feedback on a potential media type for upload chunks

Mark Nottingham <mnot@mnot.net> Wed, 28 February 2024 22:24 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 408ABC14F60A for <media-types@ietfa.amsl.com>; Wed, 28 Feb 2024 14:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=mnot.net header.b="tq037HME"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="RIYAQ9DR"
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 oo6J2z_jnvra for <media-types@ietfa.amsl.com>; Wed, 28 Feb 2024 14:24:48 -0800 (PST)
Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com [103.168.172.150]) (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 9C9ADC14F604 for <media-types@ietf.org>; Wed, 28 Feb 2024 14:24:48 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 9D64D13800AD; Wed, 28 Feb 2024 17:24:47 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 28 Feb 2024 17:24:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1709159087; x=1709245487; bh=o1KxorNC5DoshSj+HO4OcC+ndHfrgGAFsjc1fKzT2Zg=; b= tq037HMEaGsfZIRL0WwFbjGlQ/XslJJW4oMdLO/gewwDgFMfk1TzjzTJdx+Qm64G /X7A4lvpbS/HFsxFC7BX/FlJcBj20nHkz4fiOdLD2HbRgCl48WU3EnYTIGbWIHKU jWDDq8z6zQGV4ZmeL5pLOq2OVh8w+8adBo4Fuvz07D9YCjei7e+PhoaubEUBRTZO 403gyOipSzg1copO979BCAkCxm8e0POxYuH5EUz30UCi+/0fuiN+zbvN8wgsJxQp 9bcg7JeBR0STE15AsE8ClG68nsKb/DTTK0ebqwUwKhgiIzLuci8bWZFhDW/SsMOS 1GjYx8aH2bJKIwjpKdx6vQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709159087; x= 1709245487; bh=o1KxorNC5DoshSj+HO4OcC+ndHfrgGAFsjc1fKzT2Zg=; b=R IYAQ9DRXn3fIKbDmp8238TXagIpdccjFFczcSLotA0f/lUwEPyqsSifoyeXchcT7 ueyDoIdSQmx2V2cBZ8PjTkOhLfIEgNqUE3PShUWDZ12NNRYgeyCBpA0Rhv38gw8e wk8l/KxtP6i0EUGXMWtWc+vxCGiTQCegO0TlSfVwOtK7gSMVqGdukaRALxOO6tPO kviIPZ6llRKE2gR4b0FovjEKaFY77CwYnqo5i/ABgcdVg2lPpRFFWZGOj8Q1OBeQ INLXmM3vUzl08CbYD2Hra2V0OUTfb5YsqL2xeX5W3m7ha7x1V9Dtf20M3L4f2J5A GWzhwpq4uamRo6Hb7NEVA==
X-ME-Sender: <xms:r7LfZRuuB0xe2trplwq1DfO9CNgG8JYLlnrP9ze7qF3x9Uawidm0nw> <xme:r7LfZad_i3g2EjaTTYyOdPvNmwGBziN4w30esEhKZPxNHDmQyuR2qFqMYLdnfrU_I s7BgOxX7YFqCZEg1A>
X-ME-Received: <xmr:r7LfZUy8aR83ywEZQoAltfue9y_fMvaPo2VHUH4LSDKDUI5GA-l69sJqCoJmp4MpwcD3zwRWL6AKlAhOkse6VvCETHU5py9jww-uDJ_PIbISSSqnjtd6XLfc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrgeejgdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepvddugfeihfeltddttefgvedvueehudehgfefveefjeeuvedutddvieelheek jedvnecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgvthhfrdhorhhgpd hirghnrgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:r7LfZYPgJCLpNHezUmd36RRv-u9xcET3JBTAb99RzZ29LpwBT4f5Vg> <xmx:r7LfZR8OcXqYvYxBX_AJMFBd0Eh5i8M7oxbLGwRY4YW_R5qMUIsiOQ> <xmx:r7LfZYV5TRwlbvR1l4-z_aGZfABKX5WnCO5C5vDExazlK2O3vZpBWQ> <xmx:r7LfZTIgngjYWNhmNLy7OoMvn5QBbV8Vm8ff1DhBEok0W6euyA5IJQ>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 28 Feb 2024 17:24:46 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <939d9892-9512-4685-9476-3546529d372b@alvestrand.no>
Date: Thu, 29 Feb 2024 09:24:43 +1100
Cc: media-types@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <216EA7D9-692D-4AA3-9C59-47EAB7B5EE22@mnot.net>
References: <CANY19Nuq1NROzfOytcVJFBMN5cSisPzt_YH6NxRRinjwLg1rkg@mail.gmail.com> <939d9892-9512-4685-9476-3546529d372b@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/4j-O5gyu8ZXJ3Y5uILZAtLSdlpE>
Subject: Re: [media-types] Feedback on a potential media type for upload chunks
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: Wed, 28 Feb 2024 22:24:53 -0000

PATCH _requires_ that the media type identifies the semantics of the body, so applciation/octet-stream is not suitable; it does not tell the receiving server what to do with those bytes.

See:
  https://www.rfc-editor.org/rfc/rfc5789.html#section-2


Cheers,


> On 28 Feb 2024, at 23:43, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> If the interpretation of a partial upload is simply a sequence of bytes, I would strongly suggest using application/octet-stream.
> 
> The semantics ("append this to the current upload") seem to be related to the request, not the media.
> 
> Some other considerations apply for files that are (for instance) uploaded in chunks, where each chunk is required to be semantically complete in some syntax (video frames for instance). In that case, registering a media type for "sequence of instances of type X that can usefully be concatenated with another sequence of instances of type X" - but this would strongly depend on exactly the file being transferred, not on the fact that this is done using a PATCH mechanism.
> 
> Hope this viewpoint is useful!
> 
> 
> On 2/26/24 20:01, Marius Kleidl wrote:
>> Dear working group,
>> in the HTTP working group, we are discussing a draft for resumable uploads over HTTP (https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/ <https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/>). Essentially, for each file that should be uploaded, a new upload resource is created on the server. The client can then append data to this upload resource by sending a PATCH request. If the transfer gets interrupted, the client can query the upload resource's current offset and then resume the upload by appending the remaining data using another PATCH request.
>> As required by RFC 5789, PATCH requests must include a media type to describe the message content. In the case of resumable uploads, the content is just a partial chunk from the file to be uploaded without any additional data included in the message content (no offset or length value). This chunk might be textual or binary depending on the file that should be uploaded (e.g. text file or video).
>> I didn't find a registered media type in the standards tree which matches those semantics. However, the vendor tree includes application/vnd.adobe.partial-upload (https://www.iana.org/assignments/media-types/application/vnd.adobe.partial-upload <https://www.iana.org/assignments/media-types/application/vnd.adobe.partial-upload>), which was registered by Adobe in 2009 for uploads in their web applications. Its intention seems to align with the content included in PATCH requests for resumable uploads.
>> Therefore, I am thinking about a standardized media type to describe partial chunks from an upload, such as application/partial-upload or application/upload-chunk and would love any feedback on that idea.
>> Best regards
>> Marius Kleidl
>> _______________________________________________
>> media-types mailing list
>> media-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/media-types
> 
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types

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