Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AFB11E809C for ; Thu, 23 Feb 2012 14:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5kJB4Vx0tK0 for ; Thu, 23 Feb 2012 14:45:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD911E808E for ; Thu, 23 Feb 2012 14:45:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCC0JPTW9C000VNW@mauve.mrochek.com> for ietf-types@ietf.org; Thu, 23 Feb 2012 14:45:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCBX82X8F400ZUIL@mauve.mrochek.com>; Thu, 23 Feb 2012 14:45:14 -0800 (PST) Message-id: <01OCC0JOB34E00ZUIL@mauve.mrochek.com> Date: Thu, 23 Feb 2012 14:44:21 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 23 Feb 2012 14:33:12 -0800 (PST)" <01OCC0CIB73O00ZUIL@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> <01OCC0CIB73O00ZUIL@mauve.mrochek.com> To: Ned Freed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330037123; bh=BnEuiGOffjM75C+LGuqYPgTn01k48uZ6rbtUSOPdYSA=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=ecZOm4uqXFhJh2A6V+zRI2W2zkQux4VZl4y2Bu8+EQIX0MxwukJlyO93DvHZelra5 COWfAXpWNyq2AjRsVKPSFNrIzt8rTJKBQ6TO7ZJbZm55s6tvnel2K/bUjju/IgrZg+ ZNwK5CLoVhE+wDZGUCYYOF4l2BI2H4leCqXq7nEc= Cc: John R Levine , Bjoern Hoehrmann , ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 22:45:21 -0000 > As such, the requirement that security considerations for standards tree > registration trumps any "but there is a better location" argument that can be > made, because said better location doesn't actually exist and isn't going to > exist. Sorry, this was supposed to read: As such, the requirement that security considerations for standards tree registrations be as complete as possible trumps any "but there is a better location" argument that can be made, because said better location doesn't actually exist and isn't going to exist. Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0021F85E5 for ; Thu, 23 Feb 2012 14:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz3EywSex6yF for ; Thu, 23 Feb 2012 14:39:37 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B9A2E21F85E3 for ; Thu, 23 Feb 2012 14:39:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCC0CK271S00OTRZ@mauve.mrochek.com> for ietf-types@ietf.org; Thu, 23 Feb 2012 14:39:31 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCBX82X8F400ZUIL@mauve.mrochek.com>; Thu, 23 Feb 2012 14:39:28 -0800 (PST) Message-id: <01OCC0CIB73O00ZUIL@mauve.mrochek.com> Date: Thu, 23 Feb 2012 14:33:12 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 22 Feb 2012 23:55:24 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> To: Bjoern Hoehrmann DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330036776; bh=7S8EwqVzJSedqP6dzmE6baHz2GnR5XPImYYWoYO6wFA=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=SKo0Rb/cFhv6y6sWDhmJcackUuqsSJzUm9tpm7DTqEr6hkMZeDaGui4ZQ0i+/jizu mdK2BOr6pGymdDfQS+YM19ToEN8mSKh2yA49+YJwFDJuozCaAIpJPCG8nhEx1Ap4Q7 hRQir2FD/YzelSZyP0cJ8oq24+6OzX/oXN25e/bk= Cc: John R Levine , ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 22:39:39 -0000 > * Ned Freed wrote: > >> * John R Levine wrote: > >> > Encoding considerations: needs base64 or other encoding that allows > >> > arbitrary binary data > > > >> The value should be "8bit" (for both types). > > > >???? These are binary formats, plain and simple. There's no encoding included > >in them that would result in line-oriented output. > > > >I don't mind changing the wording to simply say "binary" if that is clearer, > >but "8bit" is flat-out incorrect. > My apologies, I meant "binary". The nomenclature does confuse me, and I > looked the definitions up again when making the comment, but apparently > it came out wrong. The point is that RFC 4288 says "one of these key- > words", not free-form text. The keyword absolutely needs to be included, but free form text is often helpful in explaining various nuances, and I see nothing in RFC 4288 that actually prohibits it. > >> > Additional information: > >> > > >> > Magic number(s): first byte is usually 0x78 but can also be 0x08, > >> > 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. > > > >> This is confusing. > > > >Then suggest text. Not sure how else you can say this. > I have not checked whether the above is all that can be said, but if it > is, something like "The first byte is one of ... where 0x78 is the most > common". That also works for me, but frankly I don't think it is any clearer. > >> > File extension(s): none > >> > Macintosh file type code(s): none > >> > > >> > Person and email address to contact for further information: see > >> > http://www.zlib.net/ > > > >> The form in RFC 4288 wants you to use "&" in place of "and". > > > >No, really, it doesn't. Nothing says the form has to be followed to this > >degree. > Well, I look at it from a automated data extraction perspective, and > little details like this make it harder to develop such tools. There > being no good reason to use "&" sometimes and "and" other times, I'd > prefer consistency, but I do agree that this is not a blocker. Um, I doubt very, very much there's any automation involved... > >> >4. Security Considerations > >> > > >> > Zlib and gzip compression can be used to compress arbitrary binary > >> > data such as hostile executable code. Also, data that purports to be > >> > in zlib or gzip format may not be, and fields that are supposed to be > >> > flags, lengths, or pointers, could contain anything. Applications > >> > should treat any data with due scepticism. > > > >> I would prefer simply referencing the two format RFCs, the types as such > >> do not introduce additional security considerations. > > > >This may need to be reworded to make it clearer, but AFAIK the point that these > >formats decode automatically in some contexts and are therefore sometimes used > >to get hostile code past overly simplistic scans is not mentioned in those > >documents and *is* a known security concern. As such, it needs to be mentioned. > That is something the format RFCs should discuss, it's not a media type > issue. With HTTP for instance you do not have automatic decompression > based on the media type, but rather in a separate mechanism. As John already pointed out, the RFCs say what they say and that isn't going to change. Expecting someone to republish an RFC for no other reason than to change a security considerion of this sort is simply not realistic. As such, the requirement that security considerations for standards tree registration trumps any "but there is a better location" argument that can be made, because said better location doesn't actually exist and isn't going to exist. Ned Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8211E8083 for ; Wed, 22 Feb 2012 22:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGYEm7wUQ8p3 for ; Wed, 22 Feb 2012 22:29:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C1F5411E807F for ; Wed, 22 Feb 2012 22:29:13 -0800 (PST) Received: (qmail 54509 invoked from network); 23 Feb 2012 06:29:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d4ec.4f45dcb8.k1202; bh=fEo7RCwac/EtZnZMLjDJ4+qgJVxLE1vjMV9A1g2uPoQ=; b=L2Fpjj+ZPIB1U7JnQ8UO5nH1gTALxcckrAcR9qqZwhy1zOW4M0WXO3CIwCwMsdoYqWWjnUhafFQNXrefmmDz0cIZB64UAn3+POvNxF4rEB1nHJdxXWHi3ytwtOiejzzgbI5LfvoYG9WLQ6wo06BNGLtQjO+WHILM/wPMt2F6zig= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Feb 2012 06:28:49 -0000 Date: 22 Feb 2012 22:29:10 -0800 Message-ID: From: "John R. Levine" To: "Bjoern Hoehrmann" In-Reply-To: References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 06:29:14 -0000 >> ???? These are binary formats, plain and simple. There's no encoding included >> in them that would result in line-oriented output. >> >> I don't mind changing the wording to simply say "binary" if that is clearer, >> but "8bit" is flat-out incorrect. I think I'll leave the current wording. >>>> Magic number(s): first byte is usually 0x78 but can also be 0x08, >>>> 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. >> >>> This is confusing. >> >> Then suggest text. Not sure how else you can say this. > > I have not checked whether the above is all that can be said, ... Why not? It's RFC 1950, section 2.2. >>>> 4. Security Considerations >>>> >>>> Zlib and gzip compression can be used to compress arbitrary binary >>>> data such as hostile executable code. Also, data that purports to be >>>> in zlib or gzip format may not be, and fields that are supposed to be >>>> flags, lengths, or pointers, could contain anything. Applications >>>> should treat any data with due scepticism. >> >>> I would prefer simply referencing the two format RFCs, the types as such >>> do not introduce additional security considerations. The draft does reference the two format RFCs. >> This may need to be reworded to make it clearer, but AFAIK the point that these >> formats decode automatically in some contexts and are therefore sometimes used >> to get hostile code past overly simplistic scans is not mentioned in those >> documents and *is* a known security concern. As such, it needs to be mentioned. > > That is something the format RFCs should discuss, it's not a media type > issue. With HTTP for instance you do not have automatic decompression > based on the media type, but rather in a separate mechanism. Beyond the fact that the format RFCs were written 15 years ago and aren't going to change, the issue here is that MIME parts can be mislabelled. Zlib and gzip have an internal structure with pointers and table lookups, so data that claims to be zlib but isn't quite could provoke buffer overruns and other security holes. By the way, HTTP has exactly the same vulnerability, since HTTP has gzip and deflate content codings. See RFC 2616, sec 3.5. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608421E8055 for ; Wed, 22 Feb 2012 15:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.805 X-Spam-Level: X-Spam-Status: No, score=-3.805 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0JRjIfeKkGc for ; Wed, 22 Feb 2012 15:04:43 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EEF6F21E801D for ; Wed, 22 Feb 2012 15:04:42 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2012 23:04:41 -0000 Received: from dslb-094-223-180-032.pools.arcor-ip.net (EHLO HIVE) [94.223.180.32] by mail.gmx.net (mp016) with SMTP; 23 Feb 2012 00:04:41 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+Zl6BQvCiZG8pWR/w2Dwxe+6C41jjWNjugda1TVT 9kKVO6EQ+AmsS1 From: Bjoern Hoehrmann To: "John R. Levine" Date: Thu, 23 Feb 2012 00:04:48 +0100 Message-ID: References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 23:04:44 -0000 * John R. Levine wrote: >>>> The draft is here: >>>> >>>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/ > >For comments, please see the draft, not just the excepts I posted. Most >of Bjoern's comments are already addressed in the current draft. If you mean draft-levine-application-gzip-00 then the excerpts seem to be quite equivalent to the draft, and I do not see a more recent draft. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B194221E8051 for ; Wed, 22 Feb 2012 14:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y46TFGTJqzLK for ; Wed, 22 Feb 2012 14:55:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5C9AA21F8518 for ; Wed, 22 Feb 2012 14:55:21 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2012 22:55:19 -0000 Received: from dslb-094-223-180-032.pools.arcor-ip.net (EHLO HIVE) [94.223.180.32] by mail.gmx.net (mp071) with SMTP; 22 Feb 2012 23:55:19 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+Quyx7YuOQB1HCjONkIl71eUX3Dl+b6+UQz195iQ WsMVlExBZTAx6Y From: Bjoern Hoehrmann To: Ned Freed Date: Wed, 22 Feb 2012 23:55:24 +0100 Message-ID: References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> In-Reply-To: <01OC9QB5028200ZUIL@mauve.mrochek.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: John R Levine , ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:55:22 -0000 * Ned Freed wrote: >> * John R Levine wrote: >> > Encoding considerations: needs base64 or other encoding that allows >> > arbitrary binary data > >> The value should be "8bit" (for both types). > >???? These are binary formats, plain and simple. There's no encoding included >in them that would result in line-oriented output. > >I don't mind changing the wording to simply say "binary" if that is clearer, >but "8bit" is flat-out incorrect. My apologies, I meant "binary". The nomenclature does confuse me, and I looked the definitions up again when making the comment, but apparently it came out wrong. The point is that RFC 4288 says "one of these key- words", not free-form text. >> > Additional information: >> > >> > Magic number(s): first byte is usually 0x78 but can also be 0x08, >> > 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. > >> This is confusing. > >Then suggest text. Not sure how else you can say this. I have not checked whether the above is all that can be said, but if it is, something like "The first byte is one of ... where 0x78 is the most common". >> > File extension(s): none >> > Macintosh file type code(s): none >> > >> > Person and email address to contact for further information: see >> > http://www.zlib.net/ > >> The form in RFC 4288 wants you to use "&" in place of "and". > >No, really, it doesn't. Nothing says the form has to be followed to this >degree. Well, I look at it from a automated data extraction perspective, and little details like this make it harder to develop such tools. There being no good reason to use "&" sometimes and "and" other times, I'd prefer consistency, but I do agree that this is not a blocker. >> >4. Security Considerations >> > >> > Zlib and gzip compression can be used to compress arbitrary binary >> > data such as hostile executable code. Also, data that purports to be >> > in zlib or gzip format may not be, and fields that are supposed to be >> > flags, lengths, or pointers, could contain anything. Applications >> > should treat any data with due scepticism. > >> I would prefer simply referencing the two format RFCs, the types as such >> do not introduce additional security considerations. > >This may need to be reworded to make it clearer, but AFAIK the point that these >formats decode automatically in some contexts and are therefore sometimes used >to get hostile code past overly simplistic scans is not mentioned in those >documents and *is* a known security concern. As such, it needs to be mentioned. That is something the format RFCs should discuss, it's not a media type issue. With HTTP for instance you do not have automatic decompression based on the media type, but rather in a separate mechanism. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495BC21E806D for ; Wed, 22 Feb 2012 00:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0RZU0tYZJOB for ; Wed, 22 Feb 2012 00:15:59 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9E021E8088 for ; Wed, 22 Feb 2012 00:15:57 -0800 (PST) Received: (qmail 91334 invoked from network); 22 Feb 2012 08:15:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=164c4.4f44a43b.k1202; bh=RCCgtRJllTUJrJHJDJ43fHI7wGrzjQDVvEygn2Lwu2s=; b=mSqnQUSQqmVII2npCLQNBWWkWGKcNAN9vnXXPSmRoYISOwC0PHX8dJqE4MBLud0Ik7WYKRmv3/olDE8MGzBFDUC8CUdN5lYSF5UWR7NdmubrdZHGUsfkjq9YnKiXYfyOq9G2RGiQDrzCagm++J1JnDhZ63j3jTpDTEiFAYhLGSg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Feb 2012 08:15:33 -0000 Date: 22 Feb 2012 00:15:54 -0800 Message-ID: From: "John R. Levine" To: "Ned Freed" In-Reply-To: <01OC9QB5028200ZUIL@mauve.mrochek.com> References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> <01OC9QB5028200ZUIL@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 22 Feb 2012 07:34:21 -0800 Cc: Bjoern Hoehrmann , ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 08:16:00 -0000 >>> The draft is here: >>> >>> https://datatracker.ietf.org/doc/draft-levine-application-gzip/ For comments, please see the draft, not just the excepts I posted. Most of Bjoern's comments are already addressed in the current draft. R's, John Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D021E8087 for ; Tue, 21 Feb 2012 23:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.177 X-Spam-Level: X-Spam-Status: No, score=-110.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az9S5DjvwDqL for ; Tue, 21 Feb 2012 23:38:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 08AD321E8043 for ; Tue, 21 Feb 2012 23:38:12 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-38-4f449b63fd4b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.14.01970.36B944F4; Wed, 22 Feb 2012 08:38:11 +0100 (CET) Received: from [131.160.126.154] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 22 Feb 2012 08:38:09 +0100 Message-ID: <4F449B60.9070709@ericsson.com> Date: Wed, 22 Feb 2012 09:38:08 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf-types@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 22 Feb 2012 07:34:21 -0800 Cc: Mary Barnes , Robert Sparks Subject: [ietf-types] Review of application/media-policy-dataset+xml registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 07:38:14 -0000 Hi, the draft below registers the following new media type: media-policy-dataset+xml. Your comments on this registration are appreciated. Thanks, Gonzalo http://tools.ietf.org/html/draft-ietf-sipping-media-policy-dataset-14#section-10.1 10.1. Media Type Registration Media type name: application Media subtype name: media-policy-dataset+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023]. Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 9 of this specification. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to convey media policy information between SIP user agents and a domain. Additional Information: Magic Number: None File Extension: .mpf or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Volker Hilt, Intended usage: COMMON Author/Change controller: The IETF. Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2021E8067 for ; Tue, 21 Feb 2012 23:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP8aOl2ADC0Q for ; Tue, 21 Feb 2012 23:30:30 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D10EF21E8043 for ; Tue, 21 Feb 2012 23:30:30 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OC9QB67T8W00UAZT@mauve.mrochek.com> for ietf-types@ietf.org; Tue, 21 Feb 2012 23:30:29 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OC8QYYHB0W00ZUIL@mauve.mrochek.com>; Tue, 21 Feb 2012 23:30:26 -0800 (PST) Message-id: <01OC9QB5028200ZUIL@mauve.mrochek.com> Date: Tue, 21 Feb 2012 23:23:07 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 21 Feb 2012 21:29:47 +0100" <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1329895832; bh=KtgneRtFoL7nn0zKfSq3Auc66l7FY2jcKcTdGfAyVFk=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=rQ+f3EedFeeseT7ywy+TKZ2YPiRA5nMJd/Rgjc2+TtAyeDsO239O2N9f9j66hIzzr DGtz8nnM+cxFMAzvsPw1WKh8pRiIkGWwrRE8L/CLqPvikcuG5mfu4ZwmOImK6W32uw A81OVK3HjlEs/FL2sYQJJgAEyIaY0Q5Z71Id4tJo= Cc: John R Levine , ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 07:30:32 -0000 > * John R Levine wrote: > >The draft is here: > > > >https://datatracker.ietf.org/doc/draft-levine-application-gzip/ > Thank you. The draft should mention that legacy applications have used > application/x-gzip in the past, but that's discouraged, people should > use the types you define instead. > (Most of these comments apply to both types). > >The zlib and gzip formats are defined in RFCs 1950 and 1952. This > >defines MIME types for them. > > > >2. The Application/Zlib Media Type > I would prefer all lower-case for the type name. > > Type name: application > > > > Subtype name: zlib > > > > Required parameters: none > > > > Optional parameters: none > > > > Encoding considerations: needs base64 or other encoding that allows > > arbitrary binary data > The value should be "8bit" (for both types). ???? These are binary formats, plain and simple. There's no encoding included in them that would result in line-oriented output. I don't mind changing the wording to simply say "binary" if that is clearer, but "8bit" is flat-out incorrect. > > Security considerations: See section [security] below > > > > Interoperability considerations: none > This should probably reference RFC1950. Seems a little redundant, but whatever. > > Published specification: [RFC1950] > > > > Applications that use this media type: anywhere data size is an issue > Same here. > > Additional information: > > > > Magic number(s): first byte is usually 0x78 but can also be 0x08, > > 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. > This is confusing. Then suggest text. Not sure how else you can say this. > > File extension(s): none > > Macintosh file type code(s): none > > > > Person and email address to contact for further information: see > > http://www.zlib.net/ > The form in RFC 4288 wants you to use "&" in place of "and". No, really, it doesn't. Nothing says the form has to be followed to this degree. > >4. Security Considerations > > > > Zlib and gzip compression can be used to compress arbitrary binary > > data such as hostile executable code. Also, data that purports to be > > in zlib or gzip format may not be, and fields that are supposed to be > > flags, lengths, or pointers, could contain anything. Applications > > should treat any data with due scepticism. > I would prefer simply referencing the two format RFCs, the types as such > do not introduce additional security considerations. This may need to be reworded to make it clearer, but AFAIK the point that these formats decode automatically in some contexts and are therefore sometimes used to get hostile code past overly simplistic scans is not mentioned in those documents and *is* a known security concern. As such, it needs to be mentioned. Ned Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B6011E8075 for ; Tue, 21 Feb 2012 12:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=-2.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD1K1i7RtL-3 for ; Tue, 21 Feb 2012 12:29:44 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C599421F86E3 for ; Tue, 21 Feb 2012 12:29:43 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2012 20:29:42 -0000 Received: from dslb-094-222-155-136.pools.arcor-ip.net (EHLO HIVE) [94.222.155.136] by mail.gmx.net (mp010) with SMTP; 21 Feb 2012 21:29:42 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18ClDRljeYCAJSM64gBPFn5dseyOxV/5EdJSMBCDp rMJcULLISgKyq/ From: Bjoern Hoehrmann To: "John R Levine" Date: Tue, 21 Feb 2012 21:29:47 +0100 Message-ID: <7bv7k75ur1utsvkk8jvdlp47tt8nuab9e6@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:29:49 -0000 * John R Levine wrote: >The draft is here: > >https://datatracker.ietf.org/doc/draft-levine-application-gzip/ Thank you. The draft should mention that legacy applications have used application/x-gzip in the past, but that's discouraged, people should use the types you define instead. (Most of these comments apply to both types). >The zlib and gzip formats are defined in RFCs 1950 and 1952. This >defines MIME types for them. > >2. The Application/Zlib Media Type I would prefer all lower-case for the type name. > Type name: application > > Subtype name: zlib > > Required parameters: none > > Optional parameters: none > > Encoding considerations: needs base64 or other encoding that allows > arbitrary binary data The value should be "8bit" (for both types). > Security considerations: See section [security] below > > Interoperability considerations: none This should probably reference RFC1950. > Published specification: [RFC1950] > > Applications that use this media type: anywhere data size is an issue Same here. > Additional information: > > Magic number(s): first byte is usually 0x78 but can also be 0x08, > 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. This is confusing. > File extension(s): none > Macintosh file type code(s): none > > Person and email address to contact for further information: see > http://www.zlib.net/ The form in RFC 4288 wants you to use "&" in place of "and". >4. Security Considerations > > Zlib and gzip compression can be used to compress arbitrary binary > data such as hostile executable code. Also, data that purports to be > in zlib or gzip format may not be, and fields that are supposed to be > flags, lengths, or pointers, could contain anything. Applications > should treat any data with due scepticism. I would prefer simply referencing the two format RFCs, the types as such do not introduce additional security considerations. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3921F88A6 for ; Tue, 21 Feb 2012 10:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfQzD8TwrxP for ; Tue, 21 Feb 2012 10:54:15 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32421F87F7 for ; Tue, 21 Feb 2012 10:54:10 -0800 (PST) Received: (qmail 54378 invoked from network); 21 Feb 2012 18:54:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=d466.4f43e850.k1202; bh=y2hdfGlOG3x0wwXwGtHp6b7Cu/41quJEoq+jpjARWCU=; b=H29d4SMAF4xgiQFvxluS8WLBT2BRkJE+BnaVPKxcYJGyeDXtKyapVoMIguhbww+Cn2QzzJajcFycxFkaRuK2cOKKgLq8j2sU2zo12jG+qulyp/5udg5AjBdKtdkeFTivDS2x/8A8p4GsO/1QbiiRi2i9tiunuudDbUjnXXfti4I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=d466.4f43e850.k1202; bh=y2hdfGlOG3x0wwXwGtHp6b7Cu/41quJEoq+jpjARWCU=; b=fWYG/UHOhr8Tg6gjVWakPpOhfDiEcKIyUVUGvI3MEI5ny+WdRpJqNpjPaYwIQkF/sQG8Nc1JmX1Brzj/USJ1zANsXDAcHdgc4gnTbfqm8P7VjbFUWH5VsIPT5UzUYR6JA2CFCU/PsNES11NNo1WzqF17u7mrGAkOEqKRUpZ8VPI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Feb 2012 18:53:45 -0000 Date: 21 Feb 2012 10:54:05 -0800 Message-ID: From: "John R Levine" To: ietf-types@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [ietf-types] Request for registration of application/gzip and application/zlib X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:54:27 -0000 The draft is here: https://datatracker.ietf.org/doc/draft-levine-application-gzip/ The zlib and gzip formats are defined in RFCs 1950 and 1952. This defines MIME types for them. 2. The Application/Zlib Media Type Type name: application Subtype name: zlib Required parameters: none Optional parameters: none Encoding considerations: needs base64 or other encoding that allows arbitrary binary data Security considerations: See section [security] below Interoperability considerations: none Published specification: [RFC1950] Applications that use this media type: anywhere data size is an issue Additional information: Magic number(s): first byte is usually 0x78 but can also be 0x08, 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. File extension(s): none Macintosh file type code(s): none Person and email address to contact for further information: see http://www.zlib.net/ Intended usage: COMMON Restrictions on usage: none Author: John Levine Change controller: IETF 3. The Application/Gzip Media Type Type name: application Subtype name: gzip Required parameters: none Optional parameters: none Encoding considerations: needs base64 or other encoding that allows arbitrary binary data Security considerations: See section [security] below Interoperability considerations: none Published specification: [RFC1952] Applications that use this media type: anywhere data size is an issue Additional information: Magic number(s): first two bytes are 0x1f, 0x8b. File extension(s): gz Macintosh file type code(s): none Person and email address to contact for further information: see http://www.gzip.net/ Intended usage: COMMON Restrictions on usage: none Author: John Levine Change controller: IETF 4. Security Considerations Zlib and gzip compression can be used to compress arbitrary binary data such as hostile executable code. Also, data that purports to be in zlib or gzip format may not be, and fields that are supposed to be flags, lengths, or pointers, could contain anything. Applications should treat any data with due scepticism. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075BB11E80C0 for ; Thu, 16 Feb 2012 12:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, TVD_RATWARE_MSGID_02=0.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IToBML8UQghu for ; Thu, 16 Feb 2012 12:51:14 -0800 (PST) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95411E80BB for ; Thu, 16 Feb 2012 12:51:10 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.208]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q1GKonqe005436 for ; Thu, 16 Feb 2012 12:51:09 -0800 Date: Thu, 16 Feb 2012 21:50:47 +0100 From: Mateusz Karcz To: ietf-types@iana.org X-Mailer: interia.pl/pf09 X-Originating-IP: 109.207.145.216 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329425448; bh=f3xBHMK+cxCzH9HkNt7s7IM/f9NbXpfvh8USxYFyO/c=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EhNbbQCKfIiMuJavbBsc+0qQ/wBEFTzT39wMntRQ/CTmqAfC0mHQ/bJRcKFS3Ma7H /mmOYdrmhMKUYCV0io5tC/DM/XS3L4La4AnCVMoOgNkd7RIqN7T1le9ajcURgnvDlG yDb2eNPFpa9DoqBVjjSW3bJHKGLWeYnyIy5ZnOoE= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Thu, 16 Feb 2012 20:51:10 +0000 (UTC) Subject: [ietf-types] Registration of media type application/vnd.matriksoft.mfff.fragment - errata X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:51:22 -0000 Interoperability considerations: MFFF is device-, platform-, and vendor-neutral. Each program in accordance= with format specification can use this media type. Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BCB11E80BB for ; Thu, 16 Feb 2012 12:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, TVD_RATWARE_MSGID_02=0.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyH6tp0KOdRA for ; Thu, 16 Feb 2012 12:48:52 -0800 (PST) Received: from pechora8.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id 907D511E80B5 for ; Thu, 16 Feb 2012 12:48:52 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.208]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id q1GKmUJF015056 for ; Thu, 16 Feb 2012 15:48:51 -0500 Date: Thu, 16 Feb 2012 21:48:28 +0100 From: Mateusz Karcz To: ietf-types@iana.org X-Mailer: interia.pl/pf09 X-Originating-IP: 109.207.145.216 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329425309; bh=ByQix3JlzzoYpe5vf+Zmj9axUlIogCl66gBezjoX6jY=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qaEVpseBKC0F8g4HGg5n3iToW0BO70LdIMVSaVKdCGs3bIMy8RRi4sw0B7V5dvC1l bz+/sYX/ZJ1wwORJAYUyGcNYpvAf04vFrc++gTlEdgrL/8MvgemtKab19G1M4h8BMM Mw6HCvFavwQt07ZXoiG6HMAUI59HibrzkfK26kAE= X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Thu, 16 Feb 2012 15:48:51 -0500 (EST) Subject: [ietf-types] Registration of media type application/vnd.matriksoft.mfff.fragment X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:48:57 -0000 Type name: application Subtype name: vnd.matriksoft.mfff.fragment Required parameters: revision <- defined in specification Encoding considerations: Same as encoding considerations of application/octet-stream. Security considerations: Same as security considerations of application/octet-stream and some speci= fic for this format. Fragments of file linked using Matriksoft Fragmented File Format processor= are often small in size after downloading. However, linking output file ca= n be huge. Before linking, the user should check the amount of available re= sources. Interoperability considerations: MFFF is device-, platform-, and vendor-neutral. Every Matriksoft Fragmented File Format Description is also platform-neutral. Eac= h program in accordance with format specification can use this media type. Published specification: http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec Applications that use this media type: Each program in accordance with format specification such as Matriksoft De= Fragmenter, can use this media type. Additional information: Magic number(s): none File extension(s): .mff Macintosh file type code(s): BINA Person & email address to contact for further information: Mateusz Karcz mateusz.karcz@interia.eu Intended usage: COMMON Restrictions on usage: None Author: Mateusz Karcz Change controller: Mateusz Karcz Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832AB21F852A for ; Tue, 14 Feb 2012 12:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsL1XIDUamSy for ; Tue, 14 Feb 2012 12:23:04 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE421F8505 for ; Tue, 14 Feb 2012 12:23:02 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F261540058; Tue, 14 Feb 2012 13:33:50 -0700 (MST) Message-ID: <4F3AC2A4.8050203@stpeter.im> Date: Tue, 14 Feb 2012 13:23:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Zach Shelby References: <625B50EE-D837-46C2-A5BB-1B134DC62D9E@sensinode.com> In-Reply-To: <625B50EE-D837-46C2-A5BB-1B134DC62D9E@sensinode.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/link-format registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:23:04 -0000 Note: I'll request an IETF Last Call on draft-ietf-core-link-format-11 now, which will run concurrently with the expert reviews. I am doing so in order to get all the reviews finished before IETF 83. Just FYI! Peter On 2/14/12 11:47 AM, Zach Shelby wrote: > draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This draft has a registration for a new media type in Section 7.3 (also copied below). Your comments would be appreciated. > > http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3 > > Thanks, > Zach Shelby > > 7.3. New link-format Internet media type > > This memo registers the a new Internet media type for the CoRE link > format, application/link-format. > > Type name: application > > Subtype name: link-format > > Required parameters: None > > Optional parameters: None > > Encoding considerations: Binary data > > Security considerations: > > Multicast requests using CoAP for the well-known link-format > resources could be used to perform denial of service on a constrained > network. A multicast request SHOULD only be accepted if the request > is sufficiently authenticated and secured using e.g. IPsec or an > appropriate object security mechanism. > > CoRE link format parsers should be aware that a link description may > be cyclical, i.e., contain a link to itself. These cyclical links > could be direct or indirect (i.e., through referenced link > resources). Care should be taken when parsing link descriptions and > accessing cyclical links. > > Interoperability considerations: > > Published specification: [[ this document ]] > > Applications that use this media type: CoAP server and client > implementations for resource discovery and HTTP applications that use > the link-format as a payload. > > Additional information: > > Magic number(s): > > File extension(s): *.wlnk > > Macintosh file type code(s): > > Intended usage: COMMON > > Restrictions on usage: None > > Author: CoRE WG > > Change controller: IETF > > > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5396921E80B4 for ; Tue, 14 Feb 2012 10:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCdE3ajIF3+w for ; Tue, 14 Feb 2012 10:47:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7488E21E8087 for ; Tue, 14 Feb 2012 10:47:11 -0800 (PST) Received: from [192.168.1.103] (188-67-227-29.bb.dnainternet.fi [188.67.227.29]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1EIl9h6004082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Feb 2012 20:47:10 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 20:47:08 +0200 Message-Id: <625B50EE-D837-46C2-A5BB-1B134DC62D9E@sensinode.com> To: ietf-types@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [ietf-types] Review of application/link-format registration X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:47:14 -0000 draft-ietf-core-link-format-11 has passed WGLC in the CoRE WG. This = draft has a registration for a new media type in Section 7.3 (also = copied below). Your comments would be appreciated. http://tools.ietf.org/html/draft-ietf-core-link-format-11#section-7.3 Thanks, Zach Shelby 7.3. New link-format Internet media type This memo registers the a new Internet media type for the CoRE link format, application/link-format. Type name: application Subtype name: link-format Required parameters: None Optional parameters: None Encoding considerations: Binary data Security considerations: Multicast requests using CoAP for the well-known link-format resources could be used to perform denial of service on a constrained network. A multicast request SHOULD only be accepted if the request is sufficiently authenticated and secured using e.g. IPsec or an appropriate object security mechanism. CoRE link format parsers should be aware that a link description may be cyclical, i.e., contain a link to itself. These cyclical links could be direct or indirect (i.e., through referenced link resources). Care should be taken when parsing link descriptions and accessing cyclical links. Interoperability considerations: Published specification: [[ this document ]] Applications that use this media type: CoAP server and client implementations for resource discovery and HTTP applications that use the link-format as a payload. Additional information: Magic number(s): File extension(s): *.wlnk Macintosh file type code(s): Intended usage: COMMON Restrictions on usage: None Author: CoRE WG Change controller: IETF Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4E21F86D7 for ; Sun, 12 Feb 2012 15:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOfLOdaYWppY for ; Sun, 12 Feb 2012 15:23:37 -0800 (PST) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 71C1A21F86FE for ; Sun, 12 Feb 2012 15:23:37 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id q1CNNFtg030700 for ; Sun, 12 Feb 2012 15:23:36 -0800 Received: from [192.168.178.35] (p5DDEC04F.dip0.t-ipconnect.de [93.222.192.79]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MRDId-1S5CvO1gid-00UOL7; Mon, 13 Feb 2012 00:23:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-741958686 From: Paul Libbrecht In-Reply-To: Date: Mon, 13 Feb 2012 00:23:13 +0100 Message-Id: References: To: Mateusz Karcz X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:BANmOr3R0/gsXyqESgpSmq7NRv5DXtlLEtD75Ve0R70 aEZuePYIy7oyQ3TgDx1lrqYiVg3CGFL3fLHnO6h8awXbJeNrS/ y8bTRBIuaMZO6GHbUetKyZfOtOuSoMJBR6M8CsSIBisrItwZo9 UOWcVuG7f0QIAgW1M5r8Q97W4WD1TExuVPcAvM0AmwnF60+hTm ok1s1r2Hvd/1OCTNdc29eJ/k8T9vsHGvUkWBLNksjmielnvD0g 9AYo0efxa2tLgPR8rqyxXovpvzFzEygW7s4KyCnCfN2+Re/MBf VtEHt3ZJr4F0VSuvCdm9aUN2YwqEGXNqaejRM02T/74boq7ZDt CCnQHmpFB2aNc1PrJPZGf1QVVqC2jg6EjSMsJ1vIdayCFIXTHq 6OBpcP1zbMiEw== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Sun, 12 Feb 2012 15:23:36 -0800 (PST) Cc: ietf-types@iana.org Subject: Re: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 23:23:39 -0000 --Apple-Mail-5-741958686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mateusz, can you be clearer on the following: you say: > Intended usage: > COMMON so one would expect a category of applications to be applicable by this = registration. But you say: > Applications that use this media type: > Matriksoft DeFragmenter (my intent was to figure out if media of such type would fit into the = clipboard, I could not answer this curiosity from this line neither from = the web-page). ... or maybe you intended to register an application-specific = media-type? If yes, the vnd tree is for you! paul= --Apple-Mail-5-741958686 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Intended = usage:
COMMON
so one would = expect a category of applications to be applicable by this = registration.
But you = say:
Applications that use = this media type:
Matriksoft = DeFragmenter

