Subject: [media-types] A proposal for a new top-level media type: archive

From: Sean Leonard <[email-masked]>
Date: Wed, 24 Sep 2014 16:23:21 -0700

Colleagues on media-types and apps-discuss:

I would like to propose that the IETF create a new top-level media type: 
archive.

Basically, archive would be a top-level type for all types of archive 
formats.
https://en.wikipedia.org/wiki/Archive_file
https://en.wikipedia.org/wiki/List_of_archive_formats

I think it's important to register archive formats as a distinct type 
from application, because there are common semantics that apply. In 
fact, these semantics are very similar to multipart and message 
top-level types.

The archive data types are all storage formats for *files*, as opposed 
to *content*. Each file has its own security implications, along with 
metadata that also has security implications (user and group 
permissions, access bits, executable bits, ACLs). At the highest level, 
an Internet-connected application ought to be able to identify that a 
particular piece of content is of this type (as opposed to the opaque 
application type), so it can make decisions about the content that are 
unique to archives, namely, dealing with the security issues, and 
presenting uniform user interfaces to handling such archives. Content 
bundling types like message (RFC 5322), multipart, and application/cms 
(CMS) are conceptually distinct. All those types can contain content 
that can get split off into files, but their purpose is not to replicate 
file system data.

Archives are ubiquitous on the Internet. Even if archives are used 
"infrequently" across the Internet architecture, they are obviously used 
at the endpoints. Improper transmission of archives has become a major 
source of labeling and security issues.

Remarkably, most archive formats have not been registered as media types 
(except for application/zip, which is an oldie). Therefore, it's pretty 
much a "clean field". Furthermore, there is a trend of a lot of widely 
available tools to support multiple formats, so the probability is good 
that if you pass some archive/* labeled content to an archive 
application, it will be able to do something intelligent with it.

The following major sub-types of archives, all belong in a common 
top-level media type: [from Wikipedia]
* archiving only (concatenate files): tar
*  multi-function (concatenate, compress, encrypt, etc.): zip, rar, 7z, 
arc, arj, the list goes on and on...
* software packaging: cab, msi, pup, pet, apk, rpm...
* disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual 
floppy disks, formerly-known-as-TrueCrypt, etc.
* backup: (a large quantity of proprietary formats)

I know that the TLMT matter has been brought up before with fonts. 
<http://www6.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html>

Where do we start? Maybe we should talk about it? I don't think it's as 
simple as drafting an Internet-Draft. Maybe there should be a BOF or 
working group. Experts with file system and archival experience should 
get involved.

Sean

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 25 Sep 2014 12:31:42 +1000

> I would like to propose that the IETF create a new top-level media type:
Colour me interested.

>
> I think it's important to register archive formats as a distinct type from
> application, because there are common semantics that apply.
>
>
+1

> "infrequently" across the Internet architecture, they are obviously used at
> the endpoints. Improper transmission of archives has become a major source
> of labeling and security issues.
> ​
> ​
>
>
Archives (of the single-file variety) are used a lot, but we usually call
it Content-Encoding. However I digress; I can see there being a value in
knowing the difference between a tarball and an ISO, instead of having my
browser guess which handler to launch based on the final characters of the
URL, or the first *n* bytes of the file.

> ​
> ​

​
> that if you pass some archive/* labeled content to an archive application,
> it will be able to do something intelligent with it.
> ​
> ​
>
>
​Actually there's a pretty decent list, pulled from a quick scan:

   - application/zip
   - application/gzip
   - application/zlib​
   - application/vnd.dece-zip
   - application/vnd.easykaraoke.cdgdownload
   - application/vnd.google-earth.kmz
   - application/vnd.ms-cab-compressed
   - application/vnd.osgi.bundle
   - application/vnd.software602.filler.form-xml-zip

... and probably countless others. Some of them are closer to
content-encodings than archives per se, and a good many are just zip files
with a different extension, but they're still archives. And yes, I agree,
if they were all "archive/*" instead of "application," I could probably
pass them all to 7zip or winrar without a second thought.

> ​
> ​

> working group. Experts with file system and archival experience should get
> involved.
>
>
​I think this conversation already the start. The immediate questions I
have, and my instinctive reactions (without having put any thought at all
into it), are:

   1. How much value is there in distinguishing tarball from an ISO image
   from ... (as opposed to bundling them all under application/octet-stream)
   -- my feeling is: quite a bit
   2. How much value is there in grouping archives together in one
   registry, away from other application/* types
   -- again, I think: probably a fair bit
   3. ​How does this relate to content-encoding, if at all?
   -- a HTTP resource with Content-Type:archive/tar|Content-Encoding:gzip
   is a different beast from a Content-Type:application/gzip, so they can
   probably play together just fine.

The real meaty starting point, though, would be to register a type (or
types) in the new registry. No point setting it up with nothing in. Was
there one in particular you wanted to see added?

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

On 25 September 2014 09:23, Sean Leonard <[email-masked]> wrote:

> I think it's important to register archive formats as a distinct type from
> application, because there are common semantics that apply. In fact, these
> semantics are very similar to multipart and message top-level types.
>
> The archive data types are all storage formats for *files*, as opposed to
> *content*. Each file has its own security implications, along with metadata
> that also has security implications (user and group permissions, access
> bits, executable bits, ACLs). At the highest level, an Internet-connected
> application ought to be able to identify that a particular piece of content
> is of this type (as opposed to the opaque application type), so it can make
> decisions about the content that are unique to archives, namely, dealing
> with the security issues, and presenting uniform user interfaces to
> handling such archives. Content bundling types like message (RFC 5322),
> multipart, and application/cms (CMS) are conceptually distinct. All those
> types can contain content that can get split off into files, but their
> purpose is not to replicate file system data.
>
> "infrequently" across the Internet architecture, they are obviously used at
> the endpoints. Improper transmission of archives has become a major source
> of labeling and security issues.
>
> that if you pass some archive/* labeled content to an archive application,
> it will be able to do something intelligent with it.
>
> * disk image: ISO-9660 (CD/DVD/Blu-Ray), Apple Disk Image, virtual floppy
> disks, formerly-known-as-TrueCrypt, etc.
> I know that the TLMT matter has been brought up before with fonts. <
> http://www6.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html>
>
> working group. Experts with file system and archival experience should get
> involved.
>
> Sean
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Sep 2014 19:38:06 -0700 (PDT)

> > I would like to propose that the IETF create a new top-level media type:

Yeah, me too. I'm surpised nobody has suggested this before.

				Ned

---

From: Ira McDonald <[email-masked]>
Date: Wed, 24 Sep 2014 22:48:06 -0400

Hi,

+1

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434