From SRS0=WCJ9=NM=ladisch.de=clemens@webclient5.webclient5.de Thu Nov 1 01:58:10 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6512872C for ; Thu, 1 Nov 2018 01:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249] autolearn=no autolearn_force=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 94sP6fkYuyoT for ; Thu, 1 Nov 2018 01:58:09 -0700 (PDT) Received: from webclient5.webclient5.de (webclient5.webclient5.de [IPv6:2a01:4f8:212:88::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D6C127B92 for ; Thu, 1 Nov 2018 01:58:08 -0700 (PDT) Received: from [10.1.2.4] (unknown [94.101.37.79]) by webclient5.webclient5.de (Postfix) with ESMTPSA id 88AE3558393A for ; Thu, 1 Nov 2018 09:58:06 +0100 (CET) To: media-types@ietf.org References: <20181031102655.GI17721@w3.org> From: Clemens Ladisch Message-ID: <7a0d47e2-807e-12d3-f6eb-727fd94ddcb1@ladisch.de> Date: Thu, 1 Nov 2018 09:58:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at webclient5 X-Virus-Status: Clean Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 09:02:02 -0000 Petter Reinholdtsen wrote: > I have no idea how to identify the tool maintainers which currently > recognize text/x-{patch,diff}. Perhaps at least the maintainers of > http://www.gnu.org/software/diffutils/ and > http://savannah.gnu.org/projects/patch/ are relevant contributors to > such discussion? They do not really use or recognice MIME types, being > command line tools, but are responsible for the typical producer and > consumer of these files. Pretty much all version control systems can generate patches. However, the default output typcially does not rely on MIME type detection but uses custom formatting (in a GUI, or in HTML). As far as I can see, the only place where the MIME type might matter are e-mail attachments. > I notice you mention application/*. Is not text/* a better choice, > given that for example patches in emails could be shown directly in the > email and do not need a "viewer" to be readable to those of us receiving > patches? As it happens, cgit deliberately returns "text/plain" (e.g., ). Regards, Clemens From nobody Thu Nov 1 03:05:31 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3708F124408 for ; Thu, 1 Nov 2018 03:05:30 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PuqBFH3_JFVC for ; Thu, 1 Nov 2018 03:05:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC224124D68 for ; Thu, 1 Nov 2018 03:05:27 -0700 (PDT) Received: from [192.168.178.20] ([91.61.59.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPDeK-1gDm8i0w4m-004PTc; Thu, 01 Nov 2018 11:05:24 +0100 Received: from [192.168.178.20] ([91.61.59.249]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MPDeK-1gDm8i0w4m-004PTc; Thu, 01 Nov 2018 11:05:24 +0100 To: Clemens Ladisch , media-types@ietf.org References: <20181031102655.GI17721@w3.org> <7a0d47e2-807e-12d3-f6eb-727fd94ddcb1@ladisch.de> From: Julian Reschke Message-ID: <2fda8422-3059-43d7-7885-3f83225ce774@gmx.de> Date: Thu, 1 Nov 2018 11:05:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <7a0d47e2-807e-12d3-f6eb-727fd94ddcb1@ladisch.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:4Xh6g58Lqlk38a8AIRae5P2SMSVkzUFHlITTC+aT1N5xGcnsDLx uDsiF3rxOLG/SorcTtlUFLgR64bRkVC9Ya/R7R2lvNA3Q07XeQojkfQgLS+OHr6VcXH8AMa GK/IZXKfMi/kJXbtWIKNFjlDXKYJEs16MQZskPss0liS4Mz/CIYEI97Iml+BEA5mH1GQPo4 uqLZ2wUKD6a3oP2Jwpxxg== X-UI-Out-Filterresults: notjunk:1;V01:K0:auiPxQXZV74=:8j+yG6KbmR11Ba+ZymCHEh wcDMAfdQhMszl6Kno1gsp6XBfrzgbT9gSFIxpRgX6I9dVGfV77c0knGwfCyjZigJACGDEOEqi 0YuObMYE3j3NiiHUxjTpi9b0C/+kUb8YvTbAKZHoLOqWWIJZBII0sRxYpTCvGbDMhjyYf2td5 Sg4vw13GQhuecSuEEEpnTO67+V4bBwIoOe4YgO9TIKolPngrL1EdPGfGpe1gLzD+n9dzpXmpL vTJGHub5vhAYeR5JrqOkCIDJsSptZb9k1ym/+rnxENESfUyjgYsy9aIJQhwhKk4N+fHqfJfBb Y2j91CdTQIFwmgOHnHzUt1TVfsK3gp96lJv6i+SvnHTGsIAEPlISlhohkINNmiQ4x4WY6ctNh xa312C1P8R3WTKL2whgf0z0bMwbB/pGq7CDuSkx799FZD5K9LBQrbD4bdVUZNUHxIsm6k+/d3 DERcM7dR3x7XWDqWQfarNASiYHkohm+TloH5Gylre94C4bvPk8XulCv4aunWOKy70lR4tx6Zw Q3l0xgKjCLLef2/M3IxPjecjZNp03W138nbrx6qLMQmlODKIJIU/5hGVR9EZZVBKFdmWeYJsA vgthee2QPB0o44plpCWTGyt669OVIEH3eRgC74V15+HiQK7jkIITbFgoD9HSuJ1B1iA7jN3gG PwttAhYvSCDWJKZUNLaKtA45BQt64308RwcQ7UAmLquw3atRb9fc4GjX4lBSbwYYTlRLW+knJ FYfsEKUcJnbvgSHMy8iQCYu0uBOVKvNS4BNalJYyH3cT3rcAKAFEVPP2QLmQiSM5wJOclpzNK /+DQuxk7+RXHdOSGjSl9U06X6u5mgQ02TrW3DG22dgFGg8733I= Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 10:05:30 -0000 On 2018-11-01 09:58, Clemens Ladisch wrote: > Petter Reinholdtsen wrote: >> I have no idea how to identify the tool maintainers which currently >> recognize text/x-{patch,diff}. Perhaps at least the maintainers of >> http://www.gnu.org/software/diffutils/ and >> http://savannah.gnu.org/projects/patch/ are relevant contributors to >> such discussion? They do not really use or recognice MIME types, being >> command line tools, but are responsible for the typical producer and >> consumer of these files. > > Pretty much all version control systems can generate patches. However, > the default output typcially does not rely on MIME type detection but > uses custom formatting (in a GUI, or in HTML). As far as I can see, > the only place where the MIME type might matter are e-mail attachments. > ... FWIW, it would also be interesting for use as a payload in an HTTP PATCH request (see https://greenbytes.de/tech/webdav/rfc5789.html) - as far as I recall the big challenge here is not the label but to actually find a well-documented and interoperable patch format. Best regards, Julian From nobody Thu Nov 1 04:01:29 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08C1277D2 for ; Thu, 1 Nov 2018 04:01:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 uXQwyVpji73V for ; Thu, 1 Nov 2018 04:01:22 -0700 (PDT) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B06012777C for ; Thu, 1 Nov 2018 04:01:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id E698040032; Thu, 1 Nov 2018 12:01:16 +0100 (CET) Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id c_x2W7zQx6rW; Thu, 1 Nov 2018 12:01:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 833614002F; Thu, 1 Nov 2018 12:01:15 +0100 (CET) X-Virus-Scanned: amavisd-new at bouvier.get.c.bitbit.net Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SjMttAl_sQ61; Thu, 1 Nov 2018 12:01:15 +0100 (CET) Received: from hjemme.reinholdtsen.name (cm-84.212.222.24.getinternet.no [84.212.222.24]) by bouvier.getmail.no (Postfix) with SMTP id 59AE64002E; Thu, 1 Nov 2018 12:01:15 +0100 (CET) Received: (nullmailer pid 14007 invoked by uid 10001); Thu, 01 Nov 2018 11:01:15 -0000 From: Petter Reinholdtsen To: media-types@ietf.org In-Reply-To: <7a0d47e2-807e-12d3-f6eb-727fd94ddcb1@ladisch.de> References: <20181031102655.GI17721@w3.org> <7a0d47e2-807e-12d3-f6eb-727fd94ddcb1@ladisch.de> Date: Thu, 01 Nov 2018 12:01:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 11:01:27 -0000 [Clemens Ladisch] > Pretty much all version control systems can generate patches. However, > the default output typcially does not rely on MIME type detection but > uses custom formatting (in a GUI, or in HTML). As far as I can see, > the only place where the MIME type might matter are e-mail > attachments. It also matter for downloading from web sites and selecting files in a Linux/unix file browsers, where the user can get a patch viewer instead of a text editor. :) > As it happens, cgit deliberately returns "text/plain" (e.g., > ). While the Debian source service hand out patches using 'text/x-diff', as can be seen from . There is no doubt that both the mime types are in use, so the question is really which one to choose as the official one, unless creating a new one is better. It will take time for a registered MIME type to gain tracktion no matter which one we pick, but of course by picking one of the used ones, we get a head start with existing users. :) -- Happy hacking Petter Reinholdtsen From nobody Thu Nov 1 05:23:18 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CCE1276D0 for ; Thu, 1 Nov 2018 05:23:16 -0700 (PDT) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 RBfIUvTvDCKD for ; Thu, 1 Nov 2018 05:23:13 -0700 (PDT) Received: from v-smtpout1.han.skanova.net (v-smtpout1.han.skanova.net [81.236.60.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F62124D68 for ; Thu, 1 Nov 2018 05:23:12 -0700 (PDT) Received: from [192.168.1.3] ([81.227.16.59]) by cmsmtp with ESMTPA id IC08gzdzxONS2IC0Bgt4Bm; Thu, 01 Nov 2018 13:23:09 +0100 To: Eric Prud'hommeaux , Petter Reinholdtsen Cc: media-types@ietf.org References: <20181031102655.GI17721@w3.org> From: Henrik Andersson Openpgp: preference=signencrypt Message-ID: Date: Thu, 1 Nov 2018 13:23:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20181031102655.GI17721@w3.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLdi0x0lLZ+0HENyoLsYD7U/Vw6AzxTS0a50swucw8dzfIYUIzkKZRgSW9AnyScMZl9dVcMZ+u9q3sa7+XST1vV7ARKcHdq4mRh8fxlzY1AdAEtmBEv+ rsya+zBfEGxAYyHb5AMCQqYa/cASouHMsVAnfbuCbfGxe03hd58ChuWtx8nSi72dryDbQgRINzTETi88n62YSrKRMPeHSAbNpB0= Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 12:23:16 -0000 Eric Prud'hommeaux skrev: > I think this negotiation must happen with the tool maintainers which > currently recognize text/x-{patch,diff}. Given that that's probably > impossible, the answer is almost certainly that you are stuck with > "x-". Thanks for picking this up. > > I tried to answer your question but ended up puzzled by this text in > [RFC6838]: > [[ > Note that types with names beginning with "x-" are no longer > considered to be members of this tree (see [RFC6648]). Also note > that if a generally useful and widely deployed type incorrectly ends > up with an "x-" name prefix, it MAY be registered using its current > name in an alternative tree by following the procedure defined in > Appendix A. > ]] > > The only "x-" subtree in [IMT] is "x-www-form-urlencoded", and maybe > it's an exception. The tricky question is whether x-{diff,patch} > deserve the same exception. On one hand, we don't want a slippery > slope of exceptions, on the other hand, the tree's job is to document > current or achievable reality. > > > [RFC6838] https://tools.ietf.org/html/rfc6838#section-3.4 > [IMT] https://www.iana.org/assignments/media-types/media-types.xhtml#application > In short, don't use the "x-" prefix. And don't use the "x." prefix either. Those explicitly mean "not registered". The mentioned exception is a sad reality that only came to pass because of the insane costs to change it. There are no such costs here. From nobody Thu Nov 1 08:06:17 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC191277BB for ; Thu, 1 Nov 2018 08:06:14 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 0dVgSkWYXZyE for ; Thu, 1 Nov 2018 08:06:12 -0700 (PDT) Received: from lamora.getmail.no (lamora.getmail.no [84.210.184.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B02124BAA for ; Thu, 1 Nov 2018 08:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lamora.getmail.no (Postfix) with ESMTP id B4C2260820; Thu, 1 Nov 2018 16:06:06 +0100 (CET) X-Virus-Scanned: amavisd-new at lamora.get.c.bitbit.net Received: from lamora.getmail.no ([127.0.0.1]) by localhost (lamora.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKpkZ9-P6b_T; Thu, 1 Nov 2018 16:06:05 +0100 (CET) Received: from hjemme.reinholdtsen.name (cm-84.212.222.24.getinternet.no [84.212.222.24]) by lamora.getmail.no (Postfix) with SMTP id 59C126081F; Thu, 1 Nov 2018 16:06:05 +0100 (CET) Received: (nullmailer pid 3218 invoked by uid 10001); Thu, 01 Nov 2018 15:06:05 -0000 From: Petter Reinholdtsen To: media-types@ietf.org In-Reply-To: References: <20181031102655.GI17721@w3.org> Date: Thu, 01 Nov 2018 16:06:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 15:06:15 -0000 [Henrik Andersson] > In short, don't use the "x-" prefix. And don't use the "x." prefix > either. Those explicitly mean "not registered". The mentioned exception > is a sad reality that only came to pass because of the insane costs to > change it. There are no such costs here. So, if I understand you correctly, your recommendation is to use text/diff or text/patch as the official registered MIME type? I am all for a identifier with out the "x-" prefix. :-) I notice from my collection that text/x-diff have 27% higher use than text/x-patch. If we are moving to a different identifier, I guess it do not really matter which one of the old ones were most "popular". :) -- Happy hacking Petter Reinholdtsen From nobody Thu Nov 1 08:17:29 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0592128C65 for ; Thu, 1 Nov 2018 08:17:27 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4jb2FUzurp_1 for ; Thu, 1 Nov 2018 08:17:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB05129619 for ; Thu, 1 Nov 2018 08:17:25 -0700 (PDT) Received: from [192.168.178.20] ([91.61.59.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmJsk-1ficzF2H1G-00Zvt5; Thu, 01 Nov 2018 16:17:19 +0100 Received: from [192.168.178.20] ([91.61.59.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmJsk-1ficzF2H1G-00Zvt5; Thu, 01 Nov 2018 16:17:19 +0100 To: Petter Reinholdtsen , media-types@ietf.org References: <20181031102655.GI17721@w3.org> From: Julian Reschke Message-ID: Date: Thu, 1 Nov 2018 16:17:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:TT6THUlveoUEYh11SVeWWnblYoRfF46QZlBPoGalhmMW+7JqwAO P0gQxFhSGUCXNcGm51Y1SLGfV3MEfmNmsiwhq5iOpdcVuRFyvy1WWmDes4tY+h8BBE09SuM Zzkj1+9hYmXnnvyBwzkbTDHzGwhOw6GrOCD1reZU3Jo3EITOXgNQZhXAklebBZeBJRf0kIn ywwMrZ7wg/K0HXcB6XOzQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bGXv11Ytef0=:kh+b5Yc/vSWTvCx45AGYcV UFqTYKVosNQ4Q95p6EiAb0q8ATtBi1hFDSZrlOui6766+BExrBq0MGbxuz1h0kBndm532s/g6 MNEpWgdPxulVTwP6vvJYYgpK9UTArJDSnv2GsxWiF+GS9OuyPF6Ism27F/SMtVwA7ggghsUyN wxZL9WhvhmM4t2rUp58HgSL/G+IMQUrUK6t2rJleD8uS7SWt4TmPXLllAnHrS83dAKSiZ20p+ 1ICEKbF/kyRUNEGPJQVnHNlZOjNgj3bGb25zKOnyLMmnLWzFPNbUdCEKLVZfMOicRBIdahXa0 dcb8v+wmzdAzXO/IEp3REA+dV1EgjN8TKwyzHehwOFoPPrwLGfGdQ8OqIK8F3scq9rnKHjsVV MM7GYT658hLYuNFY1KxNAeavFhd6Oh5e8RJNJx6CfhJLUTesZzDpJ4smG83c/aQhzAgLJ4t1Z VnwVJtcC4iByer3xAHxgmc0cm/NQtmnh2tSD7RXlvpPdHyHYq52Hup8gKuaf1S0g/Hbj8RbsT 8dqz3aICtlBl/DV/4NendUx68sXQxn+kMR/lmXFGhxq68F71g+/24nAfDDE4bZ7FFJU0UASjX /FpFD7RLi+U7z7KtYqEIVXh2paJx67rK67UlhoS8usSK+h5Y5RF3NLteiRRiDgLrzgzug/ipb NaNEIoD9a2W8ZuYKkm4mpmYKK3nwBXAinnrn5cQrA/HjhPLLmz6AP70ombGhKMzQBP66aJuHs fknIUTVxTLNTdQnCmJ4CIBY/yDOLAV2LKsvMYhJHHOTab++xVT5IAWhdCiY+mOTqsPADPnqz5 shrDug5vViZwvP0JJyJFeQ1gmDHUjqX3c04MogIy1BYKbQ1sl8= Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2018 15:17:28 -0000 On 2018-11-01 16:06, Petter Reinholdtsen wrote: > [Henrik Andersson] >> In short, don't use the "x-" prefix. And don't use the "x." prefix >> either. Those explicitly mean "not registered". The mentioned exception >> is a sad reality that only came to pass because of the insane costs to >> change it. There are no such costs here. > > So, if I understand you correctly, your recommendation is to use > text/diff or text/patch as the official registered MIME type? I am all > for a identifier with out the "x-" prefix. :-) > > I notice from my collection that text/x-diff have 27% higher use than > text/x-patch. If we are moving to a different identifier, I guess it do > not really matter which one of the old ones were most "popular". :) Make sure you have a well-defined payload format before discussing naming. Note that this also means thinking about character encoding... From nobody Sat Nov 3 06:33:12 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EF212D4E9 for ; Sat, 3 Nov 2018 06:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 5MjvTIHu84nm for ; Sat, 3 Nov 2018 06:33:06 -0700 (PDT) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA3512F1A6 for ; Sat, 3 Nov 2018 06:33:06 -0700 (PDT) Received: by mail-qk1-f170.google.com with SMTP id e4so7574115qkh.6 for ; Sat, 03 Nov 2018 06:33:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lF14ASP9pWha80kvObYmqb5jfRMmnzbvVLbmP3Ld55I=; b=mpnee8RpJRKWTedBOXQWgneXPSERZW4+V0OLxV4OmOqrpbxVkhxVnc9kpKHFryLd7X zCBq9KHoSI8LZln7e8tJGW+yquPygpE+pqcw+/C1/QSe8lGJoIMaBZfVMDqZNy1vJWJv kgLVAB0JIFDAGGzL6AeS5cCqBW45kZ5V0ZLMRePRCz+LA/3vzzrlfpZRk+4+FcxBoYc/ OQcIJ5V04CDEYLy44NHJEDEF/mZWeWlCk/dHmq1CC+KCcdjPFhwy9PFzU/quIkGU0H0A GzYndexbdm2RIO9mOAUdeKQKJ5rPJ0YsuCcWpHq087lSB2/8XXUzIeXHFQTOamESUNm2 dhPw== X-Gm-Message-State: AGRZ1gIDb7CTfMRKVL/b4VKCrQm1A8I/B1xl9xroais9R3KNT1d60vGn c5W5SUh6M9PZXwVZIwncOglensNBZW0bJY5yKx23og== X-Google-Smtp-Source: AJdET5eFIr+lOpoKAOPPNNVZkwBcr8ruiLn5/Xv0zCmaeNsjv/ajA2zjJ+NjCRKYEL8PJdpVH3GWQ2o5OPK1YX2xEzo= X-Received: by 2002:a37:848:: with SMTP id 69mr14177603qki.351.1541251985391; Sat, 03 Nov 2018 06:33:05 -0700 (PDT) MIME-Version: 1.0 References: <20181031102655.GI17721@w3.org> In-Reply-To: From: "Eric Prud'hommeaux" Date: Sat, 3 Nov 2018 09:32:53 -0400 Message-ID: To: henke@henke37.cjb.net Cc: pere@hungry.com, media-types@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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: Sat, 03 Nov 2018 13:33:09 -0000 On Thu, Nov 1, 2018 at 8:23 AM Henrik Andersson wrote: > > Eric Prud'hommeaux skrev: > > I think this negotiation must happen with the tool maintainers which > > currently recognize text/x-{patch,diff}. Given that that's probably > > impossible, the answer is almost certainly that you are stuck with > > "x-". Thanks for picking this up. > > > > I tried to answer your question but ended up puzzled by this text in > > [RFC6838]: > > [[ > > Note that types with names beginning with "x-" are no longer > > considered to be members of this tree (see [RFC6648]). Also note > > that if a generally useful and widely deployed type incorrectly ends > > up with an "x-" name prefix, it MAY be registered using its current > > name in an alternative tree by following the procedure defined in > > Appendix A. > > ]] > > > > The only "x-" subtree in [IMT] is "x-www-form-urlencoded", and maybe > > it's an exception. The tricky question is whether x-{diff,patch} > > deserve the same exception. On one hand, we don't want a slippery > > slope of exceptions, on the other hand, the tree's job is to document > > current or achievable reality. > > > > > > [RFC6838] https://tools.ietf.org/html/rfc6838#section-3.4 > > [IMT] https://www.iana.org/assignments/media-types/media-types.xhtml#application > > > In short, don't use the "x-" prefix. And don't use the "x." prefix > either. Those explicitly mean "not registered". The mentioned exception > is a sad reality that only came to pass because of the insane costs to > change it. There are no such costs here. That depends on the levers we have available. I was assuming that we can't change the deployed media type to get rid of the "x-". It appears that some of the tooling makes that not too problematic because it has infrustructure for aliases. I'm all in favor of getting rid of "x-" when possible. It's possible the right thing to do is to register all four (or maybe only one of text/{diff,patch} and gradually migrate the tooling (a non-trivial task as i've been seeing tools DTRT with patches for decades). A dual registration reflects both current and intended reality, which is arguably its purpose. -- -ericP office: +1.617.258.5741 mobile: +1.617.599.3509 From nobody Mon Nov 5 14:26:35 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B8B124D68 for ; Mon, 5 Nov 2018 14:26:34 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 d3yIcSAqyRNT for ; Mon, 5 Nov 2018 14:26:31 -0800 (PST) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D77124C04 for ; Mon, 5 Nov 2018 14:26:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 7F77F4002E; Mon, 5 Nov 2018 23:26:26 +0100 (CET) Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XDskbGLT4xKf; Mon, 5 Nov 2018 23:26:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 362204002F; Mon, 5 Nov 2018 23:26:24 +0100 (CET) X-Virus-Scanned: amavisd-new at bouvier.get.c.bitbit.net Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X9bs8BVXXa2x; Mon, 5 Nov 2018 23:26:24 +0100 (CET) Received: from hjemme.reinholdtsen.name (cm-84.212.222.24.getinternet.no [84.212.222.24]) by bouvier.getmail.no (Postfix) with SMTP id 050A94002E; Mon, 5 Nov 2018 23:26:24 +0100 (CET) Received: (nullmailer pid 17839 invoked by uid 10001); Mon, 05 Nov 2018 22:26:23 -0000 From: Petter Reinholdtsen To: media-types@ietf.org In-Reply-To: References: <20181031102655.GI17721@w3.org> Date: Mon, 05 Nov 2018 23:26:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [media-types] Mime type for patch files? X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:26:34 -0000 [Eric Prud'hommeaux] > That depends on the levers we have available. I was assuming that we > can't change the deployed media type to get rid of the "x-". It > appears that some of the tooling makes that not too problematic > because it has infrustructure for aliases. I'm all in favor of getting > rid of "x-" when possible. It's possible the right thing to do is to > register all four (or maybe only one of text/{diff,patch} and > gradually migrate the tooling (a non-trivial task as i've been seeing > tools DTRT with patches for decades). A dual registration reflects > both current and intended reality, which is arguably its purpose. I do not understand the way forward from here. Can someone who know the process bring some clarity? Who make decisions? Who are just making comments on the sideline? What am I supposed to do now to try to get a registered mime type for patches? -- Happy hacking Petter Reinholdtsen From nobody Sun Nov 25 23:59:02 2018 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD2E1294D0 for ; Sun, 25 Nov 2018 23:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MoO7IxEaFhdM for ; Sun, 25 Nov 2018 23:58:56 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625D3130DC7 for ; Sun, 25 Nov 2018 23:58:53 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id ADA67A3BA6C34 for ; Mon, 26 Nov 2018 07:58:48 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 26 Nov 2018 07:58:50 +0000 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.140]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Mon, 26 Nov 2018 15:58:40 +0800 From: "Roni Even (A)" To: "media-types@ietf.org" Thread-Topic: registeration of audio/video/text/application flexfec media subtypes Thread-Index: AdSCadb67+0YbePGTJW14ARj+KchGQ== Date: Mon, 26 Nov 2018 07:58:40 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18C809D7@dggemm526-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.166] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18C809D7dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [media-types] registeration of audio/video/text/application flexfec media subtypes X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2018 07:59:00 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18C809D7dggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, RTP payload formats for the Forward Error Correction (FEC) in https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11 = is ready for publication as a Payload WG document The document registers flexfec subtype The new registration is in Section 5.1 of the document and is also given be= low. Comments on the registration are welcome. Thanks. Roni Even Payload WG co-chair 5.1.1. Registration of audio/flexfec Type name: audio Subtype name: flexfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o L: indicates the number of columns of the source block that are protected by this FEC block and it applies to all the source SSRCs. L is a positive integer. o D: indicates the number of rows of the source block that are protected by this FEC block and it applies to all the source SSRCs. D is a positive integer. o ToP: indicates the type of protection applied by the sender: 0 for 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC protection, 2 for 2-D parity FEC protection, and 3 for retransmission. There can only be one value listed for ToP. Note that both L and D in the optional parameters should follow the value pairings stated in Section 4.2.2.2 if included. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC6838])= and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Fragment identifier considerations: None. Additional information: None. Person & email address to contact for further information: Varun Singh and IETF Audio/Video Transport Payloads Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Varun Singh . Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Provisional registration? (standards tree only): Yes. 5.1.2. Registration of video/flexfec Type name: video Subtype name: flexfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o L: indicates the number of columns of the source block that are protected by this FEC block and it applies to all the source SSRCs. L is a positive integer. o D: indicates the number of rows of the source block that are protected by this FEC block and it applies to all the source SSRCs. D is a positive integer. o ToP: indicates the type of protection applied by the sender: 0 for 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC protection, 2 for 2-D parity FEC protection, and 3 for retransmission. There can only be one value listed for ToP. Note that both L and D in the optional parameters should follow the value pairings stated in Section 4.2.2.2 if included. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC6838])= and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Fragment identifier considerations: None. Additional information: None. Person & email address to contact for further information: Varun Singh and IETF Audio/Video Transport Payloads Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Varun Singh . Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Provisional registration? (standards tree only): Yes. 5.1.3. Registration of text/flexfec Type name: text Subtype name: flexfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o L: indicates the number of columns of the source block that are protected by this FEC block and it applies to all the source SSRCs. L is a positive integer. o D: indicates the number of rows of the source block that are protected by this FEC block and it applies to all the source SSRCs. D is a positive integer. o ToP: indicates the type of protection applied by the sender: 0 for 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC protection, 2 for 2-D parity FEC protection, and 3 for retransmission. There can only be one value listed for ToP. Note that both L and D in the optional parameters should follow the value pairings stated in Section 4.2.2.2 if included. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC6838])= and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Fragment identifier considerations: None. Additional information: None. Person & email address to contact for further information: Varun Singh and IETF Audio/Video Transport Payloads Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Varun Singh . Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Provisional registration? (standards tree only): Yes. 5.1.4. Registration of application/flexfec Type name: application Subtype name: flexfec Required parameters: o rate: The RTP timestamp (clock) rate. The rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. However, it is RECOMMENDED to select the rate that matches the rate of the protected source RTP stream. o repair-window: The time that spans the source packets and the corresponding repair packets. The size of the repair window is specified in microseconds. Optional parameters: o L: indicates the number of columns of the source block that are protected by this FEC block and it applies to all the source SSRCs. L is a positive integer. o D: indicates the number of rows of the source block that are protected by this FEC block and it applies to all the source SSRCs. D is a positive integer. o ToP: indicates the type of protection applied by the sender: 0 for 1-D interleaved FEC protection, 1 for 1-D non-interleaved FEC protection, 2 for 2-D parity FEC protection, and 3 for retransmission. There can only be one value listed for ToP. Note that both L and D in the optional parameters should follow the value pairings stated in Section 4.2.2.2 if included. Encoding considerations: This media type is framed (See Section 4.8 in the template document [RFC6838])= and contains binary data. Security considerations: See Section 9 of [RFCXXXX]. Interoperability considerations: None. Published specification: [RFCXXXX]. Applications that use this media type: Multimedia applications that want to improve resiliency against packet loss by sending redundant data in addition to the source media. Fragment identifier considerations: None. Additional information: None. Person & email address to contact for further information: Varun Singh and IETF Audio/Video Transport Payloads Working Group. Intended usage: COMMON. Restriction on usage: This media type depends on RTP framing, and hence, is only defined for transport via RTP [RFC3550]. Author: Varun Singh . Change controller: IETF Audio/Video Transport Working Group delegated from the IESG. Provisional registration? (standards tree only): Yes. --_000_6E58094ECC8D8344914996DAD28F1CCD18C809D7dggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
 
Hi,

RTP payload formats for = the Forward Error Correction (FEC)

in https://tools.ietf.org/html/draft-= ietf-payload-flexible-fec-scheme-11    is ready for publication as a Payload WG document

 
The document registers flexfec subtype
The new registration is in Section 5.1 of the document and is also give=
n below.
 
Comments on the registration are welcome.
 
Thanks.
 
Roni Even
 
Payload WG co-chair

 

 


5.1.1.  Registration of audio/flexfec

   Type name: audio

 

   Subtype name: flexfec<= /span>

 

   Required parameters:

 

   o  rate: The RTP timestamp (= clock) rate.  The rate SHALL be larger

      than 1000 Hz to= provide sufficient resolution to RTCP operations.

      However, it is = RECOMMENDED to select the rate that matches the

      rate of the pro= tected source RTP stream.

 

   o  repair-window: The time t= hat spans the source packets and the

      corresponding r= epair packets.  The size of the repair window is

      specified in mi= croseconds.

 

   Optional parameters:

 

   o  L: indicates the number o= f columns of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  L = is a positive integer.

 

   o  D: indicates the number o= f rows of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  D = is a positive integer.

 

   o  ToP: indicates the type o= f protection applied by the sender: 0 for

      1-D interleaved= FEC protection, 1 for 1-D non-interleaved FEC

      protection, 2 f= or 2-D parity FEC protection, and 3 for

      retransmission.=   There can only be one value listed for ToP.

 

   Note that both L and D in the opt= ional parameters should follow the

   value pairings stated in Section 4.2.2.2 if included.

 

   Encoding considerations: This med= ia type is framed (See Section 4.8

   in the template document [RFC6838]) and contains binary data.

 

   Security considerations: See Section 9 of [RFCXXXX].

 

   Interoperability considerations: = None.

 

   Published specification: [RFCXXXX= ].

 

   Applications that use this media = type: Multimedia applications that

   want to improve resiliency agains= t packet loss by sending redundant

   data in addition to the source me= dia.

 

   Fragment identifier consideration= s: None.

 

   Additional information: None.

 

   Person & email address to con= tact for further information: Varun

   Singh <varun@callstats.io> = and IETF Audio/Video Transport Payloads

   Working Group.<= /p>

   Intended usage: COMMON.

 

   Restriction on usage: This media = type depends on RTP framing, and

   hence, is only defined for transp= ort via RTP [RFC3550].<= o:p>

 

   Author: Varun Singh <varun@cal= lstats.io>.

 

   Change controller: IETF Audio/Vid= eo Transport Working Group delegated

   from the IESG.<= /p>

 

   Provisional registration? (standa= rds tree only): Yes.

 

5.1.2.  Registration of video/flexfec

   Type name: video

 

   Subtype name: flexfec<= /span>

 

  Required parameters:

 

   o  rate: The RTP timestamp (= clock) rate.  The rate SHALL be larger

      than 1000 Hz to= provide sufficient resolution to RTCP operations.

      However, it is = RECOMMENDED to select the rate that matches the

      rate of the pro= tected source RTP stream.

 

   o  repair-window: The time t= hat spans the source packets and the

      corresponding r= epair packets.  The size of the repair window is

      specified in mi= croseconds.

 

   Optional parameters:

 

   o  L: indicates the number o= f columns of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  L = is a positive integer.

 

   o  D: indicates the number o= f rows of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  D = is a positive integer.

 

   o  ToP: indicates the type o= f protection applied by the sender: 0 for

      1-D interleaved= FEC protection, 1 for 1-D non-interleaved FEC

      protection, 2 f= or 2-D parity FEC protection, and 3 for

      retransmission.=   There can only be one value listed for ToP.

 

   Note that both L and D in the opt= ional parameters should follow the

   value pairings stated in Section 4.2.2.2 if included.

 

   Encoding considerations: This med= ia type is framed (See Section 4.8

   in the template document [RFC6838]) and contains binary data.

 

   Security considerations: See Section 9 of [RFCXXXX].

 

   Interoperability considerations: = None.

 

   Published specification: [RFCXXXX= ].

 

   Applications that use this media = type: Multimedia applications that

   want to improve resiliency agains= t packet loss by sending redundant

   data in addition to the source me= dia.

 

   Fragment identifier consideration= s: None.

 

   Additional information: None.

 

   Person & email address to con= tact for further information: Varun

   Singh <varun@callstats.io> = and IETF Audio/Video Transport Payloads

   Working Group.<= /p>

 

   Intended usage: COMMON.

 

   Restriction on usage: This media = type depends on RTP framing, and

   hence, is only defined for transp= ort via RTP [RFC3550].<= o:p>

 

   Author: Varun Singh <varun@cal= lstats.io>.

 

   Change controller: IETF Audio/Vid= eo Transport Working Group delegated

   from the IESG.<= /p>

 

   Provisional registration? (standa= rds tree only): Yes.

 

 

5.1.3.  Registration of text/flexfec

   Type name: text=

 

   Subtype name: flexfec<= /span>

 

   Required parameters:

 

   o  rate: The RTP timestamp (= clock) rate.  The rate SHALL be larger

      than 1000 Hz to= provide sufficient resolution to RTCP operations.

      However, it is = RECOMMENDED to select the rate that matches the

      rate of the pro= tected source RTP stream.

 

   o  repair-window: The time t= hat spans the source packets and the

      corresponding r= epair packets.  The size of the repair window is

      specified in mi= croseconds.

 

   Optional parameters:

 

   o  L: indicates the number o= f columns of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  L = is a positive integer.

 

   o  D: indicates the number o= f rows of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  D = is a positive integer.

 

   o  ToP: indicates the type o= f protection applied by the sender: 0 for

      1-D interleaved= FEC protection, 1 for 1-D non-interleaved FEC

      protection, 2 f= or 2-D parity FEC protection, and 3 for

      retransmission.=   There can only be one value listed for ToP.

 

   Note that both L and D in the opt= ional parameters should follow the

   value pairings stated in Section 4.2.2.2 if included.

 

   Encoding considerations: This med= ia type is framed (See Section 4.8

   in the template document [RFC6838]) and contains binary data.

 

   Security considerations: See Section 9 of [RFCXXXX].

 

   Interoperability considerations: = None.

 

   Published specification: [RFCXXXX= ].

 

   Applications that use this media = type: Multimedia applications that

   want to improve resiliency agains= t packet loss by sending redundant

   data in addition to the source me= dia.

 

 

   Fragment identifier consideration= s: None.

 

   Additional information: None.

 

   Person & email address to con= tact for further information: Varun

   Singh <vvarun@callstats.io>= and IETF Audio/Video Transport Payloads

   Working Group.<= /p>

 

   Intended usage: COMMON.

 

   Restriction on usage: This media = type depends on RTP framing, and

   hence, is only defined for transp= ort via RTP [RFC3550].<= o:p>

 

   Author: Varun Singh <varun@cal= lstats.io>.

 

   Change controller: IETF Audio/Vid= eo Transport Working Group delegated

   from the IESG.<= /p>

 

   Provisional registration? (standa= rds tree only): Yes.

 

5.1.4.  Registration of application/flexfec

   Type name: application=

 

   Subtype name: flexfec<= /span>

 

   Required parameters:

 

   o  rate: The RTP timestamp (= clock) rate.  The rate SHALL be larger

      than 1000 Hz to= provide sufficient resolution to RTCP operations.

      However, it is = RECOMMENDED to select the rate that matches the

      rate of the pro= tected source RTP stream.

 

   o  repair-window: The time t= hat spans the source packets and the

      corresponding r= epair packets.  The size of the repair window is

      specified in mi= croseconds.

 

   Optional parameters:

 

   o  L: indicates the number o= f columns of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  L = is a positive integer.

 

   o  D: indicates the number o= f rows of the source block that are

      protected by th= is FEC block and it applies to all the source

      SSRCs.  D = is a positive integer.

 

   o  ToP: indicates the type o= f protection applied by the sender: 0 for

      1-D interleaved= FEC protection, 1 for 1-D non-interleaved FEC

      protection, 2 f= or 2-D parity FEC protection, and 3 for

      retransmission.=   There can only be one value listed for ToP.

 

   Note that both L and D in the opt= ional parameters should follow the

   value pairings stated in Section 4.2.2.2 if included.

 

   Encoding considerations: This med= ia type is framed (See Section 4.8

   in the template document [RFC6838]) and contains binary data.

 

   Security considerations: See Section 9 of [RFCXXXX].

 

   Interoperability considerations: = None.

 

   Published specification: [RFCXXXX= ].

 

   Applications that use this media = type: Multimedia applications that

   want to improve resiliency agains= t packet loss by sending redundant

   data in addition to the source me= dia.

 

   Fragment identifier consideration= s: None.

 

   Additional information: None.

 

   Person & email address to con= tact for further information: Varun

   Singh <varun@callstats.io> = and IETF Audio/Video Transport Payloads

   Working Group.<= /p>

 

   Intended usage: COMMON.

 

   Restriction on usage: This media = type depends on RTP framing, and

   hence, is only defined for transp= ort via RTP [RFC3550].<= o:p>

 

   Author: Varun Singh <varun@cal= lstats.io>.

 

   Change controller: IETF Audio/Vid= eo Transport Working Group delegated

   from the IESG.<= /p>

 

   Provisional registration? (standa= rds tree only): Yes.

 

--_000_6E58094ECC8D8344914996DAD28F1CCD18C809D7dggemm526mbxchi_--