Dependencies/libogg/doc/rfc5334.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       I. Goncalves
   8 Request for Comments: 5334                                   S. Pfeiffer
   9 Obsoletes: 3534                                            C. Montgomery
  10 Category: Standards Track                                           Xiph
  11                                                           September 2008
  12
  13
  14                             Ogg Media Types
  15
  16 Status of This Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Abstract
  25
  26    This document describes the registration of media types for the Ogg
  27    container format and conformance requirements for implementations of
  28    these types.  This document obsoletes RFC 3534.
  29
  30 Table of Contents
  31
  32    1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
  33    2.     Changes Since RFC 3534  . . . . . . . . . . . . . . . . . .  2
  34    3.     Conformance and Document Conventions  . . . . . . . . . . .  3
  35    4.     Deployed Media Types and Compatibility  . . . . . . . . . .  3
  36    5.     Relation between the Media Types  . . . . . . . . . . . . .  5
  37    6.     Encoding Considerations . . . . . . . . . . . . . . . . . .  5
  38    7.     Security Considerations . . . . . . . . . . . . . . . . . .  6
  39    8.     Interoperability Considerations . . . . . . . . . . . . . .  7
  40    9.     IANA Considerations . . . . . . . . . . . . . . . . . . . .  7
  41    10.    Ogg Media Types . . . . . . . . . . . . . . . . . . . . . .  7
  42    10.1.  application/ogg . . . . . . . . . . . . . . . . . . . . . .  7
  43    10.2.  video/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  8
  44    10.3.  audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  9
  45    11.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
  46    12.    Copying Conditions  . . . . . . . . . . . . . . . . . . . . 10
  47    13.    References  . . . . . . . . . . . . . . . . . . . . . . . . 11
  48    13.1.  Normative References  . . . . . . . . . . . . . . . . . . . 11
  49    13.2.  Informative References  . . . . . . . . . . . . . . . . . . 11
  50
  51
  52
  53
  54
  55
  56
  57
  58 Goncalves, et al.           Standards Track                     [Page 1]
  59 \f
  60 RFC 5334                    Ogg Media Types               September 2008
  61
  62
  63 1.  Introduction
  64
  65    This document describes media types for Ogg, a data encapsulation
  66    format defined by the Xiph.Org Foundation for public use.  Refer to
  67    "Introduction" in [RFC3533] and "Overview" in [Ogg] for background
  68    information on this container format.
  69
  70    Binary data contained in Ogg, such as Vorbis and Theora, has
  71    historically been interchanged using the application/ogg media type
  72    as defined by [RFC3534].  This document obsoletes [RFC3534] and
  73    defines three media types for different types of content in Ogg to
  74    reflect this usage in the IANA media type registry, to foster
  75    interoperability by defining underspecified aspects, and to provide
  76    general security considerations.
  77
  78    The Ogg container format is known to contain [Theora] or [Dirac]
  79    video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
  80    audio, and [CMML] timed text/metadata.  As Ogg encapsulates binary
  81    data, it is possible to include any other type of video, audio,
  82    image, text, or, generally speaking, any time-continuously sampled
  83    data.
  84
  85    While raw packets from these data sources may be used directly by
  86    transport mechanisms that provide their own framing and packet-
  87    separation mechanisms (such as UDP datagrams or RTP), Ogg is a
  88    solution for stream based storage (such as files) and transport (such
  89    as TCP streams or pipes).  The media types defined in this document
  90    are needed to correctly identify such content when it is served over
  91    HTTP, included in multi-part documents, or used in other places where
  92    media types [RFC2045] are used.
  93
  94 2.  Changes Since RFC 3534
  95
  96    o  The type "application/ogg" is redefined.
  97
  98    o  The types "video/ogg" and "audio/ogg" are defined.
  99
 100    o  New file extensions are defined.
 101
 102    o  New Macintosh file type codes are defined.
 103
 104    o  The codecs parameter is defined for optional use.
 105
 106    o  The Ogg Skeleton extension becomes a recommended addition for
 107       content served under the new types.
 108
 109
 110
 111
 112
 113
 114 Goncalves, et al.           Standards Track                     [Page 2]
 115 \f
 116 RFC 5334                    Ogg Media Types               September 2008
 117
 118
 119 3.  Conformance and Document Conventions
 120
 121    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 122    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 123    document are to be interpreted as described in BCP 14, [RFC2119] and
 124    indicate requirement levels for compliant implementations.
 125    Requirements apply to all implementations unless otherwise stated.
 126
 127    An implementation is a software module that supports one of the media
 128    types defined in this document.  Software modules may support
 129    multiple media types, but conformance is considered individually for
 130    each type.
 131
 132    Implementations that fail to satisfy one or more "MUST" requirements
 133    are considered non-compliant.  Implementations that satisfy all
 134    "MUST" requirements, but fail to satisfy one or more "SHOULD"
 135    requirements, are said to be "conditionally compliant".  All other
 136    implementations are "unconditionally compliant".
 137
 138 4.  Deployed Media Types and Compatibility
 139
 140    The application/ogg media type has been used in an ad hoc fashion to
 141    label and exchange multimedia content in Ogg containers.
 142
 143    Use of the "application" top-level type for this kind of content is
 144    known to be problematic, in particular since it obfuscates video and
 145    audio content.  This document thus defines the media types,
 146
 147    o  video/ogg
 148
 149    o  audio/ogg
 150
 151    which are intended for common use and SHOULD be used when dealing
 152    with video or audio content, respectively.  This document also
 153    obsoletes the [RFC3534] definition of application/ogg and marks it
 154    for complex data (e.g., multitrack visual, audio, textual, and other
 155    time-continuously sampled data), which is not clearly video or audio
 156    data and thus not suited for either the video/ogg or audio/ogg types.
 157    Refer to the following section for more details.
 158
 159    An Ogg bitstream generally consists of one or more logical bitstreams
 160    that each consist of a series of header and data pages packetising
 161    time-continuous binary data [RFC3533].  The content types of the
 162    logical bitstreams may be identified without decoding the header
 163    pages of the logical bitstreams through use of a [Skeleton]
 164    bitstream.  Using Ogg Skeleton is REQUIRED for content served under
 165
 166
 167
 168
 169
 170 Goncalves, et al.           Standards Track                     [Page 3]
 171 \f
 172 RFC 5334                    Ogg Media Types               September 2008
 173
 174
 175    the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
 176    as Skeleton contains identifiers to describe the different
 177    encapsulated data.
 178
 179    Furthermore, it is RECOMMENDED that implementations that identify a
 180    logical bitstream that they cannot decode SHOULD ignore it, while
 181    continuing to decode the ones they can.  Such precaution ensures
 182    backward and forward compatibility with existing and future data.
 183
 184    These media types can optionally use the "codecs" parameter described
 185    in [RFC4281].  Codecs encapsulated in Ogg require a text identifier
 186    at the beginning of the first header page, hence a machine-readable
 187    method to identify the encapsulated codecs would be through this
 188    header.  The following table illustrates how those header values map
 189    into strings that are used in the "codecs" parameter when dealing
 190    with Ogg media types.
 191
 192         Codec Identifier             | Codecs Parameter
 193        -----------------------------------------------------------
 194         char[5]: 'BBCD\0'            | dirac
 195         char[5]: '\177FLAC'          | flac
 196         char[7]: '\x80theora'        | theora
 197         char[7]: '\x01vorbis'        | vorbis
 198         char[8]: 'CELT    '          | celt
 199         char[8]: 'CMML\0\0\0\0'      | cmml
 200         char[8]: '\213JNG\r\n\032\n' | jng
 201         char[8]: '\x80kate\0\0\0'    | kate
 202         char[8]: 'OggMIDI\0'         | midi
 203         char[8]: '\212MNG\r\n\032\n' | mng
 204         char[8]: 'PCM     '          | pcm
 205         char[8]: '\211PNG\r\n\032\n' | png
 206         char[8]: 'Speex   '          | speex
 207         char[8]: 'YUV4MPEG'          | yuv4mpeg
 208
 209    An up-to-date version of this table is kept at Xiph.org (see
 210    [Codecs]).
 211
 212    Possible examples include:
 213
 214    o  application/ogg; codecs="theora, cmml, ecmascript"
 215
 216    o  video/ogg; codecs="theora, vorbis"
 217
 218    o  audio/ogg; codecs=speex
 219
 220
 221
 222
 223
 224
 225
 226 Goncalves, et al.           Standards Track                     [Page 4]
 227 \f
 228 RFC 5334                    Ogg Media Types               September 2008
 229
 230
 231 5.  Relation between the Media Types
 232
 233    As stated in the previous section, this document describes three
 234    media types that are targeted at different data encapsulated in Ogg.
 235    Since Ogg is capable of encapsulating any kind of data, the multiple
 236    usage scenarios have revealed interoperability issues between
 237    implementations when dealing with content served solely under the
 238    application/ogg type.
 239
 240    While this document does redefine the earlier definition of
 241    application/ogg, this media type will continue to embrace the widest
 242    net possible of content with the video/ogg and audio/ogg types being
 243    smaller subsets of it.  However, the video/ogg and audio/ogg types
 244    take precedence in a subset of the usages, specifically when serving
 245    multimedia content that is not complex enough to warrant the use of
 246    application/ogg.  Following this line of thought, the audio/ogg type
 247    is an even smaller subset within video/ogg, as it is not intended to
 248    refer to visual content.
 249
 250    As such, the application/ogg type is the recommended choice to serve
 251    content aimed at scientific and other applications that require
 252    various multiplexed signals or streams of continuous data, with or
 253    without scriptable control of content.  For bitstreams containing
 254    visual, timed text, and any other type of material that requires a
 255    visual interface, but that is not complex enough to warrant serving
 256    under application/ogg, the video/ogg type is recommended.  In
 257    situations where the Ogg bitstream predominantly contains audio data
 258    (lyrics, metadata, or cover art notwithstanding), it is recommended
 259    to use the audio/ogg type.
 260
 261 6.  Encoding Considerations
 262
 263    Binary: The content consists of an unrestricted sequence of octets.
 264
 265    Note:
 266
 267    o  Ogg encapsulated content is binary data and should be transmitted
 268       in a suitable encoding without CR/LF conversion, 7-bit stripping,
 269       etc.; base64 [RFC4648] is generally preferred for binary-to-text
 270       encoding.
 271
 272    o  Media types described in this document are used for stream based
 273       storage (such as files) and transport (such as TCP streams or
 274       pipes); separate types are used to identify codecs such as in
 275       real-time applications for the RTP payload formats of Theora
 276       [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
 277       as for identification of encapsulated data within Ogg through
 278       Skeleton.
 279
 280
 281
 282 Goncalves, et al.           Standards Track                     [Page 5]
 283 \f
 284 RFC 5334                    Ogg Media Types               September 2008
 285
 286
 287 7.  Security Considerations
 288
 289    Refer to [RFC3552] for a discussion of terminology used in this
 290    section.
 291
 292    The Ogg encapsulation format is a container and only a carrier of
 293    content (such as audio, video, and displayable text data) with a very
 294    rigid definition.  This format in itself is not more vulnerable than
 295    any other content framing mechanism.
 296
 297    Ogg does not provide for any generic encryption or signing of itself
 298    or its contained bitstreams.  However, it encapsulates any kind of
 299    binary content and is thus able to contain encrypted and signed
 300    content data.  It is also possible to add an external security
 301    mechanism that encrypts or signs an Ogg bitstream and thus provides
 302    content confidentiality and authenticity.
 303
 304    As Ogg encapsulates binary data, it is possible to include executable
 305    content in an Ogg bitstream.  Implementations SHOULD NOT execute such
 306    content without prior validation of its origin by the end-user.
 307
 308    Issues may arise on applications that use Ogg for streaming or file
 309    transfer in a networking scenario.  In such cases, implementations
 310    decoding Ogg and its encapsulated bitstreams have to ensure correct
 311    handling of manipulated bitstreams, of buffer overflows, and similar
 312    issues.
 313
 314    It is also possible to author malicious Ogg bitstreams, which attempt
 315    to call for an excessively large picture size, high sampling-rate
 316    audio, etc.  Implementations SHOULD protect themselves against this
 317    kind of attack.
 318
 319    Ogg has an extensible structure, so that it is theoretically possible
 320    that metadata fields or media formats might be defined in the future
 321    which might be used to induce particular actions on the part of the
 322    recipient, thus presenting additional security risks.  However, this
 323    type of capability is currently not supported in the referenced
 324    specification.
 325
 326    Implementations may fail to implement a specific security model or
 327    other means to prevent possibly dangerous operations.  Such failure
 328    might possibly be exploited to gain unauthorized access to a system
 329    or sensitive information; such failure constitutes an unknown factor
 330    and is thus considered out of the scope of this document.
 331
 332
 333
 334
 335
 336
 337
 338 Goncalves, et al.           Standards Track                     [Page 6]
 339 \f
 340 RFC 5334                    Ogg Media Types               September 2008
 341
 342
 343 8.  Interoperability Considerations
 344
 345    The Ogg container format is device-, platform-, and vendor-neutral
 346    and has proved to be widely implementable across different computing
 347    platforms through a wide range of encoders and decoders.  A broadly
 348    portable reference implementation [libogg] is available under the
 349    revised (3-clause) BSD license, which is a Free Software license.
 350
 351    The Xiph.Org Foundation has defined the specification,
 352    interoperability, and conformance and conducts regular
 353    interoperability testing.
 354
 355    The use of the Ogg Skeleton extension has been confirmed to not cause
 356    interoperability issues with existing implementations.  Third parties
 357    are, however, welcome to conduct their own testing.
 358
 359 9.  IANA Considerations
 360
 361    In accordance with the procedures set forth in [RFC4288], this
 362    document registers two new media types and redefines the existing
 363    application/ogg as defined in the following section.
 364
 365 10.  Ogg Media Types
 366
 367 10.1.  application/ogg
 368
 369    Type name: application
 370
 371    Subtype name: ogg
 372
 373    Required parameters: none
 374
 375    Optional parameters: codecs, whose syntax is defined in RFC 4281.
 376    See section 4 of RFC 5334 for a list of allowed values.
 377
 378    Encoding considerations: See section 6 of RFC 5334.
 379
 380    Security considerations: See section 7 of RFC 5334.
 381
 382    Interoperability considerations: None, as noted in section 8 of RFC
 383    5334.
 384
 385    Published specification: RFC 3533
 386
 387    Applications which use this media type: Scientific and otherwise that
 388    require various multiplexed signals or streams of data, with or
 389    without scriptable control of content.
 390
 391
 392
 393
 394 Goncalves, et al.           Standards Track                     [Page 7]
 395 \f
 396 RFC 5334                    Ogg Media Types               September 2008
 397
 398
 399    Additional information:
 400
 401    Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
 402    correspond to the string "OggS".
 403
 404    File extension(s): .ogx
 405
 406       RFC 3534 defined the file extension .ogg for application/ogg,
 407       which RFC 5334 obsoletes in favor of .ogx due to concerns where,
 408       historically, some implementations expect .ogg files to be solely
 409       Vorbis-encoded audio.
 410
 411    Macintosh File Type Code(s): OggX
 412
 413    Person & Email address to contact for further information: See
 414    "Authors' Addresses" section.
 415
 416    Intended usage: COMMON
 417
 418    Restrictions on usage: The type application/ogg SHOULD only be used
 419    in situations where it is not appropriate to serve data under the
 420    video/ogg or audio/ogg types.  Data served under the application/ogg
 421    type SHOULD use the .ogx file extension and MUST contain an Ogg
 422    Skeleton logical bitstream to identify all other contained logical
 423    bitstreams.
 424
 425    Author: See "Authors' Addresses" section.
 426
 427    Change controller: The Xiph.Org Foundation.
 428
 429 10.2.  video/ogg
 430
 431    Type name: video
 432
 433    Subtype name: ogg
 434
 435    Required parameters: none
 436
 437    Optional parameters: codecs, whose syntax is defined in RFC 4281.
 438    See section 4 of RFC 5334 for a list of allowed values.
 439
 440    Encoding considerations: See section 6 of RFC 5334.
 441
 442    Security considerations: See section 7 of RFC 5334.
 443
 444    Interoperability considerations: None, as noted in section 8 of RFC
 445    5334.
 446
 447
 448
 449
 450 Goncalves, et al.           Standards Track                     [Page 8]
 451 \f
 452 RFC 5334                    Ogg Media Types               September 2008
 453
 454
 455    Published specification: RFC 3533
 456
 457    Applications which use this media type: Multimedia applications,
 458    including embedded, streaming, and conferencing tools.
 459
 460    Additional information:
 461
 462    Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
 463    correspond to the string "OggS".
 464
 465    File extension(s): .ogv
 466
 467    Macintosh File Type Code(s): OggV
 468
 469    Person & Email address to contact for further information: See
 470    "Authors' Addresses" section.
 471
 472    Intended usage: COMMON
 473
 474    Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
 475    bitstreams containing visual, audio, timed text, or any other type of
 476    material that requires a visual interface.  It is intended for
 477    content not complex enough to warrant serving under "application/
 478    ogg"; for example, a combination of Theora video, Vorbis audio,
 479    Skeleton metadata, and CMML captioning.  Data served under the type
 480    "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
 481    Implementations interacting with the type "video/ogg" SHOULD support
 482    multiplexed bitstreams.
 483
 484    Author: See "Authors' Addresses" section.
 485
 486    Change controller: The Xiph.Org Foundation.
 487
 488 10.3.  audio/ogg
 489
 490    Type name: audio
 491
 492    Subtype name: ogg
 493
 494    Required parameters: none
 495
 496    Optional parameters: codecs, whose syntax is defined in RFC 4281.
 497    See section 4 of RFC 5334 for a list of allowed values.
 498
 499    Encoding considerations: See section 6 of RFC 5334.
 500
 501    Security considerations: See section 7 of RFC 5334.
 502
 503
 504
 505
 506 Goncalves, et al.           Standards Track                     [Page 9]
 507 \f
 508 RFC 5334                    Ogg Media Types               September 2008
 509
 510
 511    Interoperability considerations: None, as noted in section 8 of RFC
 512    5334.
 513
 514    Published specification: RFC 3533
 515
 516    Applications which use this media type: Multimedia applications,
 517    including embedded, streaming, and conferencing tools.
 518
 519    Additional information:
 520
 521    Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
 522    correspond to the string "OggS".
 523
 524    File extension(s): .oga, .ogg, .spx
 525
 526    Macintosh File Type Code(s): OggA
 527
 528    Person & Email address to contact for further information: See
 529    "Authors' Addresses" section.
 530
 531    Intended usage: COMMON
 532
 533    Restrictions on usage: The type "audio/ogg" SHOULD be used when the
 534    Ogg bitstream predominantly contains audio data.  Content served
 535    under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
 536    bitstream when using the default .oga file extension.  The .ogg and
 537    .spx file extensions indicate a specialization that requires no
 538    Skeleton due to backward compatibility concerns with existing
 539    implementations.  In particular, .ogg is used for Ogg files that
 540    contain only a Vorbis bitstream, while .spx is used for Ogg files
 541    that contain only a Speex bitstream.
 542
 543    Author: See "Authors' Addresses" section.
 544
 545    Change controller: The Xiph.Org Foundation.
 546
 547 11.  Acknowledgements
 548
 549    The authors gratefully acknowledge the contributions of Magnus
 550    Westerlund, Alfred Hoenes, and Peter Saint-Andre.
 551
 552 12.  Copying Conditions
 553
 554    The authors agree to grant third parties the irrevocable right to
 555    copy, use and distribute the work, with or without modification, in
 556    any medium, without royalty, provided that, unless separate
 557    permission is granted, redistributed modified works do not contain
 558    misleading author, version, name of work, or endorsement information.
 559
 560
 561
 562 Goncalves, et al.           Standards Track                    [Page 10]
 563 \f
 564 RFC 5334                    Ogg Media Types               September 2008
 565
 566
 567 13.  References
 568
 569 13.1.  Normative References
 570
 571    [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 572                Extensions (MIME) Part One: Format of Internet Message
 573                Bodies", RFC 2045, November 1996.
 574
 575    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
 576                Requirement Levels", BCP 14, RFC 2119, March 1997.
 577
 578    [RFC3533]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
 579                RFC 3533, May 2003.
 580
 581    [RFC4281]   Gellens, R., Singer, D., and P. Frojdh, "The Codecs
 582                Parameter for "Bucket" Media Types", RFC 4281,
 583                November 2005.
 584
 585    [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
 586                Registration Procedures", BCP 13, RFC 4288,
 587                December 2005.
 588
 589 13.2.  Informative References
 590
 591    [CMML]      Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
 592                Media Markup Language (CMML)", Work in Progress,
 593                March 2006.
 594
 595    [Codecs]    Pfeiffer, S. and I. Goncalves, "Specification of MIME
 596                types and respective codecs parameter", July 2008,
 597                <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
 598
 599    [Dirac]     Dirac Group, "Dirac Specification",
 600                <http://diracvideo.org/specifications/>.
 601
 602    [FLAC]      Coalson, J., "The FLAC Format",
 603                <http://flac.sourceforge.net/format.html>.
 604
 605    [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
 606                <http://xiph.org/ogg/doc/libogg>.
 607
 608    [Ogg]       Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
 609                logical and physical bitstream overview, Ogg logical
 610                bitstream framing, Ogg multi-stream multiplexing",
 611                <http://xiph.org/ogg/doc>.
 612
 613    [RFC3534]   Walleij, L., "The application/ogg Media Type", RFC 3534,
 614                May 2003.
 615
 616
 617
 618 Goncalves, et al.           Standards Track                    [Page 11]
 619 \f
 620 RFC 5334                    Ogg Media Types               September 2008
 621
 622
 623    [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
 624                Text on Security Considerations", BCP 72, RFC 3552,
 625                July 2003.
 626
 627    [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
 628                Encodings", RFC 4648, October 2006.
 629
 630    [RFC5215]   Barbato, L., "RTP Payload Format for Vorbis Encoded
 631                Audio", RFC 5215, August 2008.
 632
 633    [Skeleton]  Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
 634                Bitstream", November 2007,
 635                <http://xiph.org/ogg/doc/skeleton.html>.
 636
 637    [Speex]     Valin, J., "The Speex Codec Manual", February 2002,
 638                <http://speex.org/docs/manual/speex-manual>.
 639
 640    [SpRTP]     Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
 641                "RTP Payload Format for the Speex Codec", Work
 642                in Progress, February 2008.
 643
 644    [Theora]    Xiph.Org Foundation, "Theora Specification",
 645                October 2007, <http://theora.org/doc/Theora.pdf>.
 646
 647    [ThRTP]     Barbato, L., "RTP Payload Format for Theora Encoded
 648                Video", Work in Progress, June 2006.
 649
 650    [Vorbis]    Xiph.Org Foundation, "Vorbis I Specification", July 2004,
 651                <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Goncalves, et al.           Standards Track                    [Page 12]
 675 \f
 676 RFC 5334                    Ogg Media Types               September 2008
 677
 678
 679 Authors' Addresses
 680
 681    Ivo Emanuel Goncalves
 682    Xiph.Org Foundation
 683    21 College Hill Road
 684    Somerville, MA  02144
 685    US
 686
 687    EMail: justivo@gmail.com
 688    URI:   xmpp:justivo@gmail.com
 689
 690
 691    Silvia Pfeiffer
 692    Xiph.Org Foundation
 693
 694    EMail: silvia@annodex.net
 695    URI:   http://annodex.net/
 696
 697
 698    Christopher Montgomery
 699    Xiph.Org Foundation
 700
 701    EMail: monty@xiph.org
 702    URI:   http://xiph.org
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Goncalves, et al.           Standards Track                    [Page 13]
 731 \f
 732 RFC 5334                    Ogg Media Types               September 2008
 733
 734
 735 Full Copyright Statement
 736
 737    Copyright (C) The IETF Trust (2008).
 738
 739    This document is subject to the rights, licenses and restrictions
 740    contained in BCP 78, and except as set forth therein, the authors
 741    retain all their rights.
 742
 743    This document and the information contained herein are provided on an
 744    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 745    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 746    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 747    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 748    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 749    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 750
 751 Intellectual Property
 752
 753    The IETF takes no position regarding the validity or scope of any
 754    Intellectual Property Rights or other rights that might be claimed to
 755    pertain to the implementation or use of the technology described in
 756    this document or the extent to which any license under such rights
 757    might or might not be available; nor does it represent that it has
 758    made any independent effort to identify any such rights.  Information
 759    on the procedures with respect to rights in RFC documents can be
 760    found in BCP 78 and BCP 79.
 761
 762    Copies of IPR disclosures made to the IETF Secretariat and any
 763    assurances of licenses to be made available, or the result of an
 764    attempt made to obtain a general license or permission for the use of
 765    such proprietary rights by implementers or users of this
 766    specification can be obtained from the IETF on-line IPR repository at
 767    http://www.ietf.org/ipr.
 768
 769    The IETF invites any interested party to bring to its attention any
 770    copyrights, patents or patent applications, or other proprietary
 771    rights that may cover technology that may be required to implement
 772    this standard.  Please address the information to the IETF at
 773    ietf-ipr@ietf.org.
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Goncalves, et al.           Standards Track                    [Page 14]
 787 \f