Subject: [apps-discuss] 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

---

From: Jan Kundrát <[email-masked]>
Date: Mon, 29 Sep 2014 21:37:59 +0200

>    - application/vnd.software602.filler.form-xml-zip

Be careful here -- the ZIP encoding of these is just an implementation 
detail. Bundling them under the proposed archive/* makes as much sense as 
doing this for the ODT documents -- they, too, happen to use ZIP for 
storing their XML bits.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Sep 2014 13:39:38 -0700

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

[...]

I see a few expressions of support for this and no objections.

Is there a draft APPSAWG should be thinking about adopting here?  Does
anyone disagree that this fits within our charter?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Mon, 29 Sep 2014 13:47:34 -0700 (PDT)

> doing this for the ODT documents -- they, too, happen to use ZIP for

Absolutely. application/zip should be/have been archive/zip, an application
format that happens to employ zip at some level does not.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Sep 2014 14:10:12 -0700

> format that happens to employ zip at some level does not.

Color me confused.

There is a wide -- possibly infinite -- range of interesting,
context-specific domain semantics that we might choose to class as
"top-level".

After all these years, what makes 'archive' appropriate for special
handling and others not?

In other words, if we do want to go down this path, I suggest we do it
with an enhanced meta-model of what top-level is about and be prepared
to welcome many more additions.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Sep 2014 14:21:03 -0700

+1

Yes, that is my understanding as well.

If someone wished to define a file archiving format in XML as the structuring language (to separate files and metadata), it could be archive/format+xml; similarly if someone wished to define a file archiving format in the newly-minted CBOR [RFC7049], it could be archive/format+cbor.

In the case of application types like Word documents (application/vnd.openxmlformats-officedocument.wordprocessingml.document), it is not desirable for a system that does not understand that specific format to do “archive-like behavior” with it (i.e., show the user the ZIP file contents). It’s better to save it to the local filesystem as one stream of bytes.

Whether “archive-like behavior” is desirable depends on the media type registrant’s intent, which is not really for us to judge. Some use cases of ODT/Word documents will use a ZIP parser to manage them..but those parsers are used in the context of manipulating the ZIP archives in “that sort of way” (not as a general-purpose archive, but according to some specific format or protocol requirement).

Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 29 Sep 2014 14:26:41 -0700

On Sep 29, 2014, at 1:39 PM, Murray S. Kucherawy <[email-masked]> wrote:

> I would like to propose that the IETF create a new top-level media type: archive.
> 
> [...]
> 
> Is there a draft APPSAWG should be thinking about adopting here?  Does anyone disagree that this fits within our charter?

I think this work definitely fits within the Application area. However, I am not sure if it should be cabined to APPSAWG. It may be wise to form a new working group.

If this is something that the IETF is going to pursue, there are questions as to its scope. I requested that the Area Directors approve a BoF for IETF 91. I will respond to this in detail on the APPSAWG IETF 91 scheduling thread.

Best regards,

Sean

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 30 Sep 2014 11:51:10 +0900

I don't think we need a WG for this, and we also don't need a BOF. 
Before I support adoption in the appsa WG, I'd like to see an initial 
draft. It shouldn't be too difficult, the draft that introduces 'model' 
as a top-level type is 13 pages overall (see 
http://tools.ietf.org/html/rfc2077).

Regards,   Martin.

P.S.: At one point in time (~5 years ago), I started trying to write a 
draft for a font/ top-level mime type. I abandoned it because except for 
"doing things right", there was not much practical motivation. Given 
that there haven't been too many problems until now with application/zip 
and friends, I'd assume that anybody who wants to write a draft for 
archive/ will have to have a very strong internal motivation for "doing 
things right". My strong guess is that such a thing might work in the 
appsa WG, but keeping a separate WG alive on such motivation isn't going 
to work.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Sep 2014 22:10:59 -0700

On Mon, Sep 29, 2014 at 7:51 PM, "Martin J. Dürst" <[email-masked]>
wrote:

> I don't think we need a WG for this, and we also don't need a BOF. Before
> I support adoption in the appsa WG, I'd like to see an initial draft. It
> shouldn't be too difficult, the draft that introduces 'model' as a
> top-level type is 13 pages overall (see http://tools.ietf.org/html/rfc2077
> ).
>

That's pretty much a necessary step for each of the two paths anyway.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Mon, 29 Sep 2014 23:40:24 -0700 (PDT)

> context-specific domain semantics that we might choose to class as

Really? In the past ~25 years, I'm aware of exactly three serious proposals to
create a new top-level type: Model, font, and now archive. (There have been a
few others, e.g., iso for ISO-specified formats, but they did not meet the
basic criteria for top-level types.)

> After all these years, what makes 'archive' appropriate for special

Perhaps the fact that it makes sense as a top-level type in essentially
the same way as multipart and message do has something to do with it.

The better question is why, after all these years, does defining archive now
make sense. The answer is: There used to be a strong reluctance to register
media types for archive formats. But the use of media types has expanded and
our model for how they are used has changed, and what didn't make sense then
makes sense now. And the registration of these types, which taken as a group
have semantics similar to multipart and message, means it also makes sense for
them to have a top-level type.

> to welcome many more additions.

Sounds like a hell of a lot of work to handle a process that seems to run about
once every 8 years, and which already has a requirement of a standards-track
RFC attached.

I suggest we wait until the glut of proposals you seem to be anticipating
actually materializes before we undertake such a project.

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 30 Sep 2014 09:44:09 +0200 (CEST)

> actually materializes before we undertake such a project.

+1 !

> 				Ned

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Sep 2014 09:40:59 -0700

> basic criteria for top-level types.)

My memory is often terrible, of course, but I had the impression that:

   a) We've previously been rather resistant to proposals; this sets a
tone that discourages proposals, and certainly the long history of not
adding top-level types establishes a de facto sense of barrier

   b) On the average, making additions to the top of an infrastructure
hierarchy that hasn't been getting changed for some decades disrupts the
support infrastructure.  I'll bet folk can think of a very recent
(current) IETF-related example...

> media types for archive formats. 

Again, I had the impression that the reluctance was broader and deeper.

> once every 8 years, and which already has a requirement of a standards-track

Well, yeah.  That's one way to keep the barrier fairly high, in
pragmatic terms, if not formal ones.

I'll stress that I'm not saying that I think that we /should/ resist new
top-level types, like this one, merely that as a practical matter, we
have.

Further I'm saying that the fact of that history means adding a new
top-level type at this point should be treated as a strategic change to
an important infrastructure mechanism.

If we want it to succeed...

d/

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Sep 2014 22:55:24 -0700 (PDT)

> adding top-level types establishes a de facto sense of barrier

AFAIK the only proposals we've been resistant to have been ones that
clearly didn't make sense.

> (current) IETF-related example...

I have considerable familiarity with the support infrastructure in this
particular case, and I can think of exactly one case where's there's an
inherent problem adding top-level types: SDP. But in this case the bigger
problem would be what an archive type means in the context of SDP, not how to
represent it.

> Again, I had the impression that the reluctance was broader and deeper.

Suppose that's true. Why does it matter? The issue at hand isn't the
registration of archive formats as media types. That's a done deal.

> an important infrastructure mechanism.

Whereas I think the history says something else entirely.

				Ned