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

Marius Kleidl <marius@transloadit.com> Mon, 26 February 2024 19:02 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 53D2DC151981 for <media-types@ietfa.amsl.com>; Mon, 26 Feb 2024 11:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Level:
X-Spam-Status: No, score=-4.405 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_FAIL=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
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 jRXXE_V3if2S for <media-types@ietfa.amsl.com>; Mon, 26 Feb 2024 11:01:57 -0800 (PST)
Received: from pechora4.lax.icann.org (pechora4.icann.org [192.0.33.74]) (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 1D670C151539 for <media-types@ietf.org>; Mon, 26 Feb 2024 11:01:57 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 pechora4.lax.icann.org (Postfix) with ESMTPS id 9864970000F0 for <media-types@iana.org>; Mon, 26 Feb 2024 19:01:56 +0000 (UTC)
Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3392b12dd21so2872979f8f.0 for <media-types@iana.org>; Mon, 26 Feb 2024 11:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transloadit.com; s=google; t=1708974095; x=1709578895; darn=iana.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=npn0Qvgb765xIuhGr1dfRf/lXCbobOscPK278Fsgu7A=; b=E8eV3Zs1YCdv1zo5t9eB9SovwXlu6DYrL8v431TjGxFgTOIefI3sWCXxqhe/38uodC Syd4hFdBkyBN2H6+ehv3NnOspd1lnuH0P7l2xh/JyqHunV65lrQ5dGU4MAWX+bpw2Y1T So4eID4pq5Ww8r7zlNvN3rmsuJmIXhoSpR+CM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708974095; x=1709578895; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=npn0Qvgb765xIuhGr1dfRf/lXCbobOscPK278Fsgu7A=; b=U/Cz0Z4x2eMM7Qn7sv33wiCdNYkqRWQshUDl/blJQCO4/JUDhHRIWyOIa3GrZt8toq WW9BVtXIBtE2g1uP3pnziinewoe0033K4HyXEmz4kjoYLI6E/bQkQJIKoQZgkGmWKQqr fWapAG/+YX1XELLSSvxxm6GQoinyT9QzShkCUu3DqOrUP2Iy6oo5BoCrWGXniYm9DBfZ KlTDibGUTQOB4c71swj6T88ApkOD0JR6daC9HDuKwgF9If/PKdWXwFAugWLKS6Z7NuMc sH5SRMyKGBW7Uua/s13ozuSoHbHvNiQjnwzWjyi10+dUOjt6lMbw/kn995UgEFD4VKSC IziQ==
X-Gm-Message-State: AOJu0YwSktFt6qePrr2nn81io/nDq/H9NevFHPkTdhVhO8FezaczbyeD ZO6s51T5GsQwH+aptEhPiNP9LNlPD4gER8iQxAtzq/dPXY/tn1FWvYLgKr79GoKdD4fLDxWpbyV +0nGnDDLwdJrQnDJ++eckByiYqlQspq/F+DdmSkC8gQo7aVBh0wc=
X-Google-Smtp-Source: AGHT+IEcSgEV3x9uHi4A5Mywkx/iou/xpNROn8GKsWKrCd/3E2We7RaPzkSlt/wK9cEGDHmr9QnWgQNeE+gac9CsKG0=
X-Received: by 2002:a5d:5387:0:b0:33d:2d2c:f404 with SMTP id d7-20020a5d5387000000b0033d2d2cf404mr5768479wrv.15.1708974094668; Mon, 26 Feb 2024 11:01:34 -0800 (PST)
MIME-Version: 1.0
From: Marius Kleidl <marius@transloadit.com>
Date: Mon, 26 Feb 2024 20:01:23 +0100
Message-ID: <CANY19Nuq1NROzfOytcVJFBMN5cSisPzt_YH6NxRRinjwLg1rkg@mail.gmail.com>
To: media-types@iana.org
Content-Type: multipart/alternative; boundary="000000000000d7f28d06124d89a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/XoF-_vBDWWS4KjLFjLlrbnuO8bw>
Subject: [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: Mon, 26 Feb 2024 19:02:01 -0000

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