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

Mark Nottingham <mnot@mnot.net> Thu, 07 March 2024 22:08 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 115EDC14F69B for <media-types@ietfa.amsl.com>; Thu, 7 Mar 2024 14:08:51 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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_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="fEoNN9wP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="IZtiI9ZF"
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 noMhfnGTRxVn for <media-types@ietfa.amsl.com>; Thu, 7 Mar 2024 14:08:46 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 F2F25C14F696 for <media-types@ietf.org>; Thu, 7 Mar 2024 14:08:45 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0C1865C00A4; Thu, 7 Mar 2024 17:08:45 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 07 Mar 2024 17:08:45 -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=1709849325; x=1709935725; bh=feKn9wWctclXYaPdevJHUyokutfShLGxq7oPF/wBsNI=; b= fEoNN9wPwUBHA5YCeUl75xbKQgd21WPQzx3UnsEpNeGzoSGogxpc/M8phkfNKKXv c0/18Wk6LupkjFIe3gD+FwO/YQOOzZjfFkRjqc0XgHuHNCoTvW5snKB3OLpDhdSg qVMClb/z6iqKAVVdwH0nDHKPwO10WFuCyRl5CAUOvFCLxIl7i6HsWKJZyPzrp2WR GDSRM56J/IJw45LhODKf/wF9Y5kVj/yqW9uW0Ydunn66HGcrDcy2doVcSwB55mCO RRQx/nug3Ms3iBzxaVZ6bjsVhG2MRp2gAG5Cy3pCHE6MiD7l1QFd1wNUr91QzaBH eaA70ecTKbeIah6HuXPcag==
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=1709849325; x= 1709935725; bh=feKn9wWctclXYaPdevJHUyokutfShLGxq7oPF/wBsNI=; b=I ZtiI9ZF+WUaCjQ6GhiqZdxnTpZy1On5BZ1zldvE/A71ISnxmLiMm12rMHMCMt03V WCQY4GUzg0p0BPRm9DuWQB5ifJZjYqZTzvp2afDdJcTKQ7AOzKqq3xaoioic2jll zt0JgKG91I+/g4MUGA2Tkbw/gKp1dW5avxE83CKWl+krqQF7iTYN5VC6O0RozaA1 ZUPhgaxwC92WzjpH6EhX/g8paAyCqF0GiZuqJqZVjTmSfsHQupTSzd1+LEAvNvyG acPeeCWeoVYTDrfr0BT7v6pP+6BRbwT7YyaForbdyoE+7ifgM9rSlSvOL/ARt8bn aooDCqRqmQ6UqoF6h34Kw==
X-ME-Sender: <xms:7DrqZUOGAbFtayerK5JnbjSFKytpBIzARWllSqao38TLkNDJTJMB-Q> <xme:7DrqZa94AOTeYZ8Ow8LsMDdsxsBKdXItDJWP4WXsHAGUIweig3F4mWpShTaxCJA-4 mvx8wT9Ck0AtJypJw>
X-ME-Received: <xmr:7DrqZbT0VHvnbdo4gXk3-8_Q05t0IKFuVJSujv04CyPd4s3rKhvlAyxmNJRuKs81hrb4qQdxGwZr8M5dgcczg1ncS_6C5LiiCUoUDEcnIxKRyPmVymj7uprT>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrieefgdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepvddugfeihfeltddttefgvedvueehudehgfefveefjeeuvedutddvieelheek jedvnecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpihgvthhfrdhorhhgpd hirghnrgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:7DrqZctU2cm4H-iRBcxhpV62HpmUaTyfaNUpeImAwzjTiZ9eJUt-bA> <xmx:7DrqZcdAH6VgHxJ5KSZQfF31-5iOrWwPQD4P5GUOI7w0Tm6TP6am9Q> <xmx:7DrqZQ372yyD1no2vHn_7lovB6ByfCVh8sA7YCE0IK4u--l3mYL5Bw> <xmx:7TrqZYEOXHINhHA0b2FPfDPAOSWhzzwuiUIPKb7_wZo8_LQpAIrFhw>
Feedback-ID: ie6694242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Mar 2024 17:08:43 -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: <638d18d6-439e-44fd-a172-3f8dcde7a7c2@alvestrand.no>
Date: Fri, 08 Mar 2024 09:08:39 +1100
Cc: media-types@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <90312C2C-56C6-4D96-AC2E-91FC54980509@mnot.net>
References: <CANY19Nuq1NROzfOytcVJFBMN5cSisPzt_YH6NxRRinjwLg1rkg@mail.gmail.com> <939d9892-9512-4685-9476-3546529d372b@alvestrand.no> <216EA7D9-692D-4AA3-9C59-47EAB7B5EE22@mnot.net> <b1873ef8-8ccb-435a-9dab-df629314e88f@alvestrand.no> <3916F0BA-395F-4DD6-84EE-CFE147FA062C@mnot.net> <638d18d6-439e-44fd-a172-3f8dcde7a7c2@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/ZRPZvmxiu_882nekxsL1SMmoX-c>
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: Thu, 07 Mar 2024 22:08:51 -0000

E.g., RFC 6902, RFC 7351, RFC 7396, RFC 8072.


> On 8 Mar 2024, at 06:56, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 
> On 3/6/24 17:51, Mark Nottingham wrote:
>> Yes, it's used by many APIs, etc.
> 
> with a common spec? what types do they use?
> 
> the best thing for a new requirement is if we can just have documentation of something already common practice.
> 
> 
>> Cheers,
>> 
>> 
>>> On 7 Mar 2024, at 03:55, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> 
>>> 
>>> On 2/28/24 18:24, Mark Nottingham wrote:
>>>> 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
>>> sigh ... I was hoping that application/octet-stream with range: would suffice for the simple case :-(
>>> 
>>> Is there any current deployment of PATCH in the wild?
>>> 
>>>> 
>>>> 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/
>>>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 

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