idnits 2.17.1 draft-valin-codec-guidelines-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3979 (ref. 'IPR') (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 3356 (ref. 'COLLAB') (Obsoleted by RFC 6756) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JM. Valin 3 Internet-Draft Octasic Inc. 4 Intended status: Standards Track S. Borilin 5 Expires: April 28, 2011 SPIRIT DSP 6 K. Vos 7 Skype Technologies S.A. 8 C. Montgomery 9 Xiph.Org Foundation 10 R. Chen 11 Broadcom Corporation 12 October 25, 2010 14 Guidelines for the Codec Development Within the IETF 15 draft-valin-codec-guidelines-08 17 Abstract 19 This document provides general guidelines for work on developing and 20 specifying a codec within the IETF. These guidelines cover the 21 development process, evaluation, requirements conformance, and 22 intellectual property issues. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Development Process . . . . . . . . . . . . . . . . . . . . . 4 60 3. Evaluation, Testing, and Characterization . . . . . . . . . . 7 61 4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 8 62 5. Intellectual Property . . . . . . . . . . . . . . . . . . . . 10 63 6. Relationship with Other SDOs . . . . . . . . . . . . . . . . . 12 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 69 10.2. Informative References . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 72 1. Introduction 74 This document describes a suggested process for work at the IETF on 75 standardization of a codec that is optimized for use in interactive 76 Internet applications and that can be widely implemented and easily 77 distributed among application developers, service operators, and end 78 users. 80 2. Development Process 82 The process outlined here is intended to make the work on an audio 83 codec within the IETF transparent, predictable, and well organized. 84 Such work might involve development of a completely new codec, 85 adaptation of an existing codec to meet the requirements, or 86 integration between two or more existing codecs that results in an 87 improved codec combining the best aspects of each codec. To enable 88 such procedural transparency, the contributor of an existing codec 89 must be willing to cede change control to the IETF and should have 90 sufficient knowledge of the codec to assist in the work of adapting 91 it or applying some of its technology to the development or 92 improvemnet of other codecs. Furthermore, contributors need to be 93 aware that any codec that results from work within the IETF is likely 94 to be different from any existing codec that was contributed to the 95 Internet Standards Process. 97 Work on codec development is expected to proceed as follows: 99 1. IETF participants will identify the requirements to be met by an 100 Internet codec, in the form of an Internet-Draft. 102 2. Interested parties are encouraged to make contributions proposing 103 existing or new codecs, or elements thereof, to the codec WG as 104 long as these contributions are within the scope of the WG. 105 Ideally, these contributions should be in the form of Internet 106 Drafts, although other forms of contributions are also possible 107 as discussed in [PROCESS] and in the IETF's Note Well. As 108 always, contributions to the IETF are subject, among other 109 process oriented RFCs, to [PROCESS], [TRUST], and [IPR]. 110 Considering the field of technology, IPR transparency may be 111 particularly high on the priority list of many codec WG 112 participants. Accordingly, contributors are specifically 113 reminded of their IPR disclosure requirement, and all 114 participants are reminded of the solicitation of the disclosure 115 of third party IPR, both as codified in [IPR]. 117 3. As contributions are received and discussed within the working 118 group, the group should gain a clearer understanding of what is 119 achievable within the design space. As a result, the authors of 120 the requirements document should iteratively clarify and improve 121 their document to reflect the emerging working group consensus. 122 This is likely to involve collaboration with IETF working groups 123 in other areas, such as collaboration with working groups in the 124 Transport area to identify important aspects of packet 125 transmission over the Internet and to understand the degree of 126 rate adaptation desirable, and with working groups in the RAI 127 area to ensure that information about and negotiation of the 128 codec can be easily represented at the signalling layer. In 129 parallel with this work, interested parties should evaluate the 130 contributions at a higher level to see which requirements might 131 be met by each codec. 133 4. Once a sufficient number of proposals has been received, the 134 interested parties will identify the strengths, weaknesses, and 135 innovative aspects of the contributed codecs. This step will 136 consider not only the codecs as a whole, but also key features of 137 the individual algorithms (predictors, quantizers, transforms, 138 etc.). 140 5. It is expected that none of the contributed codecs will meet all 141 of the defined requirements. Therefore, it is expected that IETF 142 participants will accept a _baseline codec_ as a WG item to 143 facilitate the development process. This baseline codec will 144 meet as many of the requirements as possible, but probably will 145 need to be adjusted through an iterative development process in 146 order to meet all of the requirements (or as many requirements as 147 possible). The baseline codec might be one of the contributed 148 codecs (especially if it is the only codec that meets most of the 149 requirements), a combination of two or more of the contributed 150 codecs, or an entirely new codec. None of the decisions taken at 151 this step will be definitive. In particular, IETF participants 152 will not provide a "rubber stamp" for any contributed codec. 154 6. IETF participants should then attempt to iteratively improve each 155 component of the baseline codec reference implementation, where 156 by "component" we mean individual algorithms such as predictors, 157 transforms, quantizers, and entropy coders. The participants 158 should proceed by trying new designs, applying ideas from the 159 contributed codecs, evaluating "proof of concept" ideas, and 160 using their expertise in codec development to improve the 161 baseline codec. Any aspect of the baseline codec might be 162 changed (even the fundamental principles of the codec) or the 163 participants might start over entirely by scrapping the baseline 164 codec and designing a completely new one. The overriding goal 165 shall be to design a codec that will meet the requirements 166 defined in the requirements document. Given the IETF's open 167 standards process, any interested party will be able to 168 contribute to this work, whether or not they submitted an 169 Internet-Draft for one of the contributed codecs. The codec 170 itself should be normatively specified with code in an Internet- 171 Draft. 173 7. In parallel with work on the codec reference implementation, 174 developers and other interested parties should perform evaluation 175 of the codec as described under Section 3, IETF participants 176 should define (within the AVT Working Group) the codec's payload 177 format for use with the Real-time Transport Protocol [RTP], and 178 application developers should start testing the codec by 179 implementing it in code and deploying it in actual Internet 180 applications to identify any potential problems. 182 8. Once IETF participants agree that the codec being developed meets 183 the requirements, IETF participants can begin the task of 184 characterizing the codec. The characterization process is 185 described under Section 3. 187 3. Evaluation, Testing, and Characterization 189 Lab evaluation of the codec being developed should happen throughout 190 the development process because it will help ensure that progress is 191 being made toward fulfillment of the requirements. There are many 192 ways in which continuous evaluation can be performed. For minor, 193 uncontroversial changes to the codec it should usually be sufficient 194 to use objective measurements (e.g., PESQ, PEAQ, and SegSNR) 195 validated by informal subjective evaluation. For more complex 196 changes (e.g., when psychoacoustic aspects are involved) or for 197 controversial issues, internal testing should be performed. An 198 example of internal testing would be to have individual participants 199 rate the decoded samples using one of the established testing 200 methodologies, such as ITU-R BS.1534 (MUSHRA). 202 Throughout the process, it will be important to make use of the 203 Internet community at large for real-world distributed testing. This 204 will enable many different people with different equipment and use 205 cases to test the codec and report any problems they experience. In 206 the same way, third-party software developers will be encouraged to 207 integrate the codec (with a warning about the bit-stream not being 208 final) and provide feedback on its performance in real-world use 209 cases. 211 Characterization of the final codec must be based on the reference 212 implementation only (and not on any "private implementation"). This 213 can be performed by independent testing labs or, if this is not 214 possible, using the testing labs of the organizations that contribute 215 to the Internet Standards Process. Packet loss robustness should be 216 evaluated using actual loss patterns collected from use over the 217 Internet, rather than theoretical models. The goals of the 218 characterization phase are to: 220 o ensure that the requirements have been fulfilled 222 o guide the IESG in its evaluation of the resulting work 224 o assist application developers in understanding whether the codec 225 is suitable for a particular application 227 The exact methodology for the characterization phase is still subject 228 to discussion within the working group. 230 4. Requirements Conformance 232 It is the responsibility of the working group to define criteria for 233 evaluating conformance, including but not limited to comparison tools 234 and test vectors. The following text provides suggestions for 235 consideration by the working group: 237 1. Any codec specified by the IETF must include source code for a 238 normative C89 implementation, documented in an Internet Draft 239 destined for standards track RFC. This implementation will be 240 used to verify conformance of an implementation. Although a text 241 description of the algorithm should be provided, its use should 242 be limited to helping the reader in understanding the source 243 code. Should the description contradict the source code, the 244 latter shall take precedence. For convenience, the source code 245 may be provided in compressed form, with base64 encoding. 247 2. Because of the size of the codec's source code, it is possible 248 that even after publishing the RFC, bugs would be found from time 249 to time. An errata of the RFC and its software description 250 should be maintained, along with a public software repository 251 containing the current reference implementation. 253 3. It is the intention of the group to allow the greatest possible 254 choice of freedom in implementing the specification. 255 Accordingly, the number of binding RFC2119 keywords is going to 256 be the minimum still allowing for interopable implementations. 257 In practice this generally means that only the decoder needs to 258 be normative, so that the encoder can improve over time. This 259 also enables different tradeoffs between quality and complexity. 261 4. To reduce the risk of bias towards certain CPU/DSP architectures, 262 ideally the decoder specification should not require "bit-exact" 263 conformance with the reference implementation. The output of a 264 decoder implementation should only be "close enough" to the 265 output of the reference decoder. A comparison tool should be 266 provided along with the codec to verify objectively that the 267 output of a decoder is likely to be perceptually 268 indistinguishable from that of the reference decoder. However, 269 an implementation may still wish to produce an output that is 270 bit-exact with the reference implementation to simplify the 271 testing procedure. 273 5. To ensure freedom of implementation, decoder-side only error 274 concealment does not need to be specified, although the reference 275 implementation should include the same PLC algorithm as used in 276 the testing phase. Is it up to the working group to decide 277 whether minimum requirements on PLC quality will be required for 278 compliance with the specification. Obviously, any information 279 signaled in the bitstream intended to aid PLC needs to be 280 specified. 282 6. An encoder implementation should not be required to make use of 283 all the "features" (tools) in the bit-stream definition. 284 However, the codec specification may require that an encoder 285 implementation be able to generate any possible bit-rate. Unless 286 a particular "profile" is defined in the specification, the 287 decoder must be able to decode all features of the bit-stream. 288 The decoder must also be able to handle any combination of bits, 289 even combinations that cannot be generated by the reference 290 encoder. It is recommended that the decoder specification shall 291 define exactly how the decoder should react to "impossible" 292 packets. However, an encoder must never generate such packets 293 that do not conform to the bit-stream definition. 295 7. Compressed test vectors should be provided as a means to verify 296 conformance with the decoder specification. These test vectors 297 should exercise all paths in the decoder (100% code coverage). 299 8. While the exact encoder will not be specified, it is recommended 300 to specify objective measurement targets for an encoder, below 301 which use of a particular encoder implementation is not 302 recommended. For example, one such specification could be: "the 303 use of an encoder whose PESQ MOS is less than 0.1 below the 304 reference encoder in the following conditions is not 305 recommended". 307 5. Intellectual Property 309 Producing an unencumbered codec is desirable for the following 310 reasons: 312 o It is the experience of a wide variety of application developers 313 and service providers that encumbrances such as licensing and 314 royalties make it difficult to implement, deploy, and distribute 315 audio applications for use by the Internet community. 317 o It is beneficial to have low-cost options whenever possible 318 because standalone voice services are being commoditized and 319 small, innovative development teams often cannot afford to pay 320 per-channel licensing fees and royalties. 322 o Many market segments are moving away from selling hard-coded 323 hardware devices and toward freely distributing end-user software; 324 this is true of numerous large application providers and even 325 telcos themselves. 327 o Compatibility with the licensing of typical open source 328 applications implies the need to avoid encumbrances, including 329 even the requirement to obtain a license for implementation, 330 deployment, or use (even if the license does not require the 331 payment of a fee). 333 Therefore, a codec that can be widely implemented and easily 334 distributed among application developers, service operators, and end 335 users is preferred. Many existing codecs that might fulfill some or 336 most of the technical attributes listed above are encumbered in 337 various ways. For example, patent holders might require that those 338 wishing to implement the codec in software, deploy the codec in a 339 service, or distribute the codec in software or hardware need to 340 request a license, enter into a business agreement, pay licensing 341 fees or royalties, or adhere to other special conditions or 342 restrictions. Because such encumbrances have made it difficult to 343 widely implement and easily distribute high-quality audio codecs 344 across the entire Internet community, the working group prefers 345 unencumbered technologies in a way that is consistent with BCP 78 and 346 BCP 79. In particular, the working group shall heed the preference 347 stated in BCP 79: "In general, IETF working groups prefer 348 technologies with no known IPR claims or, for technologies with 349 claims against them, an offer of royalty-free licensing." Although 350 this preference cannot guarantee that the working group will produce 351 an unencumbered codec, the working group shall follow BCP 79, and 352 adhere to the spirit of BCP 79. The working group cannot explicitly 353 rule out the possibility of adopting encumbered technologies; 354 however, the working group will try to avoid encumbered technologies 355 that require royalties or other encumbrances that would prevent such 356 technologies from being easy to redistribute and use. 358 The following guidelines will help to maximize the odds that the 359 codec will be unencumbered: 361 1. In accordance with BCP 79 [IPR], contributed codecs should 362 preferably use technologies with no known IPR claims or 363 technologies with an offer of royalty-free (RF) licensing. 365 2. Whenever possible, the working group should use technologies that 366 are perceived by the participants to be safer with regard to IPR 367 issues. 369 3. Contributors must disclose IPR as specified in BCP 79. 371 4. In cases where no RF license can be obtained regarding a patent, 372 the group should consider alternative algorithms or methods, even 373 if they result in lower quality, higher complexity, or otherwise 374 less desirable characteristics (in most cases, the degradation 375 will likely be small once the best alternative has been 376 identified). 378 5. In accordance with BCP 78 [TRUST], the source code for the 379 reference implementation must be made available under a BSD-style 380 license (or whatever license is defined as acceptable by the IETF 381 Trust when the Internet-Draft defining the reference 382 implementation is published). 384 IETF participants should be aware that, given the way patents work in 385 most countries, the resulting codec can never be guaranteed to be 386 free of patent claims because some patents may not be known to the 387 contributors, some patent applications may not be disclosed at the 388 time the codec is developed, and only courts of law can determine the 389 validity and breadth of patent claims. However, these observations 390 are no different within the Internet Standards Process than they are 391 for standardization of codecs within other SDOs (or development of 392 codecs outside the context of any SDO), and furthermore are no 393 different for codecs than for other technologies worked on within the 394 IETF. In all these cases, the best approach is to minimize the risk 395 of unknowingly incurring encrumbrance on existing patents. Despite 396 these precautions, participants need to understand that, practically 397 speaking, it is nearly impossible to _guarantee_ that implementors 398 will not incur encumbrance on existing patents. 400 6. Relationship with Other SDOs 402 It is understood that other SDOs are also involved in the codec 403 development and standardization, including but not necessarily 404 limited to: 406 o The Telecommunication Standardization Sector (ITU-T) of the 407 International Telecommunication Union (ITU), in particular Study 408 Group 16 410 o The Moving Picture Experts Group (MPEG) 412 o The European Telecommunications Standards Institute (ETSI) 414 o The 3rd Generation Partnership Project (3GPP) 416 o The 3rd Generation Partnership Project 2 (3GPP2) 418 It is important to ensure that such work does not constitute 419 uncoordinated protocol development, of the kind described in 420 [UNCOORD] in the following principle: 422 [T]he IAB considers an essential principle of the protocol 423 development process that only one SDO maintains design authority 424 for a given protocol, with that SDO having ultimate authority over 425 the allocation of protocol parameter code-points; defining the 426 intended semantics, interpretation, and actions associated with 427 those code-points. 429 The work envisioned by this guidelines document is not 430 "uncoordinated" in the sense described in the foregoing quote, for 431 the following reasons: 433 o Internet signalling technologies are designed to enable the 434 negotiation of any codecs that are supported in a particular 435 application (such signalling technologies include the Session 436 Initiation Protocol [SIP], Session Description Protocol [SDP], and 437 the Extensible Messaging and Presence Protocol [XMPP] extensions 438 for media negotiation as specified in [Jingle]). 440 o Internet transport technologies such as the Real-time Transport 441 Protocol [RTP] (including secure transport as described in [SRTP]) 442 are designed to support any codec for which RTP packetization 443 rules have been defined. 445 o The IETF codec working group will focus on issues that are 446 specific to the Internet, including robustness to packet loss and 447 other aspects of packet transmission over the Internet. Issues 448 that are specific to non-Internet transports (e.g., radio 449 communication and circuit-switched networks) are specifically out 450 of scope. 452 Although there is already sufficient codec expertise available among 453 IETF participants to complete the envisioned work, additional 454 contributions are welcome within the framework of the Internet 455 Standards Process, in the following ways: 457 o Individuals who are technical contributors to codec work within 458 other SDOs can participate directly in codec work within the IETF. 460 o Other SDOs can contribute their expertise (e.g., codec 461 characterization and evaluation techniques) and thus facilitate 462 the testing of a codec produced by the IETF. 464 o Any SDO can provide input to IETF work through liaison statements. 466 However, it is important to note that final responsibility for the 467 development process and the resulting codec will remain with the IETF 468 as governed by BCP 9 [PROCESS]. 470 Finally, there is precedent for the contribution of codecs developed 471 elsewhere to the ITU-T (e.g., AMR Wideband was standardized 472 originally within 3GPP). This is a model to explore as the IETF 473 coordinates further with the ITU-T in accordance with the 474 collaboration guidelines defined in [COLLAB]. 476 7. Security Considerations 478 The procedural guidelines for codec development do not have security 479 considerations. However, the resulting codec needs to take 480 appropriate security considerations into account, for example as 481 outlined in [DOS] and [SECGUIDE]. 483 8. IANA Considerations 485 This document has no actions for IANA. 487 9. Acknowledgments 489 We would like to thank all the other people who contributed directly 490 or indirectly to this document, including Jason Fischl, Gregory 491 Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Michael 492 Knappe, Timothy Terriberry, Christian Hoene, Stephan Wenger and Henry 493 Sinnreich. We also like to thank Cullen Jennings and Gregory 494 Lebovitz for their advice. Special thanks to Peter Saint-Andre, who 495 originally co-authored this document. 497 10. References 499 10.1. Normative References 501 [IPR] Bradner, S., "Intellectual Property Rights in IETF 502 Technology", BCP 79, RFC 3979, March 2005. 504 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 505 3", BCP 9, RFC 2026, October 1996. 507 [TRUST] Bradner, S. and J. Contreras, "Rights Contributors Provide 508 to the IETF Trust", BCP 78, RFC 5378, November 2008. 510 10.2. Informative References 512 [COLLAB] Fishman, G. and S. Bradner, "Internet Engineering Task 513 Force and International Telecommunication Union - 514 Telecommunications Standardization Sector Collaboration 515 Guidelines", RFC 3356, August 2002. 517 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 518 Service Considerations", RFC 4732, December 2006. 520 [Jingle] Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. 521 Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, June 2009. 523 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 524 Jacobson, "RTP: A Transport Protocol for Real-Time 525 Applications", STD 64, RFC 3550, July 2003. 527 [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 528 Description Protocol", RFC 4566, July 2006. 530 [SECGUIDE] 531 Rescorla, E. and B. Korver, "Guidelines for Writing RFC 532 Text on Security Considerations", BCP 72, RFC 3552, 533 July 2003. 535 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 536 A., Peterson, J., Sparks, R., Handley, M., and E. 537 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 538 June 2002. 540 [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 541 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 542 RFC 3711, March 2004. 544 [UNCOORD] Bryant, S. and M. Morrow, "Uncoordinated Protocol 545 Development Considered Harmful", RFC 5704, November 2009. 547 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 548 Protocol (XMPP): Core", RFC 3920, October 2004. 550 Authors' Addresses 552 Jean-Marc Valin 553 Octasic Inc. 554 4101, Molson Street 555 Montreal, Quebec 556 Canada 558 Email: jean-marc.valin@octasic.com 560 Slava Borilin 561 SPIRIT DSP 563 Email: borilin@spiritdsp.net 565 Koen Vos 566 Skype Technologies S.A. 567 Stadsgarden 6 568 Stockholm, 11645 569 Sweden 571 Email: koen.vos@skype.net 573 Christopher Montgomery 574 Xiph.Org Foundation 576 Email: xiphmont@xiph.org 578 Raymond (Juin-Hwey) Chen 579 Broadcom Corporation 581 Email: rchen@broadcom.com