[media-types] New toplevel type - extension

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 10 June 2022 16:21 UTC

Return-Path: <hallam@gmail.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 43EACC1594AF for <media-types@ietfa.amsl.com>; Fri, 10 Jun 2022 09:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.49
X-Spam-Level:
X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 O4sSuDezaKqH for <media-types@ietfa.amsl.com>; Fri, 10 Jun 2022 09:21:35 -0700 (PDT)
Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BF620C14F736 for <media-types@ietf.org>; Fri, 10 Jun 2022 09:21:35 -0700 (PDT)
Received: by mail-yb1-f172.google.com with SMTP id x38so1978865ybd.9 for <media-types@ietf.org>; Fri, 10 Jun 2022 09:21:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xrXfJ6Tk8HEQJnHVTI3vpA5YTQkyOB2YMhQj4FhsnG4=; b=bYP1PfRYNfM/ZeZf/efQu3tOIF/d3lTkmEbvQwgW0jjc/qKM9talOY/jcw83XuUEgU NDb28PxZAUWMzrZU9HPNKLZJo+kiyrhQkhjxllBXL9DanWqlaSjQSbaMnl4zaJb0r5u4 PY1OreWSqU1DoyM0PgfIoxSLvsA7MKS70TJ6pypLOtvqRWz6d9LpoPg0jleFhA4njzUn OTogzSevNsRphzMXAIP+48Pxsn+AvdJqOIVKFDiu9hbODyjiJUJHTrwmEsCvplE0Uzc0 r9Dcaaluyv72aXMtK47IuDCUIRqMuE/WEUqUUxB90tyGFwvMn4gYrjVFx7mfLhHFi2Z1 rvpg==
X-Gm-Message-State: AOAM530yXRVTR2+X1BUHqZkRlwxGgqPJL5P4Hv2zSBBNq7Paw9HExXGJ b4epJnTBLfFVQfWt2aUjIq0ZuhkEB63oGPjq9DIa9mv2lFo=
X-Google-Smtp-Source: ABdhPJzRsYzE2UtrZBTwCczmZh4jVuIflm+DaRay2iPreqZXLHnS2vCYwrD94MG57GHisOvnRkevhm6iouk+5ENdYc0=
X-Received: by 2002:a25:1f09:0:b0:663:3a8b:ac9b with SMTP id f9-20020a251f09000000b006633a8bac9bmr31744209ybf.78.1654878094698; Fri, 10 Jun 2022 09:21:34 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 10 Jun 2022 12:21:29 -0400
Message-ID: <CAMm+Lwh1vAC4HKmKbnHdb0dT-b0yZMAWwURiX5S7beJEg6F2iQ@mail.gmail.com>
To: media-types@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fb2e7f05e11a5493"
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/Yxdhwes2rV7s227dVwk66u-qKq4>
Subject: [media-types] New toplevel type - extension
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: Fri, 10 Jun 2022 16:21:36 -0000

I am not going to defend the aesthetics of this proposal. But it definitely
has utility.

The proposal is for a new toplevel type extension where the subtype is the
file extension used to announce the type to the operating system.

Yes, I know it is ugly. But it would be damned useful when writing an
archiving tool. At the moment, I have to record both the original file
extension and the inferred media type. And this results in a whole rack of
ambiguity and mess because having two ways to describe the same thing
inevitably results in ambiguity.

Consider the case that Alice saves her html document out to a DARE archive
from a html editor. In this case the content is definitely text/html.

But what happens when Alice zips a set of files on disk and the archive
tool infers the content types? Well obviously file.html is almost certainly
html but that is an inference and when the archive tool guesses the type of
less well known file types it can easily get it wrong.

So in the spirit of 'describe exactly what you know', extension/dcat seems
to be the way forward for when my archive tool detects a file of extension
.dcat.


Thoughts?

[The use case that brought this up is that I threw together a little Web
browser that can surf a Web site published as a set of static encrypted
files. So all the content is encrypted end to end.

If a threshold encryption scheme is used, the administrator of the group
can add and remove decryption rights from users without changing the
encrypted content or compromising the end-to-end encryption.

One consequence of this approach is that the media type to be reported to
the browser is only known after the browser attempts decryption. If Alice
attempts to read a file encrypted to a group she has not been read into,
she will see a HTML warning page telling her she is not allowed access.

Oh and my very ad hoc usability study strongly suggests that when a user is
surfing the Web and suddenly hits an Orange Page shouting TOP SECRET they
do actually take notice. But even if they don't the data is still
encrypted.]