(my intent was to figure out if = media of such type would fit into the clipboard, I could not answer this = curiosity from this line neither from the = web-page).

... or maybe you intended to register an = application-specific media-type?
If yes, the vnd tree is for = you!

paul
= --Apple-Mail-5-741958686-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7527B21F8687 for ; Sun, 12 Feb 2012 12:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.878 X-Spam-Level: X-Spam-Status: No, score=-3.878 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4OyxZI7cCyc for ; Sun, 12 Feb 2012 12:06:22 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id D8D6521F8675 for ; Sun, 12 Feb 2012 12:06:14 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora4.lax.icann.org (8.13.8/8.13.8) with SMTP id q1CK5r3q022863 for ; Sun, 12 Feb 2012 20:06:14 GMT Received: (qmail invoked by alias); 12 Feb 2012 20:05:50 -0000 Received: from dslb-094-223-155-246.pools.arcor-ip.net (EHLO HIVE) [94.223.155.246] by mail.gmx.net (mp001) with SMTP; 12 Feb 2012 21:05:50 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18d4iFYlbYdWgufv4fCYosin53ZnAHHqeB80Z/l5z GGvUiHo4Mi5THJ From: Bjoern Hoehrmann To: Mateusz Karcz Date: Sun, 12 Feb 2012 21:05:54 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Sun, 12 Feb 2012 20:06:14 +0000 (UTC) Cc: ietf-types@iana.org Subject: Re: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:06:23 -0000 * Mateusz Karcz wrote: >Type name: > text >Subtype name: > vnd.matriksoft.mfff.description+xml XML media types under the 'text' top level type are unpopular, it would probably be a good idea to explain why this does not use 'application'. >Required parameters: > revision <- defined in Text missing. >Optional parameters: > charset <- Same as charset parameter of text/xml as specified in RFC 3023. >Encoding considerations: > Same as encoding considerations of text/xml as specified in RFC 3023. >Security considerations: > Same as described in RFC 3023. This suggests there are no other considerations which is unlikely to be the case. This should probably say something along the lines of "in addition to ..." >Additional information: > Magic number(s): As specified in RFC 3023. > File extension(s): .mfd .mffd .xml If there are specific extensions, this should not list "xml" because it could also be used, there would have to be more specific reasons. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A765821F85A1 for ; Sat, 11 Feb 2012 16:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, TVD_RATWARE_MSGID_02=0.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaPNMyUaTbBi for ; Sat, 11 Feb 2012 16:55:33 -0800 (PST) Received: from pechora6.dc.icann.org (unknown [IPv6:2620:0:2830:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6E21F8598 for ; Sat, 11 Feb 2012 16:55:32 -0800 (PST) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.208]) by pechora6.dc.icann.org (8.13.8/8.13.8) with ESMTP id q1C0tBJJ025936 for ; Sat, 11 Feb 2012 19:55:31 -0500 Date: Sun, 12 Feb 2012 01:35:48 +0100 From: Mateusz Karcz To: ietf-types@iana.org X-Mailer: interia.pl/pf09 X-Originating-IP: 83.25.167.73 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329006949; bh=kCa4TFdXuVQsoDAOCG0A79Q0vSTMrOtMCDKpYIWyiBQ=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nWe3/wNeByhMnSGhSuuFjiSO3qsdU9FZb6jiSFcm2lBKltzu//yN2S3pa4TnLQoP/ /vZVARYUd/ZVZSFXsHnM0q8z/48sCRx08rsDP5inJ0FFWoeBpIrq1fJo92dHqblTfP YFD8ncVWUf9m4hmTuT+4T8pCGzF9mhpRN1BhXpZ8= X-Greylist: Delayed for 00:19:20 by milter-greylist-4.2.3 (pechora6.dc.icann.org [192.0.46.72]); Sat, 11 Feb 2012 19:55:31 -0500 (EST) X-Mailman-Approved-At: Sun, 12 Feb 2012 06:46:46 -0800 Subject: [ietf-types] Registration of media type text/vnd.matriksoft.mfff.description+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 12:19:13 -0000 Type name: text Subtype name: vnd.matriksoft.mfff.description+xml Required parameters: revision <- defined in=20 Optional parameters: charset <- Same as charset parameter of text/xml as specified in RFC 3023. Encoding considerations: Same as encoding considerations of text/xml as specified in RFC 3023. Security considerations: Same as described in RFC 3023. Fragments of file linked with Matriksoft Fragmented File Descriptions are = often small in size after downloading. However, linking output file can be = huge. Before linking, the user should check the amount of available resourc= es. Interoperability considerations: It's XML-based media type. XML is device-, platform-, and vendor-neutral a= nd is supported by a wide range of Web user agents. Matriksoft Fragmented F= ile Format Description is also platform-neutral. Published specification: http://res.oimatriksoft.tk/spec/mfff/1.0-en.spec Applications that use this media type: Matriksoft DeFragmenter Additional information: Magic number(s): As specified in RFC 3023. File extension(s): .mfd .mffd .xml Macintosh file type code(s): TEXT Person & email address to contact for further information: Mateusz Karcz mateusz.karcz@interia.eu Intended usage: COMMON Restrictions on usage: None Author: Mateusz Karcz Change controller: Mateusz Karcz Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2144121F8883 for ; Fri, 10 Feb 2012 13:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.405 X-Spam-Level: X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkUGWb1-QVQf for ; Fri, 10 Feb 2012 13:09:43 -0800 (PST) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id E7DC121F8881 for ; Fri, 10 Feb 2012 13:09:41 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by pechora5.dc.icann.org (8.13.8/8.13.8) with ESMTP id q1AL9LMX025277 for ; Fri, 10 Feb 2012 13:09:41 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 7CAA55A2B6 for ; Fri, 10 Feb 2012 15:44:31 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClVS1WUxfs0q for ; Fri, 10 Feb 2012 15:44:31 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id 15A6A5A095 for ; Fri, 10 Feb 2012 15:44:31 -0500 (EST) Message-ID: <46E6A7C388B04236918A9A277527A81B@OfficeHP> From: "Carl Reed" To: "ietf types" Date: Fri, 10 Feb 2012 13:44:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019C_01CCE7FA.0F40B180" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Greylist: Delayed for 00:24:49 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Fri, 10 Feb 2012 13:09:41 -0800 (PST) Subject: [ietf-types] Request for review application/gml+xml - update X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:09:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_019C_01CCE7FA.0F40B180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There was an initial flurry of dialogue on the the OGC = application/gml+xml submission. Clemens Portele provided input in = response to your questions. Things have been quiet for a few weeks. I was wondering what happens next? Thanks and regards Carl Reed, PhD CTO and Executive Director Standards Program Open Geospatial Consortium www.opengeospatial.org The OGC: Making Location Count! --------------------- This communication, including attachments, is for the exclusive use of = addressee and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, any use, copying, = disclosure, dissemination or distribution is strictly prohibited. If you = are not the intended recipient, please notify the sender immediately by = return email and delete this communication and destroy all copies. "The important thing is not to stop questioning." -- Albert Einstein=20 "Security is mostly a superstition. It does not exist in nature. Life is = either a daring adventure or nothing." -- Helen Keller ------=_NextPart_000_019C_01CCE7FA.0F40B180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 was an initial flurry of dialogue on the the OGC application/gml+xml = submission.=20 Clemens Portele provided input in response to your questions. Things = have been=20 quiet for a few weeks.
 
I=20 was wondering what happens next?
  Thanks=20 and regards   Carl=20 Reed, PhD
CTO and Executive Director Standards Program
Open = Geospatial=20 Consortium
www.opengeospatial.org

The OGC: Making Location=20 Count!

---------------------

This communication, including = attachments, is for the exclusive use of addressee and may contain = proprietary,=20 confidential or privileged information. If you are not the intended = recipient,=20 any use, copying, disclosure, dissemination or distribution is strictly=20 prohibited. If you are not the intended recipient, please notify the = sender=20 immediately by return email and delete this communication and destroy = all=20 copies.

"The important thing is not to stop questioning." -- = Albert=20 Einstein
"Security is mostly a superstition. It does not exist in = nature.=20 Life is either a daring adventure or nothing." -- Helen Keller=20 ------=_NextPart_000_019C_01CCE7FA.0F40B180--