[Cellar] draft IANA Considerations section for FFV1
Dave Rice <dave@dericed.com> Sun, 04 February 2018 17:05 UTC
Return-Path: <dave@dericed.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C0212762F for <cellar@ietfa.amsl.com>; Sun, 4 Feb 2018 09:05:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 QbNBJLXdWC6z for <cellar@ietfa.amsl.com>; Sun, 4 Feb 2018 09:05:36 -0800 (PST)
Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (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 04D1E1275C5 for <cellar@ietf.org>; Sun, 4 Feb 2018 09:05:33 -0800 (PST)
Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:34276 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from <dave@dericed.com>) id 1eiNjP-002A74-Rw for cellar@ietf.org; Sun, 04 Feb 2018 12:05:33 -0500
From: Dave Rice <dave@dericed.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5A5972D-4BD4-487C-B88E-5840DB0A1306"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <480D5A6E-0001-49D8-BF73-E6B65EC12A37@dericed.com>
Date: Sun, 04 Feb 2018 12:05:24 -0500
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
X-Mailer: Apple Mail (2.3445.4.7)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/GhGqtvwTiePx0GOiqH1z9QXQvsY>
Subject: [Cellar] draft IANA Considerations section for FFV1
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Feb 2018 17:05:39 -0000
Hi cellar, The IANA Considerations section is one of remaining requirements for the FFV1 draft. I’ve updated this pull request with an update on that which also adds a Media Type Definition section per RFC6838 and RFC4855. Here’s the rendering of my draft which is also reviewable in https://github.com/FFmpeg/FFV1/pull/71 <https://github.com/FFmpeg/FFV1/pull/71>. Comments welcome as this is my first attempt at an IETF Media Type Definition. 7. Media Type Definition This registration is done using the template defined in [RFC6838] and following [RFC4855]. Type name: video Subtype name: FFV1 Required parameters: None. Optional parameters: This parameter is used to signal the capabilities of a receiver implementation. This parameter MUST NOT be used for any other purpose. version: The version of the FFV1 encoding as defined by Section 4.8.1. Encoding considerations: This media type is defined for encapsulation in several audiovisual container formats and contains binary data; see Section 4.1.3. This media type is framed binary data Section 4.8 of [RFC4288]. Security considerations: See Section 6 of RFC xxxx. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.] Interoperability considerations: None. Published specification: [I-D.ietf-cellar-ffv1] and RFC XXXX. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.] Applications which use this media type: Any application that requires the transport of lossless video can use this media type. Some examples are, but not limited to screen recording, scientific imaging, and digital video preservation. Fragment identifier considerations: N/A. Additional information: None. Person & email address to contact for further information: TODO [Pick a contact] Intended usage: COMMON Restrictions on usage: None. Author: TODO [Pick a contact] Change controller: IETF cellar working group delegated from the IESG. 8. IANA Considerations The IANA is requested to register the following values: • Media type registration as described in Section 7. Kind Regards, Dave Rice