--- video-codec-charter-20120924.txt	2013-01-01 21:59:28.530611669 -0800
+++ video-codec-charter-20130101.txt	2013-01-01 22:11:37.726358250 -0800
@@ -16,9 +16,15 @@
 
 There exist codecs that provide high quality encoding of video
 information, but that are not optimized for the actual conditions of the
-Internet; according to reports, this mismatch between design and
-deployment has hindered interoperability of such codecs in interactive
-Internet applications.
+public, consumer-level, best-effort Internet. Such optimizations might
+include fast and flexible congestion control, such as the ability to
+change resolution without sending a keyframe; a simple means of handling
+packet loss in the face of reference frame re-ordering; the ability to
+join broadcast streams without waiting for a keyframe; special coding
+tools for screen captures to support remote services and desktop
+sharing; and many more. According to reports, this mismatch between
+design and deployment has hindered performance and interoperability of
+such codecs in Internet applications.
 
 There exist codecs that can be widely implemented, but were not
 developed under the IPR rules of any SDO; according to reports, the lack
@@ -47,9 +53,10 @@
 high-quality video codec that can be widely implemented and easily
 distributed among application developers, service operators, and end
 users. At present it appears that ensuring the existence of such a
-codec will require a development effort within the working group. The
-core technical considerations for such a codec include, but are not
-necessarily limited to, the following:
+codec will require a development effort within the working group.
+
+The core technical considerations for such a codec include, but
+are not necessarily limited to, the following:
 
 1. Designing for use in interactive applications (examples include, but
 are not limited to, point-to-point video calls, multi-party video
@@ -65,32 +72,36 @@
 
 4. Ensuring interoperability with Internet signaling technologies such
 as Session Initiation Protocol (SIP), Session Description Protocol
-(SDP), and Extensible Messaging and Presence Protocol (XMPP); however,
+(SDP), and Extensible Messaging and Presence Protocol (XMPP). However,
 the result should not depend on the details of any particular signaling
 technology.
 
+5. Ensuring suitability for use in Internet applications and Web APIs,
+such as the HTML5 <video> tag, live streaming (e.g., via icecast),
+adaptive streaming (e.g., Dynamic Adaptive Streaming over HTTP (DASH),
+HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC APIs,
+proposed web recording APIs, and so on. However, the result should not
+depend on the details of any particular API.
+
 Optimizing for very low bit rates (typically below 64 kbps) is out of
 scope because such work might necessitate specialized optimizations.
 
 In addition to the technical objectives, there is one process goal,
 which is
 
-5. Ensuring the work is done under the IPR rules of the IETF.
+6. Ensuring the work is done under the IPR rules of the IETF.
 
 Although a codec produced by this working group or another standards
 organization might be used as a mandatory-to-implement technology by
 designers of particular Internet protocols, it is explicitly not a goal
-of the working group to produce or select a codec that will be mandated
-for use across the entire IETF or Internet community nor would their be
-any expectation that this would be the only mandatory-to-implement
-codec.
+of the working group to produce a codec that will be mandated for use
+across the entire IETF or Internet community nor would their be any
+expectation that this would be the only mandatory-to-implement codec.
 
 Based on the working group's analysis of the design space, the working
-group might determine that it needs to produce more than one codec, or
-a codec with multiple modes; however, it is not the goal of working
-group to produce more than one codec, and to reduce confusion in the
-marketplace the working group shall endeavor to produce as few codecs
-as possible.
+group might determine that it needs to produce a codec with multiple
+modes of operation. However, it is not the goal of working group
+to produce more than one codec.
 
 In completing its work, the working group should collaborate with other
 IETF working groups to complete particular tasks. These might include,
@@ -118,20 +129,21 @@
 
 The working group will coordinate with the ITU-T (Study group 16) and
 ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed
-codec RFC for co-publication if they find that appropriate. The working
-group will communicate a detailed description of the requirements and
-goals to other SDOs including the ITU-T and MPEG to help determine if
-existing codecs meet the requirements and goals. Information about
-codecs being standardized will be available to other SDOs in the form
-of Internet-Drafts and the working group welcomes technical feedback
-from other SDOs and experts from other organizations.
+codec RFC for co-publication by the ITU-T and ISO if they find that
+appropriate. Information about codecs being standardized, including a
+detailed description of the requirements and goals, will be available
+to other SDOs in the form of Internet-Drafts and the working group
+welcomes technical feedback from other SDOs and experts from other
+organizations.
 
 The Guidelines for Development of an Audio Codec within the IETF (RFC
 6569) will form the starting point for guidelines and requirements for
 achieving the forgoing objectives for video. The working group will
-modify them as necessary with lessons learned during that process,
-refining them into a new document in accordance with the usual IETF
-procedures once consensus has been achieved.
+modify them as necessary with lessons learned during that process (for
+example, specifying the use of English text as the normative definition
+of the codec instead of source code), refining them into a new document
+in accordance with the usual IETF procedures once consensus has been
+achieved.
 
 A codec that can be widely implemented and easily distributed among
 application developers, service operators, and end users is preferred.
@@ -156,7 +168,10 @@
 explicitly rule out the possibility of adopting encumbered technologies;
 however, the working group will try to avoid encumbered technologies
 that require royalties or other encumbrances that would prevent such
-technologies from being easy to redistribute and use.
+technologies from being easy to redistribute and use. The working group
+should not proceed with publication of a codec RFC if there is consensus
+that it cannot "be widely implemented and easily distributed among
+application developers, service operators, and end users."
 
 Deliverables
 
@@ -167,16 +182,24 @@
 Informational.
 
 3. Specification of a codec that meets the agreed-upon requirements, in
-the form of an Internet-Draft that defines the codec algorithm along
-with source code for a reference implementation. The text description
-of the codec shall describe the mandatory, recommended, and optional
-portions of the encoder and decoder. It is envisioned that this
+the form of an Internet-Draft that defines the codec algorithm. The text
+description of the codec shall describe the mandatory, recommended, and
+optional portions of the encoder and decoder. It is envisioned that this
 document shall be a Proposed Standard document.
 
-4. Specification of a storage format for non-interactive (HTTP)
-streaming or file transfer of the codec. It is envisioned that this
+4. A reference implementation of a software encoder and decoder. This
+will be in a separate document from the text description to allow it to
+be updated independently. It does not need to be standards-track.
+
+5. Specification of a storage format for file transfer of the codec,
+to support non-interactive (HTTP) streaming, including live encoding
+and both progressive and chunked downloads. It is envisioned that this
 document shall be a Proposed Standard document.
 
+6. A collection of test results, either from tests conducted by the
+working group or made publicly available elsewhere, characterizing the
+performance of the codec. This document shall be informational.
+
 Goals and Milestones
 TBD  WGLC on codec standardization guidelines
 TBD  WGLC on requirements, liaise to other SDOs
@@ -184,7 +207,9 @@
 TBD  Liaise requirements RFC to other SDOs
 TBD  Codec standardization guidelines to IESG (Informational)
 TBD  WGLC on codec specification, liaise to other SDOs
+TBD  WGLC on reference implementation, liaise to other SDOs
 TBD  Submit codec specification to IESG (Standards Track)
+TBD  Submit reference implementation to IESG (Informational)
 TBD  WGLC on storage format specification
 TBD  Submit storage format specification to IESG (Standards Track)
 TBD  WGLC on Testing document