Re: [media-types] [apps-discuss] A proposal for a new top-level media type: archive

On 25 September 2014 09:23, Sean Leonard <dev+ietf@seantek.com> wrote:

> Colleagues on media-types and apps-discuss:
>
> I would like to propose that the IETF create a new top-level media type:
> archive.
>
>
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

> 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.
> 
> 
>
>
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.

> 
> 

> 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.
> 
> 
>
>
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.

> 
> 

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.
>
>
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 <dev+ietf@seantek.com> wrote:

> 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
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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