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

Marius Kleidl <marius@transloadit.com> Wed, 28 February 2024 23:18 UTC

Return-Path: <marius@transloadit.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 D4811C14F71B for <media-types@ietfa.amsl.com>; Wed, 28 Feb 2024 15:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_FAIL=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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=transloadit.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 T5uIkkj-YdAX for <media-types@ietfa.amsl.com>; Wed, 28 Feb 2024 15:18:35 -0800 (PST)
Received: from pechora3.dc.icann.org (pechora3.icann.org [192.0.46.73]) (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 F1E13C14F71A for <media-types@ietf.org>; Wed, 28 Feb 2024 15:18:34 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pechora3.dc.icann.org (Postfix) with ESMTPS id E27077000608 for <media-types@iana.org>; Wed, 28 Feb 2024 23:18:33 +0000 (UTC)
Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2d24a727f78so3365791fa.0 for <media-types@iana.org>; Wed, 28 Feb 2024 15:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transloadit.com; s=google; t=1709162293; x=1709767093; darn=iana.org; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=avUdCFYY2n14EgwPAf+mzCfXa0o8Jxkx07JGiDMBuEE=; b=CwZjYNsZ5czFlslqcSkngpza9989fy+fsaqr6TESlTXpsS0KOBZErzgfR8YcrN5oBp FEzg/Wwhe0dQU7QRBm7as+3Wsp2HcyiSfMGqTxd1EhyhMMQn4+R9jKif+b9rMt4O+MEr WV2fSaqTZMQtJgTVr7L+h8bTDMIb4LprfpvgY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709162293; x=1709767093; h=mime-version:subject:references:in-reply-to:message-id:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=avUdCFYY2n14EgwPAf+mzCfXa0o8Jxkx07JGiDMBuEE=; b=LxmRyPfXXlkPUNgkhDV9HQc6i5r8xNe7qcCEYQQcEVSg40lT4Onwe5Igh4otVRYUCO kHlRk45L2bvf+6qwASAjWTGtKS2XzomLL95ny7Zy1ngx/NoLR9yBR/ApF941F8YeGZVu aNYJpzKon277tNNYvR26xRMz4iQNCFDC9ZpOmSQY1Ya8Sw57/aRp1ag4c3jlz0EAAm6E uYWqSo4cHeXe7AqLHC+OGI5uIgiG3uN8R6Db9DHJ5nwtJGgbOkQpUQFNuqZW5+9wEJQW yP9EyuzWzGdTjz2GPRTdS9+3tafiCynWoAaevnjiOzk7tcfzjTRwLGV8pwMU+4R7A2sA 8yEw==
X-Gm-Message-State: AOJu0Yxc9qpiMNi+fiQwa6dsFrypgLXVEkRddTMVm0dB4krE0G8fjp0B B/xNkpXinOxukQ2QZA7uKAGSyUizMxJOt+kf2/+zA1d4a2NQmBOpBS3cfqhWOR2rBZPiezCLaKh +ZYM=
X-Google-Smtp-Source: AGHT+IGD1Ar57SZbDQQkI6qzUI6sla0T0ZpHY3TwYhXRimSe3vSk6+qPqwZixKu9fiRDpN8z4erf/w==
X-Received: by 2002:a05:651c:507:b0:2d2:f5fa:f37e with SMTP id o7-20020a05651c050700b002d2f5faf37emr217867ljp.51.1709162292765; Wed, 28 Feb 2024 15:18:12 -0800 (PST)
Received: from [127.0.0.1] (aftr-62-216-209-127.dynamic.mnet-online.de. [62.216.209.127]) by smtp.gmail.com with ESMTPSA id d15-20020a5d644f000000b0033e052be14fsm36756wrw.98.2024.02.28.15.18.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Feb 2024 15:18:12 -0800 (PST)
Date: Thu, 29 Feb 2024 00:18:12 +0100
From: Marius Kleidl <marius@transloadit.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Cc: media-types@iana.org
Message-ID: <dea59dfb-14f2-497e-bbec-ad716c6f1718@transloadit.com>
In-Reply-To: <522a9eed-3422-4a35-b001-0e5371e08e68@it.aoyama.ac.jp>
References: <CANY19Nuq1NROzfOytcVJFBMN5cSisPzt_YH6NxRRinjwLg1rkg@mail.gmail.com> <522a9eed-3422-4a35-b001-0e5371e08e68@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5_99432013.1709162292570"
X-Correlation-ID: <dea59dfb-14f2-497e-bbec-ad716c6f1718@transloadit.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/viaoPLYdBKxEmmDw17n1boLYRRg>
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 23:18:38 -0000

Hello Martin,

thanks for your response. Yes, the type parameter would not be necessary for this use case as the initial request for creating the upload resource can convey the file's media type using the Content-Type header field. Therefore, we don't have to repeat it afterwards when resuming the upload.

Best regards,
Marius Kleidl

28 feb 2024 1:19:33 Martin J. Dürst <duerst@it.aoyama.ac.jp>:

> Hello Marius,
> 
> Your proposal seems to make sense. Looking at the application/vnd.adobe.partial-upload, I'd suggest that you use only one parameter for the final type, rather than what they have (e.g. final_type=video, final_subtype=mp4). But I'm not even sure such a parameter is needed, because the partiality is purely in terms of a bit range if I understand correctly.
> 
> Regards,   Martin.
> 
> 
> On 2024-02-27 04: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/).
>> 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),
>> 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