From nobody Tue Sep 2 10:13:00 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB341A02CF for ; Tue, 2 Sep 2014 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJUJkDIsfzX1 for ; Tue, 2 Sep 2014 10:12:55 -0700 (PDT) Received: from nm20-vm7.bullet.mail.gq1.yahoo.com (nm20-vm7.bullet.mail.gq1.yahoo.com [98.136.217.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8051A0126 for ; Tue, 2 Sep 2014 10:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1409677974; bh=vdSbSXz+nyPBPjd0WGETPV9Fw+F6AJLpANjumQZ+hSs=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Content-Type:From:Subject; b=CgjhfLsxFO3qe7y9Bv7GVw7yrvTHbUEjzcj6URmPS88Ia6YBoVmJGuKA58EiD/V/wf25k3NtK4nq/HFeN8TGqODa/wpVnCVsEr5sQbfhwf8n3TtxjXXdxqPxN4IIOF8L2qEt4k4J96gP9y5HCVrNPZuH05obqZIB6hJGMecDqLrpRTtxBGdC1FpZwYU8LTxP25FvzJHNBpQoRnVWPPzDLdrRChkH4xDtHvj44ps9FFlj6mGNFY5hXKesxyO7XUs4/jAKyjASVLZrly712MCKJJ3x0tIeyi4PshX3z8ltnGztzn6RN6s7yPqMe8i2EdhYgACy+kvpZT7UkWgkK5JGaQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=B9ITk+Yjv2A08Pr9QpzE7N7PcCJD115ZMDhNt6Np0OfP2DCZzkXtrof8ZAC5QaBRzSJtuCDiDF2RqipFMO4pUwX8RxTgqfIKObgE6u4l11KvUI7RbktCrPFo3hGnQe1o77SiTAenG26XGdXG4Mnjdd/Eb8a3Y9856aSpdY+xdejarBVtI//fez3roSdNnvJdFokmc3z2BDLzCVpe0Ta8mJpCQG4UwuxS3nnJz930Gqr1Oi9r2/Uo5p0WivKHKdPYsoKHvhsn/wkOWzt48lUkSVOx9X0fu7Hw8S7rxvFpndIfSAk8MQignGxW1zahuSEet28b9OOcTLHEAZkGHf+Ozw==; Received: from [98.137.12.190] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 02 Sep 2014 17:12:54 -0000 Received: from [208.71.42.193] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 02 Sep 2014 17:12:54 -0000 Received: from [127.0.0.1] by smtp204.mail.gq1.yahoo.com with NNFMP; 02 Sep 2014 17:12:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1409677974; bh=vdSbSXz+nyPBPjd0WGETPV9Fw+F6AJLpANjumQZ+hSs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Content-Type; b=No3LYjhG78GF6tUXcmbaG3PH9l1lRgZufzY3iO7uJUZ1ui7LnB33yUFPeNX0KoW9RpKSlmWwgv399aWEi4xx8jZTGy7975ieuKRR18LOdQqWK3hmalcgKBkb7dnTMQHKhLH5iAfboomGzA3/vXe8xkZy+fPCYAKdunpXh6B3QUA= X-Yahoo-Newman-Id: 861452.44741.bm@smtp204.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4EY4neUVM1l9UNuMoFKVFH8oQAyLmr3PVGjv6gZYV2vvqsd il7jYso3e4kEoI7hJ15_M8HhgyJ7m3jDjw3t4G_esvuVCvfSI2GoM5_dlBw7 211W6gt3BNLKlgdJPQF1qje075lE2rHdrUYo_hI7H1JOON1xxFDms.E9BFlg G86Tq3PSX3vkbBvwv5MeQVIWCCGLSF5ZhbFBlKI7BUVxGiB8hYXiJxOjzWwf cQTBryaoyOka.G1b45ywS4Xb08ima.Pj05Jl4K3MlBJh2A6sn24Gr.ER6rHW lXw65SOPQ9hJXmxZ.BFehN4uD7xFs8qEBEIRygkFfQuBbx.dcZVblkGavC05 7hrrc9onMukUQpvnnXtsUpgh0WtJwkd21xXWO5lSarfJg6o45_FK1TPdrCSV pdOJsQzA1V2VAaepiUYMDemjgM.2m6drBIV5J9nCXx4LQGS0VbaPNWW1JO1T DWgwljynDfzOToSdZi.94BOPynNm.kPBnPVL5JbEemzG2_LxvvNnGvCPCoJb gd5OdcVrc.uLGtbUrL3SaMlI._G4R12LLoFm1iXRC9nQ.ImMmL2nlXQ7W7ly 1apLZrMkjnrGA2n676yyEuoTgkPEsn9Cw_oAP5roZS5Ue_XoyxR9ReayOqHo iwCkVRu8dWnXAtBYZfgirBwGOkuDqpTxoKm5WcsagxkNK6pAp9ojTo_nXPrM dCfkpbEcRcDjWiDIrbgxS2OWV5fZKKYulU6Tu09imMRHiNdsh5dAiLUWIRzY iC2O3b3VHfgKEoQ-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-lb0-f170.google.com with SMTP id w7so8019023lbi.1 for ; Tue, 02 Sep 2014 10:12:51 -0700 (PDT) X-Gm-Message-State: ALoCoQllXn+yM/VKmucvm7VjJ45MF9MqgI9PEYff+grknklatyiA28PGfuNuvlHL7zkaVv/rYdQd X-Received: by 10.152.28.67 with SMTP id z3mr37134959lag.12.1409677971728; Tue, 02 Sep 2014 10:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.154.195 with HTTP; Tue, 2 Sep 2014 10:12:31 -0700 (PDT) In-Reply-To: <20140902165654.25921.23070.idtracker@ietfa.amsl.com> References: <20140902165654.25921.23070.idtracker@ietfa.amsl.com> From: mike amundsen Date: Tue, 2 Sep 2014 13:12:31 -0400 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=089e0158c8d4c0c1f00502183a5f Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/tIpxTottoTc7wtRUHy_NoaAgLQA Subject: [media-types] Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-00.txt X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:12:58 -0000 --089e0158c8d4c0c1f00502183a5f Content-Type: text/plain; charset=UTF-8 Greetings: I've started an I-D for the ALPS (Application-Level Profile Semantics) media type (see below). This is an early draft and we're looking forward to feedback and suggestions. Cheers. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund ---------- Forwarded message ---------- From: Date: Tue, Sep 2, 2014 at 12:56 PM Subject: New Version Notification for draft-amundsen-richardson-foster-alps-00.txt To: Mike Amundsen , Leonard Richardson < leonardr@segfault.org>, "Mark W. Foster" A new version of I-D, draft-amundsen-richardson-foster-alps-00.txt has been successfully submitted by Mike Amundsen and posted to the IETF repository. Name: draft-amundsen-richardson-foster-alps Revision: 00 Title: Application-Level Profile Semantics (ALPS) Document date: 2014-09-02 Group: Individual Submission Pages: 27 URL: http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-00.txt Status: https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/ Htmlized: http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-00 Abstract: This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application- agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Media-Types mailing list (see [1]). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e0158c8d4c0c1f00502183a5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings:

I&#= 39;ve started an I-D for the ALPS (Application-Level Profile Semantics) med= ia type (see below).

This is an early draft= and we're looking forward to feedback and suggestions.

Cheers= .




---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: Tue, Sep 2, 2014 at 12:56 PM
Subject: New Version Notification for= draft-amundsen-richardson-foster-alps-00.txt
To: Mike Amundsen <mca@amundsen.com>, Leonard Richardso= n <leonardr@segfault.org>= ;, "Mark W. Foster" <mwf@fo= srias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-00.txt
has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-amundsen-richardson-fos= ter-alps
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Level Profile Semantic= s (ALPS)
Document date:=C2=A0 2014-09-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster= -alps-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.iet= f.org/html/draft-amundsen-richardson-foster-alps-00


Abstract:
=C2=A0 =C2=A0This document describes ALPS, a data format for defining simpl= e
=C2=A0 =C2=A0descriptions of application-level semantics, similar in comple= xity to
=C2=A0 =C2=A0HTML microformats.=C2=A0 An ALPS document can be used as a pro= file to
=C2=A0 =C2=A0explain the application semantics of a document with an applic= ation-
=C2=A0 =C2=A0agnostic media type (such as HTML, HAL, Collection+JSON, Siren= ,
=C2=A0 =C2=A0etc.).=C2=A0 This increases the reusability of profile documen= ts across
=C2=A0 =C2=A0media types.

Editorial Note (To be removed by RFC Editor)

=C2=A0 =C2=A0Distribution of this document is unlimited.=C2=A0 Comments sho= uld be sent
=C2=A0 =C2=A0to the IETF Media-Types mailing list (see [1]).




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e0158c8d4c0c1f00502183a5f-- From nobody Wed Sep 10 21:05:08 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1F31A0389 for ; Wed, 10 Sep 2014 21:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGch3vZJV-_v for ; Wed, 10 Sep 2014 21:05:01 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543821A0348 for ; Wed, 10 Sep 2014 21:05:01 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8B44eKr028826 for ; Thu, 11 Sep 2014 04:05:01 GMT Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in1.mxes.net (Postfix) with ESMTP id F381A2FDD50 for ; Wed, 10 Sep 2014 23:48:24 -0400 (EDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7C796509B6 for ; Wed, 10 Sep 2014 23:47:43 -0400 (EDT) Message-ID: <54111B72.70307@seantek.com> Date: Wed, 10 Sep 2014 20:48:02 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: media-types@iana.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Delayed for 00:16:14 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Thu, 11 Sep 2014 04:05:01 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/peUHcp4VnMxN35w0ikAimsPt8mU Subject: [media-types] Standardizing on application/tar for tar files X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 04:05:05 -0000 Hello, Suppose that it is desirable to standardize on application/tar for .tar=20 files . Tar is standardized in POSIX.1-2001, which is both IEEE 1003 and ISO/IEC = 9945. The standard description in the pax topic=20 is=20 complete. However, there is no IANA registration template in POSIX. What is the recommended way to register this media type, if I wanted to=20 just go ahead and do it with a minimum of fuss (but maximizing quality=20 of the registration)? Thanks, Sean From nobody Thu Sep 11 02:25:13 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8F81A8914 for ; Thu, 11 Sep 2014 02:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkgoZXmnPg-9 for ; Thu, 11 Sep 2014 02:25:09 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26C71A8912 for ; Thu, 11 Sep 2014 02:25:08 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8B9OlWi014843 for ; Thu, 11 Sep 2014 09:25:07 GMT Received: from [192.168.1.64] (78.72.130.23) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u57601879) id 540853EF003148F5; Thu, 11 Sep 2014 11:13:39 +0200 Message-ID: <541167BE.1050601@henke37.cjb.net> Date: Thu, 11 Sep 2014 11:13:34 +0200 From: Henrik Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Sean Leonard , media-types@iana.org References: <54111B72.70307@seantek.com> In-Reply-To: <54111B72.70307@seantek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:11:07 by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Thu, 11 Sep 2014 09:25:08 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/eSMzQRSXZ6SvkBOKXWbfqNOe7uc Subject: Re: [media-types] Standardizing on application/tar for tar files X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 09:25:10 -0000 Sean Leonard skrev: > Hello, > > Suppose that it is desirable to standardize on application/tar for > .tar files . > > Tar is standardized in POSIX.1-2001, which is both IEEE 1003 and > ISO/IEC 9945. The standard description in the pax topic > > is complete. However, there is no IANA registration template in POSIX. > > What is the recommended way to register this media type, if I wanted > to just go ahead and do it with a minimum of fuss (but maximizing > quality of the registration)? > > Thanks, > > Sean > I'd like to note that compressed tarballs should be using the Content-Encoding HTTP header[1] in addition to the proposed application/tar mime type. [1] http://tools.ietf.org/html/rfc7231#section-3.1.2.2 From nobody Fri Sep 19 11:23:26 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC88A1A064D for ; Fri, 19 Sep 2014 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2sQ36Qj7Kk6 for ; Fri, 19 Sep 2014 11:23:15 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD8D1A015F for ; Fri, 19 Sep 2014 11:23:14 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8JIMrP6013650 for ; Fri, 19 Sep 2014 18:23:13 GMT Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 74591509B5; Fri, 19 Sep 2014 14:22:51 -0400 (EDT) Message-ID: <541C7482.8040308@seantek.com> Date: Fri, 19 Sep 2014 11:22:58 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Delayed for 206:35:09 by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Fri, 19 Sep 2014 18:23:13 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/2qd6kOykO0cab6PrCyoKsu1J76o Cc: ogdirector-platform@opengroup.org Subject: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:23:19 -0000 To Media Types reviewers: This is a first draft of a registration request for the Internet media ty= pe application/tar, for tar format archives. Per RFC 6838, I do not believe that this registration requires a formal R= FC since it is from a recognized standards organization (IEEE). Neverthel= ess, it deserves review and discussion prior to the formal request being = lodged. Feedback is appreciated. Registration Template [DRAFT] Type name: application Subtype name: tar Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: TAR (Tape ARchive), as an archive format, can contain arbitrary files of arbitrary types, including files that are not considered "regular files" = (e.g., symbolic links, directories). Some of these files may be executabl= e or contain executable data, including scripts, that could compromise the security of a computer. Addi= tionally, some files may contain directives such as URIs that, when acces= sed, can compromise privacy. As POSIX file system information can be recorded in this format, user and group permissions, dates, and the like can also be overwritten when the data is extracted. F= urthermore, when encoding data in this format, personal data such as user= and group permissions from a source computer system can be surreptitiously included in the format as a method of exfiltrating that d= ata. The format permits extensions ("pax extensions")--these extensions m= ay have their own security risks. Interoperability considerations: TAR is a widely-recognized archive format on all modern computer systems,= especially those relating to UNIX and the POSIX standards. The format ha= s undergone several iterations; the main current variations are "pax" and= "ustar", which are compatible with each other. Published specification: POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for Info= rmation Technology - Portable Operating System Interface (POSIX)" Shell a= nd Utilities - pax - EXTENDED DESCRIPTION - pax Interchange Format, ustar= Interchange Format http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html Applications that use this media type: pax is the POSIX utility. Most UNIX-compatible implementations also inclu= de a utility called tar. Most software archiving programs of any notoriety process this format; im= plementations are too numerous to list. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): hex: 75 73 74 61 72 00 30 30, aka US-ASCII: u s t a r NUL 0 0, at octet 257 File extension(s): tar Macintosh file type code(s): N/A Person & email address to contact for further information: Sean Leonard Andrew Josey Intended usage: COMMON Restrictions on usage: None. Author: The Austin Common Standards Revision Group (CSRG) The Institute of Electrical and Electronics Engineers (IEEE) The Open Group Change controller: CSRG Provisional registration? (standards tree only): No From nobody Sun Sep 21 19:37:38 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8621A19FA for ; Sun, 21 Sep 2014 19:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Frv6x7vMmW for ; Sun, 21 Sep 2014 19:37:35 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0191A19F4 for ; Sun, 21 Sep 2014 19:37:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8M2bC0i023717 for ; Mon, 22 Sep 2014 02:37:32 GMT Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AEC25509B8; Sun, 21 Sep 2014 22:37:10 -0400 (EDT) Message-ID: <541F8B4B.4090001@seantek.com> Date: Sun, 21 Sep 2014 19:36:59 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org References: <541C7482.8040308@seantek.com> <541D0FD0.40700@it.aoyama.ac.jp> In-Reply-To: <541D0FD0.40700@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 22 Sep 2014 02:37:32 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/E0zv-L4em6jrQrkmU_ONIk2a0B0 Cc: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 02:37:37 -0000 On 9/19/2014 10:25 PM, "Martin J. Dürst" wrote: > On 2014/09/20 03:22, Sean Leonard wrote: >> To Media Types reviewers: >> >> This is a first draft of a registration request for the Internet media >> type application/tar, for tar format archives. > >> Registration Template [DRAFT] >> >> Type name: application >> >> Subtype name: tar >> >> Required parameters: N/A >> >> Optional parameters: N/A > > I think these should be "None", because N/A suggests "don't know" > > Regards, Martin. Ok. Draft 2: Registration Template [DRAFT] Type name: application Subtype name: tar Required parameters: None. Optional parameters: None. Encoding considerations: binary Security considerations: TAR (Tape ARchive), as an archive format, can contain arbitrary files of arbitrary types, including files that are not considered "regular files" (e.g., symbolic links, directories). Some of these files may be executable or contain executable data, including scripts, that could compromise the security of a computer. Additionally, some files may contain directives such as URIs that, when accessed, can compromise privacy. As POSIX file system information can be recorded in this format, user and group permissions, dates, and the like can also be overwritten when the data is extracted. Furthermore, when encoding data in this format, personal data such as user and group permissions from a source computer system can be surreptitiously included in the format as a method of exfiltrating that data. The format permits extensions ("pax extensions")--these extensions may have their own security risks. Interoperability considerations: TAR is a widely-recognized archive format on all modern computer systems, especially those relating to UNIX and the POSIX standards. The format has undergone several iterations; the main current variations are "pax" and "ustar", which are compatible with each other. Published specification: POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for Information Technology - Portable Operating System Interface (POSIX)" Shell and Utilities - pax - EXTENDED DESCRIPTION - pax Interchange Format, ustar Interchange Format http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html Applications that use this media type: pax is the POSIX utility. Most UNIX-compatible implementations also include a utility called tar. Most software archiving programs of any notoriety process this format; implementations are too numerous to list. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): hex: 75 73 74 61 72 00 30 30, aka US-ASCII: u s t a r NUL 0 0, at octet 257 File extension(s): tar Macintosh file type code(s): N/A Person & email address to contact for further information: Sean Leonard Andrew Josey Intended usage: COMMON Restrictions on usage: None. Author: The Austin Common Standards Revision Group (CSRG) The Institute of Electrical and Electronics Engineers (IEEE) The Open Group Change controller: CSRG Provisional registration? (standards tree only): No From nobody Sun Sep 21 19:43:51 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6621A19FC for ; Sun, 21 Sep 2014 19:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faxUyl2hkenx for ; Sun, 21 Sep 2014 19:43:49 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3CD1A030A for ; Sun, 21 Sep 2014 19:43:48 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8M2hRL6004252 for ; Mon, 22 Sep 2014 02:43:47 GMT Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C0A4450A84 for ; Sun, 21 Sep 2014 22:43:26 -0400 (EDT) Message-ID: <541F8CC4.1000809@seantek.com> Date: Sun, 21 Sep 2014 19:43:16 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 22 Sep 2014 02:43:47 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/ozkIK8C1YLK3bWfrVXS1gNXZetM Subject: [media-types] Can we please bring media type registrations into the 21st century--Mac File Type codes X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 02:43:50 -0000 While looking over the registrations, I noticed that it is required to provide Mac OS File Type codes. That is all well and good, but Mac OS File Type codes are so 1993. I mean, literally **1993**. Mac OS X has been using Uniform Type Identifiers since 2001. How do people feel about updating the registration template to include Apple Uniform Type Identifiers, and hopefully also to remove Mac File Type codes? Thanks, Sean From nobody Sun Sep 21 19:48:49 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3BC1A19FC for ; Sun, 21 Sep 2014 19:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twy-BmNOqpBK for ; Sun, 21 Sep 2014 19:48:45 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DAA1A1A02 for ; Sun, 21 Sep 2014 19:48:45 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8M2mORV024189 for ; Mon, 22 Sep 2014 02:48:44 GMT Received: from localhost ([127.0.0.1] helo=slave.barefootcomputing.com) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XVtfp-00082k-Pa; Sun, 21 Sep 2014 22:48:21 -0400 Date: Sun, 21 Sep 2014 22:48:20 -0400 From: Liam R E Quin To: Sean Leonard Message-ID: <20140921224820.23220df5.liam@w3.org> In-Reply-To: <541F8B4B.4090001@seantek.com> References: <541C7482.8040308@seantek.com> <541D0FD0.40700@it.aoyama.ac.jp> <541F8B4B.4090001@seantek.com> Organization: W3C X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 22 Sep 2014 02:48:45 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/lX9g91qNdWzsJrq4FFwCxONQLcM Cc: media-types@iana.org, ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 02:48:47 -0000 On Sun, 21 Sep 2014 19:36:59 -0700 Sean Leonard wrote: [...] > Security considerations: > TAR (Tape ARchive), as an archive format, can contain arbitrary files of > arbitrary types, including files that are not considered "regular files" > (e.g., symbolic links, directories). Some of these files may be > executable or contain executable data, > including scripts, that could compromise the security of a computer. I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources contained in the same archive. I'm not sure it's necessary to document the issue that an arbitrary tape archive could exhaust one's local storage space. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ From nobody Sun Sep 21 23:19:23 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE841A1A34 for ; Sun, 21 Sep 2014 23:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.365 X-Spam-Level: * X-Spam-Status: No, score=1.365 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krSO4dX81awK for ; Sun, 21 Sep 2014 23:19:09 -0700 (PDT) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671291A1A33 for ; Sun, 21 Sep 2014 23:19:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8M6ImLV002193 for ; Mon, 22 Sep 2014 06:19:09 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCV2P0YZHC004JEK@mauve.mrochek.com> for media-types@iana.org; Sun, 21 Sep 2014 23:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411366725; bh=4UHZnsP9l1a/jbCb00Gy36RcRclorMd+Ia3vsd8nxXQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=bEWtz3nhAZ1E/+gwxvzx/+6M/UNFx4BWGAjIF+M1YyY9pFcoo3f7dO7+sBSHsEEdB Id35WcumdryoZoR46M38oq8my0PF7A0lAXZO9JiMJS9k++4iBbaDvyYQj66zxfH9J0 AMqzRHWH+b0U0Fq6GPBx70VhMtRoK/iHq45KWLMw= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCTHY09O1S0000SM@mauve.mrochek.com>; Sun, 21 Sep 2014 23:18:28 -0700 (PDT) Message-id: <01PCV2OZKA7G0000SM@mauve.mrochek.com> Date: Sun, 21 Sep 2014 23:15:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 21 Sep 2014 19:43:16 -0700" <541F8CC4.1000809@seantek.com> References: <541F8CC4.1000809@seantek.com> To: Sean Leonard X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 22 Sep 2014 06:19:09 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/PgvAbEA5Gq5YXri0n-gB8nA65so Cc: media-types@iana.org Subject: Re: [media-types] Can we please bring media type registrations into the 21st century--Mac File Type codes X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:19:10 -0000 > While looking over the registrations, I noticed that it is required to > provide Mac OS File Type codes. That's incorrect. You can provide such a code if you want to. It is no no way, shape, or form required. > That is all well and good, but Mac OS File Type codes are so 1993. I > mean, literally **1993**. Mac OS X has been using Uniform Type > Identifiers since 2001. > How do people feel about updating the registration template to include > Apple Uniform Type Identifiers, and hopefully also to remove Mac File > Type codes? Asked and answered during the discussions leading up to the revised procedures specified in RFC 6838 about 18 months back. But feel free to make the suggestion when RFC 6838bis are underway, say, 6 years from now. Ned From nobody Sun Sep 21 23:53:02 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7540B1A1A36 for ; Sun, 21 Sep 2014 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZf_00RlR3pX for ; Sun, 21 Sep 2014 23:52:59 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3DD1A1A3D for ; Sun, 21 Sep 2014 23:52:59 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8M6qcAH002696 for ; Mon, 22 Sep 2014 06:52:58 GMT Received: from [192.168.118.120] (p5DDEF4CD.dip0.t-ipconnect.de [93.222.244.205]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0MaXEr-1Xl1OL3vhJ-00K99y; Mon, 22 Sep 2014 08:52:25 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Libbrecht In-Reply-To: <01PCV2OZKA7G0000SM@mauve.mrochek.com> Date: Mon, 22 Sep 2014 08:52:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CAEA1AC-906F-47CC-ABB5-B5454124AAD0@hoplahup.net> References: <541F8CC4.1000809@seantek.com> <01PCV2OZKA7G0000SM@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:2zjdjQcOv3nuR7Y59cpZtTMcY5+dYp5//R+rMgzTiTV HVR8FiXRByH/f07gC8s6VGiLTMG9InqKhFETbu81/i4vIXASpK bI2eu5bD/OCf/X17X3geX9LX8TgWgwi2jRuo3EpVRuw1EO+6XH M/ernGyN/FZnuvcfVMaFNYbdKcVyu4xKXSJBVVW98e3vxDOYKh rvQxU4CBCMN9tcR0M4SkAHMDdzgZKsMGlMBnDLHwdqLYe4ttgb 6hPvtZ8lUfo+fo1snZk03AtW9HaF2jfeNuNn/R74kNAMX03EJX cYIT3Oj9sxGlkVQ/GWibcrTiITRpfKIWyHFRJRBD+7PSNPXHAo lLJktTzUFe/RNPALYGAj3tdv0MI1TWQt1stEj2+ozZ2UzKdBh9 EmVoYaEaqNpmg== X-UI-Out-Filterresults: notjunk:1; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 22 Sep 2014 06:52:58 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/LEqc2zm7Da9wPF1xNSTqK84x2w4 Cc: media-types@iana.org, Sean Leonard Subject: Re: [media-types] Can we please bring media type registrations into the 21st century--Mac File Type codes X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:53:00 -0000 Sean, beyond what Ned has been indicating, I've been asking each submitter of = a media-type that could have a clipboard flavor, sometimes only = privately, to consider adding a UTI and a windows clipboard name. I have = been following the experience we had in the MathML media type = development doing this. This succeeded for just a few, e.g. for SVG. It had a fairly small success as quite many media types' authors do not = feel like clipboard or drag-and-drop are "expected operations" with = their content.=20 It's not exactly the same thing. And indeed, as far as I know, Apple's = own Finder does not user UTI (but I could be wrong). Something more that can be done?=20 (e.g. something more in the direction of the Finder, Windows or Linux = file explorers?) paul On 22 sept. 2014, at 08:15, Ned Freed wrote: >> While looking over the registrations, I noticed that it is required = to >> provide Mac OS File Type codes. >=20 > That's incorrect. You can provide such a code if you want to. It is no = no way, shape, > or form required. >=20 >> That is all well and good, but Mac OS File Type codes are so 1993. I >> mean, literally **1993**. Mac OS X has been using Uniform Type >> Identifiers since 2001. >=20 >> How do people feel about updating the registration template to = include >> Apple Uniform Type Identifiers, and hopefully also to remove Mac File >> Type codes? >=20 > Asked and answered during the discussions leading up to the revised = procedures > specified in RFC 6838 about 18 months back. But feel free to make the > suggestion when RFC 6838bis are underway, say, 6 years from now. >=20 > Ned >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Mon Sep 22 02:53:08 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920EC1A0066 for ; Mon, 22 Sep 2014 02:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Om78PR4asup for ; Mon, 22 Sep 2014 02:53:05 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67DD1A1A81 for ; Mon, 22 Sep 2014 02:53:04 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8M9qgHU002686 for ; Mon, 22 Sep 2014 09:53:02 GMT Received: from [192.168.1.64] (78.72.130.23) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u57601879) id 53D7A9870173D0C3; Mon, 22 Sep 2014 11:40:41 +0200 Message-ID: <541FEE97.3090304@henke37.cjb.net> Date: Mon, 22 Sep 2014 11:40:39 +0200 From: Henrik Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Liam R E Quin , Sean Leonard References: <541C7482.8040308@seantek.com> <541D0FD0.40700@it.aoyama.ac.jp> <541F8B4B.4090001@seantek.com> <20140921224820.23220df5.liam@w3.org> In-Reply-To: <20140921224820.23220df5.liam@w3.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:11:57 by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Mon, 22 Sep 2014 09:53:03 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/Dime3c4QeJUXU2OE_FRpaEQhUUY Cc: media-types@iana.org, ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 09:53:06 -0000 Liam R E Quin skrev: > On Sun, 21 Sep 2014 19:36:59 -0700 > Sean Leonard wrote: > > [...] >> Security considerations: >> TAR (Tape ARchive), as an archive format, can contain arbitrary files of >> arbitrary types, including files that are not considered "regular files" >> (e.g., symbolic links, directories). Some of these files may be >> executable or contain executable data, >> including scripts, that could compromise the security of a computer. > I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources contained in the same archive. I'm not sure it's necessary to document the issue that an arbitrary tape archive could exhaust one's local storage space. > > Liam > > Tars don't offer compression. They are the exception to the rule that all archive formats offer compression. As such, there is no need for a disclaimer about the risks of decompression. From stian@mygrid.org.uk Mon Sep 22 04:08:16 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6A1A1AA3 for ; Mon, 22 Sep 2014 04:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.021, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-g5dNg7pXYD for ; Mon, 22 Sep 2014 04:08:13 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B141A1A3C for ; Mon, 22 Sep 2014 04:08:12 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8MB7i4E012523 for ; Mon, 22 Sep 2014 11:08:05 GMT Received: by mail-oa0-f42.google.com with SMTP id i7so2126396oag.29 for ; Mon, 22 Sep 2014 04:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:cc:content-type:content-transfer-encoding; bh=cWraoh36W/weE535K09jWwnxno7RllNJjkDQgT9/AvQ=; b=PEnWGQR4L+oWxMa5iox62XcaOxHON1zlqTAmY52vAy7pEhY2bRE5oJrJBhwiDe9wky TUrdNPhJ/u5nHjkCrbIglstxonEev37wWQWsDdiaTk05yIOD6ZFUjGsmD+ole1C3svz1 /kDXbaa0jIxl8jPZpvk6tSrJRuau1wfGltbSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc:content-type:content-transfer-encoding; bh=cWraoh36W/weE535K09jWwnxno7RllNJjkDQgT9/AvQ=; b=cDq8+MqNFgJtJt4AtF82FtRiMuNTE6aZCqFr6oB+ZfqtaGQ6SBgvuqnYh8/+QWC4Mp GhGnrahV7IbtvmePfzsmYtEY17h/wAOb1a6s6KykD39pOsHyBgm/D8MFzJGYR3AsJim5 9ICP2UcPEaTXCNoyM2Fgj0MxNPodu/KEnmnskbhb3zW/W5dYEjWkrJFbLrSA/TeEOeW6 0RI03bCi7cGnRUDXxdxXbL8RIO2obZc/CwZXiy0thwYlgNs2hQuoX45T7wyrFZQvrmMK 72PMFeOUo0g26hBMjnTKzXL3jtLaRtfPs4wY5CPOm8ZWx06zw9HJ2nYWECg1XV7l5a2P z0VQ== X-Gm-Message-State: ALoCoQmnFFrTKzVBvHoJgzv/ff4nCzg4UD2bq9jBE8JNblFou9OaKShCt4Ui6fqXmgLpC7pdZZnE X-Received: by 10.182.197.165 with SMTP id iv5mt15522281obc.55.1411384064004; Mon, 22 Sep 2014 04:07:44 -0700 (PDT) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.151.35 with HTTP; Mon, 22 Sep 2014 04:07:23 -0700 (PDT) In-Reply-To: <541C7482.8040308@seantek.com> References: <541C7482.8040308@seantek.com> From: Stian Soiland-Reyes Date: Mon, 22 Sep 2014 12:07:23 +0100 X-Google-Sender-Auth: SuNmw5JrroJ8tshxPg7SNsqqurE Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [IPv6:2620:0:2d0:201::1:74]); Mon, 22 Sep 2014 11:08:05 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/g-yomW75FHrceHfJBoH9EanAgP8 Cc: media-types@iana.org, ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 11:09:40 -0000 Well, I can't say it is not about time to formalize application/x-tar :) What about the two most common compressed TAR formats, .tar.gz and .tar.bz2= ? Would they be registered as application/tar+gz and application/tar+bz2 ? On 19 Sep 2014 19:24, "Sean Leonard" wrote: > > To Media Types reviewers: > > This is a first draft of a registration request for the Internet media ty= pe application/tar, for tar format archives. > > Per RFC 6838, I do not believe that this registration requires a formal R= FC since it is from a recognized standards organization (IEEE). Nevertheles= s, it deserves review and discussion prior to the formal request being lodg= ed. Feedback is appreciated. > > > Registration Template [DRAFT] > > Type name: application > > Subtype name: tar > > Required parameters: N/A > > Optional parameters: N/A > > Encoding considerations: binary > > Security considerations: > TAR (Tape ARchive), as an archive format, can contain arbitrary files of > arbitrary types, including files that are not considered "regular files" = (e.g., symbolic links, directories). Some of these files may be executable = or contain executable data, > including scripts, that could compromise the security of a computer. Addi= tionally, some files may contain directives such as URIs that, when accesse= d, can compromise privacy. As POSIX file system > information can be recorded in this format, user and group permissions, > dates, and the like can also be overwritten when the data is extracted. F= urthermore, when encoding data in this format, personal data such as user a= nd group permissions from a source computer system can be > surreptitiously included in the format as a method of exfiltrating that d= ata. The format permits extensions ("pax extensions")--these extensions may= have their own security risks. > > Interoperability considerations: > TAR is a widely-recognized archive format on all modern computer systems,= especially those relating to UNIX and the POSIX standards. The format has = undergone several iterations; the main current variations are "pax" and "us= tar", which are compatible with each other. > > Published specification: > POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for Info= rmation Technology - Portable Operating System Interface (POSIX)" Shell and= Utilities - pax - EXTENDED DESCRIPTION - pax Interchange Format, ustar Int= erchange Format > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html > > > Applications that use this media type: > pax is the POSIX utility. Most UNIX-compatible implementations also inclu= de a utility called tar. > Most software archiving programs of any notoriety process this format; im= plementations are too numerous to list. > > Fragment identifier considerations: N/A > > Additional information: > > Deprecated alias names for this type: N/A > Magic number(s): hex: 75 73 74 61 72 00 30 30, aka > US-ASCII: u s t a r NUL 0 0, > at octet 257 > File extension(s): tar > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Sean Leonard > Andrew Josey > > Intended usage: COMMON > > Restrictions on usage: None. > > Author: > The Austin Common Standards Revision Group (CSRG) > The Institute of Electrical and Electronics Engineers (IEEE) > The Open Group > > Change controller: CSRG > > Provisional registration? (standards tree only): No > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Mon Sep 22 06:08:52 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509531A1AC8 for ; Mon, 22 Sep 2014 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZOgKNqR2WtF for ; Mon, 22 Sep 2014 06:08:49 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C82B1A1AB8 for ; Mon, 22 Sep 2014 06:08:47 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MD8QBM002854 for ; Mon, 22 Sep 2014 13:08:47 GMT Received: from [192.168.1.64] (78.72.130.23) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u57601879) id 540853EF007C1956; Mon, 22 Sep 2014 14:57:13 +0200 Message-ID: <54201CA7.5070305@henke37.cjb.net> Date: Mon, 22 Sep 2014 14:57:11 +0200 From: Henrik Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Stian Soiland-Reyes References: <541C7482.8040308@seantek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:11:10 by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 22 Sep 2014 13:08:47 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/_EBsrD37JURwQQk5OLKu3JTd8lg Cc: media-types@iana.org, ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:08:50 -0000 Stian Soiland-Reyes skrev: > Well, I can't say it is not about time to formalize application/x-tar :) > > > What about the two most common compressed TAR formats, .tar.gz and .tar.bz2 ? > > Would they be registered as application/tar+gz and application/tar+bz2 ? > I do believe that I covered this already. They are content encodings. So the headers should be like this: Content-Type: application/tar Content-Encoding: gzip I do not believe that bzip2 has been registered as a content encoding. It's about time that this is done. From nobody Mon Sep 22 06:31:46 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BF61A1ADD for ; Mon, 22 Sep 2014 06:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-MMNALLPweG for ; Mon, 22 Sep 2014 06:31:39 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1F21A1AC9 for ; Mon, 22 Sep 2014 06:31:37 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8MDVGTN023329 for ; Mon, 22 Sep 2014 13:31:37 GMT Received: from [192.168.118.120] (p5DDEF4CD.dip0.t-ipconnect.de [93.222.244.205]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0LalbM-1XylgI08pk-00kOmL; Mon, 22 Sep 2014 15:31:14 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Libbrecht In-Reply-To: <54201CA7.5070305@henke37.cjb.net> Date: Mon, 22 Sep 2014 15:31:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <474ADAEB-7C40-4FE1-B6B5-CD9009672718@hoplahup.net> References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> To: Henrik Andersson X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:gOxlsaCc/vU4f/1huC2nQoOYAot5IOktVRzyz/haKtI vxcQSOlRUwN2P2A3lEAiy4FzEBKdxULG3j9oyNwBhHOAjBQR9s mC7/uvNHiLYyR56C19BgQYvjbg5pmkZtYCv6n8ut7sIFgmgKiv S03ZOd1VjTs7UW8//aXegn45A9fcCpvp291Hg6nAf9UYyyGAvC DbytrNhyNPHqyrEx47DPCbaseHd2jsghffdDfmxwkot9i7/qfJ YGa/aw9o72LXagYDDD2QWsY0qe3fYKFx4Ov9r+vB06cM9cMLpx o8pcoAgcC5qhT3JBSOKVaMWK3cNnp+J9SXryARAj8i9R684oYr lJGqYo8yVPgdK4m+vHaNbgniw5YVfE5aW1qbucYd1gfCPJF7iJ 25csQNArSdvNw== X-UI-Out-Filterresults: notjunk:1; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 22 Sep 2014 13:31:37 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/IzQGIOFp0_5mCFNi57EUI7hFQQk Cc: Stian Soiland-Reyes , media-types@iana.org, ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:31:44 -0000 I'm wondering if this works. If the http-server and the http-client use the "encoding" gzip, aren't = they supposed to make it transparent to the receiver and thus not let = the http-client save the file as a .gz (for example a .tar.gz)? I may = have overlooked parts of http but that is how I understand it. It means that if the two agents above want to transmit a = "directory.tar.gz" they would need something such as a media-type for = tar.gz or? (and probably for tar.bz2). paul On 22 sept. 2014, at 14:57, Henrik Andersson = wrote: > Stian Soiland-Reyes skrev: >> Well, I can't say it is not about time to formalize application/x-tar = :) >>=20 >>=20 >> What about the two most common compressed TAR formats, .tar.gz and = .tar.bz2 ? >>=20 >> Would they be registered as application/tar+gz and = application/tar+bz2 ? >>=20 > I do believe that I covered this already. They are content encodings. >=20 > So the headers should be like this: > Content-Type: application/tar > Content-Encoding: gzip >=20 > I do not believe that bzip2 has been registered as a content encoding. > It's about time that this is done. >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Mon Sep 22 06:35:03 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADF1A1ADB for ; Mon, 22 Sep 2014 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5dcuPCzbr2f for ; Mon, 22 Sep 2014 06:34:59 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3CF1A1AD3 for ; Mon, 22 Sep 2014 06:34:58 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MDYcNr022559 for ; Mon, 22 Sep 2014 13:34:58 GMT Received: from localhost ([127.0.0.1] helo=w3.org) by jay.w3.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XW3lC-0006TI-5h; Mon, 22 Sep 2014 09:34:34 -0400 Date: Mon, 22 Sep 2014 09:34:32 -0400 From: "Eric Prud'hommeaux" To: Liam R E Quin Message-ID: <20140922133430.GH28944@w3.org> References: <541C7482.8040308@seantek.com> <541D0FD0.40700@it.aoyama.ac.jp> <541F8B4B.4090001@seantek.com> <20140921224820.23220df5.liam@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140921224820.23220df5.liam@w3.org> Organization: World Wide Web Consortium (W3C) - http://www.w3.org/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 22 Sep 2014 13:34:58 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/slZbGYvwmjPoNnN6hUsAsjJIW40 Cc: media-types@iana.org, Sean Leonard , ogdirector-platform@opengroup.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:35:02 -0000 * Liam R E Quin [2014-09-21 22:48-0400] > On Sun, 21 Sep 2014 19:36:59 -0700 > Sean Leonard wrote: > > [...] > > Security considerations: > > TAR (Tape ARchive), as an archive format, can contain arbitrary files of > > arbitrary types, including files that are not considered "regular files" > > (e.g., symbolic links, directories). Some of these files may be > > executable or contain executable data, > > including scripts, that could compromise the security of a computer. > > I'm surprised to see no mention of the possibility of overwriting system files on extracting a tar archive; also that device nodes might be included that could then be written to by later resources contained in the same archive. I'm not sure it's necessary to document the issue that an arbitrary tape archive could exhaust one's local storage space. iirc, there's a tarbomb attack to symlink X to /etc/passwd and later in the same archive, untar onto X. dunno if that's been a vulnerability in the last decade. > Liam > > > -- > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > Pictures from old books: http://fromoldbooks.org/ > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper. From nobody Mon Sep 22 06:36:13 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7576C1A1ACE for ; Mon, 22 Sep 2014 06:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIa7m19qihgw for ; Mon, 22 Sep 2014 06:36:12 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE89B1A1ADE for ; Mon, 22 Sep 2014 06:36:10 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MDZnNP004524 for ; Mon, 22 Sep 2014 13:36:09 GMT Received: from localhost ([127.0.0.1] helo=M6700) by jay.w3.org with esmtpa (Exim 4.72) (envelope-from ) id 1XW3mO-0006Zf-Qi; Mon, 22 Sep 2014 09:35:49 -0400 Date: Mon, 22 Sep 2014 05:20:06 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <928106157.20140922052006@w3.org> To: Sean Leonard In-Reply-To: <541F8CC4.1000809@seantek.com> References: <541F8CC4.1000809@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 22 Sep 2014 13:36:09 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/qN5O8fre_Hw9P3PyzEF4rpP-mok Cc: media-types@iana.org Subject: Re: [media-types] Can we please bring media type registrations into the 21st century--Mac File Type codes X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:36:12 -0000 Hello Sean, Monday, September 22, 2014, 4:43:16 AM, you wrote: > While looking over the registrations, I noticed that it is required to > provide Mac OS File Type codes. > That is all well and good, but Mac OS File Type codes are so 1993. I > mean, literally **1993**. Mac OS X has been using Uniform Type > Identifiers since 2001. > How do people feel about updating the registration template to include > Apple Uniform Type Identifiers, and hopefully also to remove Mac File > Type codes? Yes, absolutely. -- Best regards, Chris mailto:chris@w3.org From nobody Mon Sep 22 07:04:07 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F261A1B57 for ; Mon, 22 Sep 2014 07:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwGsswo61rO9 for ; Mon, 22 Sep 2014 07:03:54 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0532C1A1BCB for ; Mon, 22 Sep 2014 06:47:03 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MDkhuC023486 for ; Mon, 22 Sep 2014 13:47:03 GMT Received: from localhost ([127.0.0.1] helo=M6700) by jay.w3.org with esmtpa (Exim 4.72) (envelope-from ) id 1XW3wv-0007dL-KV; Mon, 22 Sep 2014 09:46:41 -0400 Date: Mon, 22 Sep 2014 15:46:40 +0200 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1803390208.20140922154640@w3.org> To: Henrik Andersson In-Reply-To: <54201CA7.5070305@henke37.cjb.net> References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Mon, 22 Sep 2014 13:47:03 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/ZjqFTj_zBC5csm4VMONv9U1phVQ Cc: media-types@iana.org Subject: [media-types] registering content encodings X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:03:56 -0000 Hello Henrik, Monday, September 22, 2014, 2:57:11 PM, you wrote: > I do not believe that bzip2 has been registered as a content encoding. > It's about time that this is done. How does one register a content encoding? I had a look at http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding which lists the existing ones and says Registration Procedure(s) IETF Review EXI is a new one, so I looked in that spec for a registration template but found merely a statement that it was registered http://www.w3.org/TR/exi/#contentCoding A pointer to the registration procedure would be welcome. -- Best regards, Chris mailto:chris@w3.org From nobody Mon Sep 22 07:13:58 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1531A00E6 for ; Mon, 22 Sep 2014 07:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrTiB7ViOOIp for ; Mon, 22 Sep 2014 07:13:46 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0E01A1B37 for ; Mon, 22 Sep 2014 07:09:58 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8ME9a4t025773 for ; Mon, 22 Sep 2014 14:09:56 GMT Received: from [192.168.1.64] (78.72.130.23) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u57601879) id 538049690183FD7A; Mon, 22 Sep 2014 15:57:53 +0200 Message-ID: <54202ADF.2080702@henke37.cjb.net> Date: Mon, 22 Sep 2014 15:57:51 +0200 From: Henrik Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Chris Lilley References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> <1803390208.20140922154640@w3.org> In-Reply-To: <1803390208.20140922154640@w3.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:11:43 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Mon, 22 Sep 2014 14:09:57 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/SpZRrpf5Yj9dWY5XZ3OSwJTvpXc Cc: media-types@iana.org Subject: Re: [media-types] registering content encodings X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:13:50 -0000 Chris Lilley skrev: > Hello Henrik, > > Monday, September 22, 2014, 2:57:11 PM, you wrote: > >> I do not believe that bzip2 has been registered as a content encoding. >> It's about time that this is done. > How does one register a content encoding? I had a look at > > http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding > > which lists the existing ones and says > > Registration Procedure(s) > IETF Review > > EXI is a new one, so I looked in that spec for a registration template > but found merely a statement that it was registered > http://www.w3.org/TR/exi/#contentCoding > > A pointer to the registration procedure would be welcome. > > Sorry to say it, but I am as lost as you are. I did look for it myself and I got about as much as you did. From nobody Mon Sep 22 07:57:28 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058111A1ABA for ; Mon, 22 Sep 2014 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRuzrJKXmR9w for ; Mon, 22 Sep 2014 07:57:22 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CD61A1ACF for ; Mon, 22 Sep 2014 07:57:19 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MEuvov019751 for ; Mon, 22 Sep 2014 14:57:18 GMT Received: by mail-wi0-f180.google.com with SMTP id q5so3191096wiv.13 for ; Mon, 22 Sep 2014 07:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=xw9/nWIlkAss8FRT74wuEBTUyj8Jedza1LfVRwrc/so=; b=lYgyXE5C1F3WrWqHZCWy2Q6yaKqlikFu16TioF7a9XRopKSeUPyQ70UaSxvL2EyWzd zrKz94Pe/3MX7fhRdqV4HfwjigJqtxGE0oJG2wfn8O0jmlqisNgP/FtL907s6Kv3e2UJ bTb96VQb2XFRSbcZIMwxXJG67IbzK8BMYT4yLdM51Nv/SWuTcl5vtmhdEjCYcjzrqK1p Yx5T2Ux5jOTPn0hDzI2FcBz3CuM5DYLO0wGGZozqp7gkMrZGcl+WQJQ19WIb5xgV8i5z o3ALoiwMV7WpeWdhJkdJ3/3p/E3EgzFUOgvAQzm098l5xplvqxrgDRpNERajgGW/8Tbq c4HA== X-Received: by 10.194.179.197 with SMTP id di5mr3070148wjc.125.1411397817661; Mon, 22 Sep 2014 07:56:57 -0700 (PDT) Received: from RoniE ([109.65.113.231]) by mx.google.com with ESMTPSA id gl10sm12464068wib.1.2014.09.22.07.56.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Sep 2014 07:56:56 -0700 (PDT) From: "Roni Even" To: "'Chris Lilley'" , "'Henrik Andersson'" References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> <1803390208.20140922154640@w3.org> In-Reply-To: <1803390208.20140922154640@w3.org> Date: Mon, 22 Sep 2014 17:56:45 +0300 Message-ID: <007801cfd675$6fccbc80$4f663580$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlj7Z0LvtLvpSen/2lUW7Uc4QoAgGiqqymAg5/PzoBPrhpRpw6TE2A Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [IPv6:2620:0:2830:201::1:74]); Mon, 22 Sep 2014 14:57:18 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/VO-flcGT_IiKf_dUR772jO5AXvY Cc: media-types@iana.org Subject: Re: [media-types] registering content encodings X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:57:23 -0000 Hi, Look at http://tools.ietf.org/html/rfc7231#section-8.4 Roni > -----Original Message----- > From: media-types [mailto:media-types-bounces@ietf.org] On Behalf Of Chris > Lilley > Sent: 22 September, 2014 4:47 PM > To: Henrik Andersson > Cc: media-types@iana.org > Subject: [media-types] registering content encodings > > Hello Henrik, > > Monday, September 22, 2014, 2:57:11 PM, you wrote: > > > I do not believe that bzip2 has been registered as a content encoding. > > It's about time that this is done. > > How does one register a content encoding? I had a look at > > http://www.iana.org/assignments/http-parameters/http- > parameters.xhtml#content-coding > > which lists the existing ones and says > > Registration Procedure(s) > IETF Review > > EXI is a new one, so I looked in that spec for a registration template but found > merely a statement that it was registered > http://www.w3.org/TR/exi/#contentCoding > > A pointer to the registration procedure would be welcome. > > > -- > Best regards, > Chris mailto:chris@w3.org > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From nobody Mon Sep 22 09:43:59 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919A81A1B07 for ; Mon, 22 Sep 2014 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3Cq_6agt6zp for ; Mon, 22 Sep 2014 09:43:55 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1F31A1B47 for ; Mon, 22 Sep 2014 09:43:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8MGhXh4016813 for ; Mon, 22 Sep 2014 16:43:53 GMT Received: from [192.168.2.160] ([93.217.96.101]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MU11l-1Xf98M2cef-00QigC; Mon, 22 Sep 2014 18:43:31 +0200 Message-ID: <542051AF.2050805@gmx.de> Date: Mon, 22 Sep 2014 18:43:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Henrik Andersson , Chris Lilley References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> <1803390208.20140922154640@w3.org> <54202ADF.2080702@henke37.cjb.net> In-Reply-To: <54202ADF.2080702@henke37.cjb.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mH+/EeT2Kk0mIzDgQ+xUytJnWiy2tJwE/T/KnlOv49jSR6ogPYD UCY19x0f8RXUF7AtSFJDj54FcdnVsO0eCsKP7xkd9QbpTMsYemddOn+R+joAgje/zcjFIRU lMeksknN+uC9qQUnJ6tbVCtMtRo61uXqs25KqRXUQoehz8pBG4aQ1sLVBaduTnMajnWoBLc OLlWhu06G+enFYpEAS7ew== X-UI-Out-Filterresults: notjunk:1; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Mon, 22 Sep 2014 16:43:54 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/0f6AReKaM4niXrdCKovWM3IZMnU Cc: media-types@iana.org Subject: Re: [media-types] registering content encodings X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 16:43:56 -0000 On 2014-09-22 15:57, Henrik Andersson wrote: > Chris Lilley skrev: >> Hello Henrik, >> >> Monday, September 22, 2014, 2:57:11 PM, you wrote: >> >>> I do not believe that bzip2 has been registered as a content encoding. >>> It's about time that this is done. >> How does one register a content encoding? I had a look at >> >> http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding >> >> which lists the existing ones and says >> >> Registration Procedure(s) >> IETF Review >> >> EXI is a new one, so I looked in that spec for a registration template >> but found merely a statement that it was registered >> http://www.w3.org/TR/exi/#contentCoding >> >> A pointer to the registration procedure would be welcome. >> >> > Sorry to say it, but I am as lost as you are. I did look for it myself > and I got about as much as you did. What about following the link to RFC 7231? Best regards, Julian From nobody Tue Sep 23 07:27:09 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830AC1A86E9 for ; Tue, 23 Sep 2014 07:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pd-w5GvbBQq for ; Tue, 23 Sep 2014 07:27:05 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D741A86E0 for ; Tue, 23 Sep 2014 07:27:03 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8NEQghj028345 for ; Tue, 23 Sep 2014 14:27:03 GMT Received: by mail-oi0-f47.google.com with SMTP id e131so4447877oig.20 for ; Tue, 23 Sep 2014 07:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Wx1mH7eqatY/BVCGRvgcymh1WamRwGiLNoerB91en/w=; b=FQnH/fB5XHvrmBnJcfAZ0/FY0lgrGg3kbpHVMEWxoEf66SJGLDib6V/PUMhdQJnUaB HxbryvGfaDPSjA2XSw5mkaaarpwdFhXpCZ2fzo5tmxdOvKJSDpLLuTjFtCCSuayTMzvC OSgTaUSvBM7C8zo5hvncfur4h/kwqPy0q4VtM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Wx1mH7eqatY/BVCGRvgcymh1WamRwGiLNoerB91en/w=; b=NyV4gfnaO7mpta9fPA0pTGGKdopFihd9MKcOZJ9fME2BY7aNn/0zF39p3ghzIcEFdk 3e6G0d3EZ8g0JvL92FRPMu7e86gsNwxdPWjXyYkCw1C+hHfvoQm0QJvUPrsIcq9ghdAV 9PAK8IDbab2QVTCdagx1dM/9rqCJkwN347TunO8vqsOZPz1UdolB1VO3z59CwI2aPJZh KRPBKAKWlY7nB1yphnRVEjhKZN02zP0vZMLBWgfYOcDRfBP/3ijUVaDMkjAWGI5Q0auP LhRYvDxqkaegTOT9UcvMaMY7w52EtDahTaFWkhKVbDRK2XgUsGcfA4XPW6o6mrZTEgPl Ne4A== X-Gm-Message-State: ALoCoQm7FxDPrvzSFmVj8D2pm5beCLm7wO3SfWudoIrCXbgqfb+cAvFfP8OdrOgK43j+04QdSWNs X-Received: by 10.60.62.205 with SMTP id a13mr9932600oes.64.1411481960067; Tue, 23 Sep 2014 07:19:20 -0700 (PDT) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.151.35 with HTTP; Tue, 23 Sep 2014 07:18:59 -0700 (PDT) In-Reply-To: <474ADAEB-7C40-4FE1-B6B5-CD9009672718@hoplahup.net> References: <541C7482.8040308@seantek.com> <54201CA7.5070305@henke37.cjb.net> <474ADAEB-7C40-4FE1-B6B5-CD9009672718@hoplahup.net> From: Stian Soiland-Reyes Date: Tue, 23 Sep 2014 15:18:59 +0100 X-Google-Sender-Auth: F4smAid_F6QgJ5O0BU7DBL95dPk Message-ID: To: Paul Libbrecht Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Tue, 23 Sep 2014 14:27:03 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/Q9zIJoD1j44oSGWaqdp6HOee-MM Cc: Henrik Andersson , ogdirector-platform@opengroup.org, media-types@iana.org Subject: Re: [media-types] Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 14:27:07 -0000 Yes, which would also ruin any kind of checksums. Not everyone uses HTTP, and not every HTTP server does the encoding header (Although I believe Apache does). For instance if you attach a .tar.gz by email I don't think many email client would insert the encoding MIME header. If you add the .tar.gz to some kind of bundle (like our Research Object Bundle [1]) then in the manifest you would want to describe the file as having the format (something like) application/x-tar+gz - not a .tar that happens to be compressed. [1] https://w3id.org/bundle/ On 22 September 2014 14:31, Paul Libbrecht wrote: > I'm wondering if this works. > If the http-server and the http-client use the "encoding" gzip, aren't th= ey supposed to make it transparent to the receiver and thus not let the htt= p-client save the file as a .gz (for example a .tar.gz)? I may have overloo= ked parts of http but that is how I understand it. > > It means that if the two agents above want to transmit a "directory.tar.g= z" they would need something such as a media-type for tar.gz or? (and proba= bly for tar.bz2). > > paul > > > On 22 sept. 2014, at 14:57, Henrik Andersson wrot= e: > >> Stian Soiland-Reyes skrev: >>> Well, I can't say it is not about time to formalize application/x-tar := ) >>> >>> >>> What about the two most common compressed TAR formats, .tar.gz and .tar= .bz2 ? >>> >>> Would they be registered as application/tar+gz and application/tar+bz2= ? >>> >> I do believe that I covered this already. They are content encodings. >> >> So the headers should be like this: >> Content-Type: application/tar >> Content-Encoding: gzip >> >> I do not believe that bzip2 has been registered as a content encoding. >> It's about time that this is done. >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types > --=20 Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 From nobody Wed Sep 24 15:53:35 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D9E1A1AD8 for ; Wed, 24 Sep 2014 15:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRVRem1F2RbI for ; Wed, 24 Sep 2014 15:53:31 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4182C1A1AD6 for ; Wed, 24 Sep 2014 15:53:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8OMrAuA005114 for ; Wed, 24 Sep 2014 22:53:30 GMT Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EA372509B6; Wed, 24 Sep 2014 18:53:09 -0400 (EDT) Message-ID: <54234B42.8050400@seantek.com> Date: Wed, 24 Sep 2014 15:52:50 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org References: <541C7482.8040308@seantek.com> <541D0FD0.40700@it.aoyama.ac.jp> <541F8B4B.4090001@seantek.com> <20140921224820.23220df5.liam@w3.org> <20140922133430.GH28944@w3.org> In-Reply-To: <20140922133430.GH28944@w3.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Wed, 24 Sep 2014 22:53:31 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/IAE0Az8Uez2d4U-gtdaE1DXYAko Cc: ogdirector-platform@opengroup.org Subject: [media-types] Draft 3 Re: Internet media type application/tar; request review X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 22:53:33 -0000 Draft 3: Registration Template [DRAFT] Type name: application Subtype name: tar Required parameters: None. Optional parameters: None. Encoding considerations: binary Security considerations: TAR (Tape ARchive), as an archive format, can contain arbitrary files of arbitrary types, including files that are not considered "regular files" (e.g., symbolic links, directories). Some of these files may be executable or contain executable data, including scripts, that could compromise the security of a computer. Additionally, some files may contain directives such as URIs that, when accessed, can compromise privacy. As POSIX file system information can be recorded in this format, user and group permissions, dates, and the like can also be overwritten when the data is extracted. Extracting a tar file runs the possibility of overwriting system files, and device nodes might be included that could be written to by later resources in the same archive. If extracted into an existing directory instead of a designated new directory, the contents can appear to "explode" and make locating existing files difficult (such an archive is known as a "tarbomb"). Furthermore, when encoding data in this format, personal data such as user and group permissions from a source computer system can be surreptitiously included in the format as a method of exfiltrating that data. The format permits extensions ("pax extensions")--these extensions may have their own security risks. Interoperability considerations: TAR is a widely-recognized archive format on all modern computer systems, especially those relating to UNIX and the POSIX standards. The format has undergone several iterations; the main current variations are "pax" and "ustar", which are compatible with each other. Published specification: POSIX.1-2008, IEEE Std 1003.1-2008 (2013 Edition), IEEE Standard for Information Technology - Portable Operating System Interface (POSIX)" Shell and Utilities - pax - EXTENDED DESCRIPTION - pax Interchange Format, ustar Interchange Format http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html Applications that use this media type: pax is the POSIX utility. Most UNIX-compatible implementations also include a utility called tar. Most software archiving programs of any notoriety process this format; implementations are too numerous to list. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): hex: 75 73 74 61 72 00 30 30, aka US-ASCII: u s t a r NUL 0 0, at octet 257 File extension(s): tar Macintosh file type code(s): N/A Person & email address to contact for further information: Sean Leonard Andrew Josey Intended usage: COMMON Restrictions on usage: None. Author: The Austin Common Standards Revision Group (CSRG) The Institute of Electrical and Electronics Engineers (IEEE) The Open Group Change controller: CSRG Provisional registration? (standards tree only): No From nobody Wed Sep 24 16:24:04 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C751A1B38 for ; Wed, 24 Sep 2014 16:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzFe6LRhb8bX for ; Wed, 24 Sep 2014 16:24:01 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50D41A1ADB for ; Wed, 24 Sep 2014 16:24:01 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8ONNfRg000935 for ; Wed, 24 Sep 2014 23:24:01 GMT Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD57C509B8; Wed, 24 Sep 2014 19:23:40 -0400 (EDT) Message-ID: <54235269.2060002@seantek.com> Date: Wed, 24 Sep 2014 16:23:21 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: media-types@iana.org, apps-discuss@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 24 Sep 2014 23:24:01 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/S1tGM-I7kta-27r3ooFLasGQZEY Subject: [media-types] A proposal for a new top-level media type: archive X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 23:24:02 -0000 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. 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 nobody Wed Sep 24 19:36:58 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AB91A6F13 for ; Wed, 24 Sep 2014 19:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRuZ5FjR8iKL for ; Wed, 24 Sep 2014 19:32:05 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89131A0109 for ; Wed, 24 Sep 2014 19:32:03 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8P2VgQU002197 for ; Thu, 25 Sep 2014 02:32:02 GMT Received: by mail-qa0-f54.google.com with SMTP id n8so3993354qaq.13 for ; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qrJuCSLs8uVsViHbRmuGu5SXJ2HxS54W7nR7ruIfgxg=; b=LHqEv9fmk15p7muFrdDeEEiCeoiHYkx8MQJffLenJEefNUR4axyq0ML2hPp90Gn6V1 erGCvdllRBbpMvDOtX/OzY+BKp5gpkZ/Odjmv6+OsM2xE31LtsclnIvmNjWXv2sTaGCR /CcSYO5bua00sL9lhOnk6O0JGAI4FrBm93Zi3HZ4dSsChth84ByTNeMqxDMgUzgQLBeI XNlWZfVQc0VxhTLiulnDTb1H9HCMg9okV5LjZ7Tli7cXfFVcX2zIKjCxDRNOjKqXQWz8 yDjMZKE9UDbshiYFnVEiyABghKa5qrqPvxLptuW+Jy8hzk72K9rjBtImS3hFfarWd4Rl Th6w== MIME-Version: 1.0 X-Received: by 10.140.20.151 with SMTP id 23mr12491886qgj.24.1411612302646; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.140.25.150 with HTTP; Wed, 24 Sep 2014 19:31:42 -0700 (PDT) In-Reply-To: <54235269.2060002@seantek.com> References: <54235269.2060002@seantek.com> Date: Thu, 25 Sep 2014 12:31:42 +1000 X-Google-Sender-Auth: 32Sl9MWAjzqL-Gk8LnUD2PpcT-U Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=001a11c12392dca5cc0503da998d X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [IPv6:2620:0:2830:201::1:74]); Thu, 25 Sep 2014 02:32:02 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/1zceZxZGu8LGHa5jjJKqW7yMw0A X-Mailman-Approved-At: Wed, 24 Sep 2014 19:36:52 -0700 Cc: media-types@iana.org, IETF Apps Discuss Subject: Re: [media-types] [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:32:07 -0000 --001a11c12392dca5cc0503da998d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 September 2014 09:23, Sean Leonard 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 fro= m > 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 sourc= e > of labeling and security issues. > =E2=80=8B > =E2=80=8B > > 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. > =E2=80=8B > =E2=80=8B =E2=80=8B > 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. > =E2=80=8B > =E2=80=8B > > =E2=80=8BActually there's a pretty decent list, pulled from a quick scan: - application/zip - application/gzip - application/zlib=E2=80=8B - 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. > =E2=80=8B > =E2=80=8B 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 ge= t > involved. > > =E2=80=8BI think this conversation already the start. The immediate questio= ns 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. =E2=80=8BHow 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? --=20 Matthew Kerwin http://matthew.kerwin.net.au/ On 25 September 2014 09:23, Sean Leonard 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 fro= m > application, because there are common semantics that apply. In fact, thes= e > 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 metada= ta > 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 conte= nt > is of this type (as opposed to the opaque application type), so it can ma= ke > 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 sourc= e > 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 ge= t > involved. > > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c12392dca5cc0503da998d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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: ar= chive.


Colour me interested.
=C2=A0

I think it's important to register archive formats as a distinct type f= rom application, because there are common semantics that apply.


+1


Archives are ubiquitous on the Internet. Even if archives are used "in= frequently" across the Internet architecture, they are obviously used = at the endpoints. Improper transmission of archives has become a major sour= ce of labeling and security issues.
=E2=80=8B
=E2=80=8B<= /div>

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 m= y browser guess which handler to launch based on the final characters of th= e URL, or the first n=C2=A0bytes of the file.

= =C2=A0
=E2=80=8B
=E2=80=8B
=E2=80=8B
Remarkably,= most archive formats have not been registered as media types (except for a= pplication/zip, which is an oldie). Therefore, it's pretty much a "= ;clean field". Furthermore, there is a trend of a lot of widely availa= ble tools to support multiple formats, so the probability is good that if y= ou pass some archive/* labeled content to an archive application, it will b= e able to do something intelligent with it.
=E2=80=8B
=E2=80=8B<= /div>

=E2=80=8BActually there's a pretty decent list, pulled from a qui= ck scan:
  • application/zip
  • application/gzip=
  • application/zlib=E2=80=8B
  • application/vnd.dece-zip=
  • application/vnd.easykaraoke.cdgdownload
  • applicatio= n/vnd.google-earth.kmz
  • application/vnd.ms-cab-compressed
  • application/vnd.osgi.bundle
  • application/vnd.software602.f= iller.form-xml-zip
... and probably countless others. = Some of them are closer to content-encodings than archives per se, and a go= od many are just zip files with a different extension, but they're stil= l archives. And yes, I agree, if they were all "archive/*" instead of "ap= plication," I=C2=A0cou= ld=C2=A0probably pass them all to 7zip or winrar without a second thought.<= /font>

=C2=A0
=E2=80=8B
=E2=80=8B
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 w= orking group. Experts with file system and archival experience should get i= nvolved.


=E2=80= =8BI think this conversation already the start. The immediate questions I h= ave, and my instinctive reactions (without having put any thought at all in= to it), are:
  1. How much value is there in distinguishin= g tarball from an ISO image from ... (as opposed to bundling them all under= application/octet-stream)
    -- my feeling is: quite a bit
  2. How muc= h value is there in grouping archives together in one registry, away from o= ther application/* types
    -- again, I think: probably a fair bit
  3. = =E2=80=8BHow 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 toge= ther just fine.
The real meaty starting point, though, would = be to register a type (or types) in the new registry. No point setting it u= p with nothing in. Was there one in particular you wanted to see added?

--
=C2=A0 Matthew Kerwin
=C2= =A0 http://matt= hew.kerwin.net.au/

On 25= September 2014 09:23, Sean Leonard <dev+ietf@seantek.com> wrote:
Colleagues on media-types and ap= ps-discuss:

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

Basically, archive would be a top-level type for all types of archive forma= ts.
ht= tps://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 f= rom application, because there are common semantics that apply. In fact, th= ese 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 bit= s, executable bits, ACLs). At the highest level, an Internet-connected appl= ication 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 de= cisions about the content that are unique to archives, namely, dealing with= the security issues, and presenting uniform user interfaces to handling su= ch archives. Content bundling types like message (RFC 5322), multipart, and= application/cms (CMS) are conceptually distinct. All those types can conta= in content that can get split off into files, but their purpose is not to r= eplicate file system data.

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

Remarkably, most archive formats have not been registered as media types (e= xcept for application/zip, which is an oldie). Therefore, it's pretty m= uch a "clean field". Furthermore, there is a trend of a lot of wi= dely available tools to support multiple formats, so the probability is goo= d 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
*=C2=A0 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 d= isks, 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-d= iscuss/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 w= orking group. Experts with file system and archival experience should get i= nvolved.

Sean

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c12392dca5cc0503da998d-- From nobody Wed Sep 24 19:44:58 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194D81A6F3D for ; Wed, 24 Sep 2014 19:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3HKl5_pF0NJ for ; Wed, 24 Sep 2014 19:44:55 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [IPv6:2620:0:2d0:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80071A19F5 for ; Wed, 24 Sep 2014 19:44:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id s8P2iYUO011350 for ; Thu, 25 Sep 2014 02:44:54 GMT Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCZ1WJIY5C004WN5@mauve.mrochek.com> for media-types@iana.org; Wed, 24 Sep 2014 19:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1411612770; bh=1pNnoB3GfA30RWcqC2USStwiEYUaoP9SuPUQF8bZlNI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=HYCsQQQOdvgmPkcw1t65TaQrtGc/Y6yynAFZ4d5i2sAx39Oo7x9BpnlJV5MiE58bD nlis6CDqoZSxENThDHux10MhJzWeNDcrMGX3/Y0TNq+X0N0T4tw6oSEVBVu3mHg688 uXFtVJjz+OBQfewdm5zb9S4c4VDdJ+EhR0Xzv8N4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PCYTB9U3BK0000SM@mauve.mrochek.com>; Wed, 24 Sep 2014 19:39:26 -0700 (PDT) Message-id: <01PCZ1WHF6Q80000SM@mauve.mrochek.com> Date: Wed, 24 Sep 2014 19:38:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 25 Sep 2014 12:31:42 +1000" References: <54235269.2060002@seantek.com> To: Matthew Kerwin X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Thu, 25 Sep 2014 02:44:54 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/RUFGi2VhAhEhSDhrubkF896RWB0 Cc: IETF Apps Discuss , media-types@iana.org, Sean Leonard Subject: Re: [media-types] [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:44:56 -0000 > On 25 September 2014 09:23, Sean Leonard 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. Yeah, me too. I'm surpised nobody has suggested this before. Ned From nobody Wed Sep 24 22:05:13 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C971A6F51 for ; Wed, 24 Sep 2014 19:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UZAahWn25w3 for ; Wed, 24 Sep 2014 19:48:50 -0700 (PDT) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3761A6F49 for ; Wed, 24 Sep 2014 19:48:49 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id s8P2mR3Y029750 for ; Thu, 25 Sep 2014 02:48:47 GMT Received: by mail-we0-f169.google.com with SMTP id k48so7161102wev.14 for ; Wed, 24 Sep 2014 19:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=h3O376mQ2KZal1guwj4ehuoqSZMhsNyrC/prommaLKM=; b=Vintl2VjWl/9s3uVXpBBJkVO2s049govSMk5ORIJ8BvcB2bHK+D3+jwekbcIvscPP+ GUHT7C+ES0k7MntcI5UiIhyL0l5j/Ul7cstDl2Ju4q0i1St0dwsAbZkKPBk4RyH5ooKH VxCJsSVAjdEJzWT5ALwfI1g4OCW1VdfrrkB8eNvIrOSHha9Bd6A+RWwk2TI5LRCJozUM KXavv2yIiM9DU5f5pZDl8CyjH3rCL4mjO8gOkPjtqcp2ViMhXpzTAS96PdfjhPkKewVS 2MqPts9ExkvXcbU9YNB3PDnmMDa1095ph1KbEB4wsCHQDf3nQvQzE+vgjsPJm7mBRIUT 0CzA== X-Received: by 10.180.105.41 with SMTP id gj9mr15529550wib.3.1411613306870; Wed, 24 Sep 2014 19:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.77.136 with HTTP; Wed, 24 Sep 2014 19:48:06 -0700 (PDT) In-Reply-To: <01PCZ1WHF6Q80000SM@mauve.mrochek.com> References: <54235269.2060002@seantek.com> <01PCZ1WHF6Q80000SM@mauve.mrochek.com> From: Ira McDonald Date: Wed, 24 Sep 2014 22:48:06 -0400 Message-ID: To: Ned Freed , Ira McDonald Content-Type: multipart/alternative; boundary=f46d04428262b762910503dad50a X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [IPv6:2620:0:2830:201::1:73]); Thu, 25 Sep 2014 02:48:47 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/media-types/jMLiTKVLQLO-A5GYqg_EeOJ9XMI X-Mailman-Approved-At: Wed, 24 Sep 2014 22:05:07 -0700 Cc: IETF Apps Discuss , Matthew Kerwin , media-types@iana.org Subject: Re: [media-types] [apps-discuss] A proposal for a new top-level media type: archive X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:48:51 -0000 --f46d04428262b762910503dad50a Content-Type: text/plain; charset=UTF-8 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: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed wrote: > > On 25 September 2014 09:23, Sean Leonard 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. > > Yeah, me too. I'm surpised nobody has suggested this before. > > Ned > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428262b762910503dad50a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

+1

Cheers,
- Ir= a


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Tru= sted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
= Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
ht= tp://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Win= ter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094Summer=C2=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

On Wed, Sep 24, 2014 at 10:38 PM, Ned Freed = <ned.freed@mrochek.com> wrote:
> On 25 September 2014 09:23, Sean Leonard <= ;dev+ietf@seantek.com> wro= te:

> > Colleagues on media-types and apps-discuss:
> >
> > I would like to propose that the IETF create a new top-level medi= a type:
> > archive.
> >
> >
> Colour me interested.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04428262b762910503dad50a--