summaryrefslogtreecommitdiffhomepage
path: root/doc/rfc5334.txt
blob: fea91fb14016637d02796007b69b67c9e806319f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
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
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787






Network Working Group                                       I. Goncalves
Request for Comments: 5334                                   S. Pfeiffer
Obsoletes: 3534                                            C. Montgomery
Category: Standards Track                                           Xiph
                                                          September 2008


                            Ogg Media Types

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes the registration of media types for the Ogg
   container format and conformance requirements for implementations of
   these types.  This document obsoletes RFC 3534.

Table of Contents

   1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   2.     Changes Since RFC 3534  . . . . . . . . . . . . . . . . . .  2
   3.     Conformance and Document Conventions  . . . . . . . . . . .  3
   4.     Deployed Media Types and Compatibility  . . . . . . . . . .  3
   5.     Relation between the Media Types  . . . . . . . . . . . . .  5
   6.     Encoding Considerations . . . . . . . . . . . . . . . . . .  5
   7.     Security Considerations . . . . . . . . . . . . . . . . . .  6
   8.     Interoperability Considerations . . . . . . . . . . . . . .  7
   9.     IANA Considerations . . . . . . . . . . . . . . . . . . . .  7
   10.    Ogg Media Types . . . . . . . . . . . . . . . . . . . . . .  7
   10.1.  application/ogg . . . . . . . . . . . . . . . . . . . . . .  7
   10.2.  video/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  8
   10.3.  audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  9
   11.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
   12.    Copying Conditions  . . . . . . . . . . . . . . . . . . . . 10
   13.    References  . . . . . . . . . . . . . . . . . . . . . . . . 11
   13.1.  Normative References  . . . . . . . . . . . . . . . . . . . 11
   13.2.  Informative References  . . . . . . . . . . . . . . . . . . 11








Goncalves, et al.           Standards Track                     [Page 1]

RFC 5334                    Ogg Media Types               September 2008


1.  Introduction

   This document describes media types for Ogg, a data encapsulation
   format defined by the Xiph.Org Foundation for public use.  Refer to
   "Introduction" in [RFC3533] and "Overview" in [Ogg] for background
   information on this container format.

   Binary data contained in Ogg, such as Vorbis and Theora, has
   historically been interchanged using the application/ogg media type
   as defined by [RFC3534].  This document obsoletes [RFC3534] and
   defines three media types for different types of content in Ogg to
   reflect this usage in the IANA media type registry, to foster
   interoperability by defining underspecified aspects, and to provide
   general security considerations.

   The Ogg container format is known to contain [Theora] or [Dirac]
   video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
   audio, and [CMML] timed text/metadata.  As Ogg encapsulates binary
   data, it is possible to include any other type of video, audio,
   image, text, or, generally speaking, any time-continuously sampled
   data.

   While raw packets from these data sources may be used directly by
   transport mechanisms that provide their own framing and packet-
   separation mechanisms (such as UDP datagrams or RTP), Ogg is a
   solution for stream based storage (such as files) and transport (such
   as TCP streams or pipes).  The media types defined in this document
   are needed to correctly identify such content when it is served over
   HTTP, included in multi-part documents, or used in other places where
   media types [RFC2045] are used.

2.  Changes Since RFC 3534

   o  The type "application/ogg" is redefined.

   o  The types "video/ogg" and "audio/ogg" are defined.

   o  New file extensions are defined.

   o  New Macintosh file type codes are defined.

   o  The codecs parameter is defined for optional use.

   o  The Ogg Skeleton extension becomes a recommended addition for
      content served under the new types.






Goncalves, et al.           Standards Track                     [Page 2]

RFC 5334                    Ogg Media Types               September 2008


3.  Conformance and Document Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119] and
   indicate requirement levels for compliant implementations.
   Requirements apply to all implementations unless otherwise stated.

   An implementation is a software module that supports one of the media
   types defined in this document.  Software modules may support
   multiple media types, but conformance is considered individually for
   each type.

   Implementations that fail to satisfy one or more "MUST" requirements
   are considered non-compliant.  Implementations that satisfy all
   "MUST" requirements, but fail to satisfy one or more "SHOULD"
   requirements, are said to be "conditionally compliant".  All other
   implementations are "unconditionally compliant".

4.  Deployed Media Types and Compatibility

   The application/ogg media type has been used in an ad hoc fashion to
   label and exchange multimedia content in Ogg containers.

   Use of the "application" top-level type for this kind of content is
   known to be problematic, in particular since it obfuscates video and
   audio content.  This document thus defines the media types,

   o  video/ogg

   o  audio/ogg

   which are intended for common use and SHOULD be used when dealing
   with video or audio content, respectively.  This document also
   obsoletes the [RFC3534] definition of application/ogg and marks it
   for complex data (e.g., multitrack visual, audio, textual, and other
   time-continuously sampled data), which is not clearly video or audio
   data and thus not suited for either the video/ogg or audio/ogg types.
   Refer to the following section for more details.

   An Ogg bitstream generally consists of one or more logical bitstreams
   that each consist of a series of header and data pages packetising
   time-continuous binary data [RFC3533].  The content types of the
   logical bitstreams may be identified without decoding the header
   pages of the logical bitstreams through use of a [Skeleton]
   bitstream.  Using Ogg Skeleton is REQUIRED for content served under





Goncalves, et al.           Standards Track                     [Page 3]

RFC 5334                    Ogg Media Types               September 2008


   the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
   as Skeleton contains identifiers to describe the different
   encapsulated data.

   Furthermore, it is RECOMMENDED that implementations that identify a
   logical bitstream that they cannot decode SHOULD ignore it, while
   continuing to decode the ones they can.  Such precaution ensures
   backward and forward compatibility with existing and future data.

   These media types can optionally use the "codecs" parameter described
   in [RFC4281].  Codecs encapsulated in Ogg require a text identifier
   at the beginning of the first header page, hence a machine-readable
   method to identify the encapsulated codecs would be through this
   header.  The following table illustrates how those header values map
   into strings that are used in the "codecs" parameter when dealing
   with Ogg media types.

        Codec Identifier             | Codecs Parameter
       -----------------------------------------------------------
        char[5]: 'BBCD\0'            | dirac
        char[5]: '\177FLAC'          | flac
        char[7]: '\x80theora'        | theora
        char[7]: '\x01vorbis'        | vorbis
        char[8]: 'CELT    '          | celt
        char[8]: 'CMML\0\0\0\0'      | cmml
        char[8]: '\213JNG\r\n\032\n' | jng
        char[8]: '\x80kate\0\0\0'    | kate
        char[8]: 'OggMIDI\0'         | midi
        char[8]: '\212MNG\r\n\032\n' | mng
        char[8]: 'PCM     '          | pcm
        char[8]: '\211PNG\r\n\032\n' | png
        char[8]: 'Speex   '          | speex
        char[8]: 'YUV4MPEG'          | yuv4mpeg

   An up-to-date version of this table is kept at Xiph.org (see
   [Codecs]).

   Possible examples include:

   o  application/ogg; codecs="theora, cmml, ecmascript"

   o  video/ogg; codecs="theora, vorbis"

   o  audio/ogg; codecs=speex







Goncalves, et al.           Standards Track                     [Page 4]

RFC 5334                    Ogg Media Types               September 2008


5.  Relation between the Media Types

   As stated in the previous section, this document describes three
   media types that are targeted at different data encapsulated in Ogg.
   Since Ogg is capable of encapsulating any kind of data, the multiple
   usage scenarios have revealed interoperability issues between
   implementations when dealing with content served solely under the
   application/ogg type.

   While this document does redefine the earlier definition of
   application/ogg, this media type will continue to embrace the widest
   net possible of content with the video/ogg and audio/ogg types being
   smaller subsets of it.  However, the video/ogg and audio/ogg types
   take precedence in a subset of the usages, specifically when serving
   multimedia content that is not complex enough to warrant the use of
   application/ogg.  Following this line of thought, the audio/ogg type
   is an even smaller subset within video/ogg, as it is not intended to
   refer to visual content.

   As such, the application/ogg type is the recommended choice to serve
   content aimed at scientific and other applications that require
   various multiplexed signals or streams of continuous data, with or
   without scriptable control of content.  For bitstreams containing
   visual, timed text, and any other type of material that requires a
   visual interface, but that is not complex enough to warrant serving
   under application/ogg, the video/ogg type is recommended.  In
   situations where the Ogg bitstream predominantly contains audio data
   (lyrics, metadata, or cover art notwithstanding), it is recommended
   to use the audio/ogg type.

6.  Encoding Considerations

   Binary: The content consists of an unrestricted sequence of octets.

   Note:

   o  Ogg encapsulated content is binary data and should be transmitted
      in a suitable encoding without CR/LF conversion, 7-bit stripping,
      etc.; base64 [RFC4648] is generally preferred for binary-to-text
      encoding.

   o  Media types described in this document are used for stream based
      storage (such as files) and transport (such as TCP streams or
      pipes); separate types are used to identify codecs such as in
      real-time applications for the RTP payload formats of Theora
      [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
      as for identification of encapsulated data within Ogg through
      Skeleton.



Goncalves, et al.           Standards Track                     [Page 5]

RFC 5334                    Ogg Media Types               September 2008


7.  Security Considerations

   Refer to [RFC3552] for a discussion of terminology used in this
   section.

   The Ogg encapsulation format is a container and only a carrier of
   content (such as audio, video, and displayable text data) with a very
   rigid definition.  This format in itself is not more vulnerable than
   any other content framing mechanism.

   Ogg does not provide for any generic encryption or signing of itself
   or its contained bitstreams.  However, it encapsulates any kind of
   binary content and is thus able to contain encrypted and signed
   content data.  It is also possible to add an external security
   mechanism that encrypts or signs an Ogg bitstream and thus provides
   content confidentiality and authenticity.

   As Ogg encapsulates binary data, it is possible to include executable
   content in an Ogg bitstream.  Implementations SHOULD NOT execute such
   content without prior validation of its origin by the end-user.

   Issues may arise on applications that use Ogg for streaming or file
   transfer in a networking scenario.  In such cases, implementations
   decoding Ogg and its encapsulated bitstreams have to ensure correct
   handling of manipulated bitstreams, of buffer overflows, and similar
   issues.

   It is also possible to author malicious Ogg bitstreams, which attempt
   to call for an excessively large picture size, high sampling-rate
   audio, etc.  Implementations SHOULD protect themselves against this
   kind of attack.

   Ogg has an extensible structure, so that it is theoretically possible
   that metadata fields or media formats might be defined in the future
   which might be used to induce particular actions on the part of the
   recipient, thus presenting additional security risks.  However, this
   type of capability is currently not supported in the referenced
   specification.

   Implementations may fail to implement a specific security model or
   other means to prevent possibly dangerous operations.  Such failure
   might possibly be exploited to gain unauthorized access to a system
   or sensitive information; such failure constitutes an unknown factor
   and is thus considered out of the scope of this document.







Goncalves, et al.           Standards Track                     [Page 6]

RFC 5334                    Ogg Media Types               September 2008


8.  Interoperability Considerations

   The Ogg container format is device-, platform-, and vendor-neutral
   and has proved to be widely implementable across different computing
   platforms through a wide range of encoders and decoders.  A broadly
   portable reference implementation [libogg] is available under the
   revised (3-clause) BSD license, which is a Free Software license.

   The Xiph.Org Foundation has defined the specification,
   interoperability, and conformance and conducts regular
   interoperability testing.

   The use of the Ogg Skeleton extension has been confirmed to not cause
   interoperability issues with existing implementations.  Third parties
   are, however, welcome to conduct their own testing.

9.  IANA Considerations

   In accordance with the procedures set forth in [RFC4288], this
   document registers two new media types and redefines the existing
   application/ogg as defined in the following section.

10.  Ogg Media Types

10.1.  application/ogg

   Type name: application

   Subtype name: ogg

   Required parameters: none

   Optional parameters: codecs, whose syntax is defined in RFC 4281.
   See section 4 of RFC 5334 for a list of allowed values.

   Encoding considerations: See section 6 of RFC 5334.

   Security considerations: See section 7 of RFC 5334.

   Interoperability considerations: None, as noted in section 8 of RFC
   5334.

   Published specification: RFC 3533

   Applications which use this media type: Scientific and otherwise that
   require various multiplexed signals or streams of data, with or
   without scriptable control of content.




Goncalves, et al.           Standards Track                     [Page 7]

RFC 5334                    Ogg Media Types               September 2008


   Additional information:

   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
   correspond to the string "OggS".

   File extension(s): .ogx

      RFC 3534 defined the file extension .ogg for application/ogg,
      which RFC 5334 obsoletes in favor of .ogx due to concerns where,
      historically, some implementations expect .ogg files to be solely
      Vorbis-encoded audio.

   Macintosh File Type Code(s): OggX

   Person & Email address to contact for further information: See
   "Authors' Addresses" section.

   Intended usage: COMMON

   Restrictions on usage: The type application/ogg SHOULD only be used
   in situations where it is not appropriate to serve data under the
   video/ogg or audio/ogg types.  Data served under the application/ogg
   type SHOULD use the .ogx file extension and MUST contain an Ogg
   Skeleton logical bitstream to identify all other contained logical
   bitstreams.

   Author: See "Authors' Addresses" section.

   Change controller: The Xiph.Org Foundation.

10.2.  video/ogg

   Type name: video

   Subtype name: ogg

   Required parameters: none

   Optional parameters: codecs, whose syntax is defined in RFC 4281.
   See section 4 of RFC 5334 for a list of allowed values.

   Encoding considerations: See section 6 of RFC 5334.

   Security considerations: See section 7 of RFC 5334.

   Interoperability considerations: None, as noted in section 8 of RFC
   5334.




Goncalves, et al.           Standards Track                     [Page 8]

RFC 5334                    Ogg Media Types               September 2008


   Published specification: RFC 3533

   Applications which use this media type: Multimedia applications,
   including embedded, streaming, and conferencing tools.

   Additional information:

   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
   correspond to the string "OggS".

   File extension(s): .ogv

   Macintosh File Type Code(s): OggV

   Person & Email address to contact for further information: See
   "Authors' Addresses" section.

   Intended usage: COMMON

   Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
   bitstreams containing visual, audio, timed text, or any other type of
   material that requires a visual interface.  It is intended for
   content not complex enough to warrant serving under "application/
   ogg"; for example, a combination of Theora video, Vorbis audio,
   Skeleton metadata, and CMML captioning.  Data served under the type
   "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
   Implementations interacting with the type "video/ogg" SHOULD support
   multiplexed bitstreams.

   Author: See "Authors' Addresses" section.

   Change controller: The Xiph.Org Foundation.

10.3.  audio/ogg

   Type name: audio

   Subtype name: ogg

   Required parameters: none

   Optional parameters: codecs, whose syntax is defined in RFC 4281.
   See section 4 of RFC 5334 for a list of allowed values.

   Encoding considerations: See section 6 of RFC 5334.

   Security considerations: See section 7 of RFC 5334.




Goncalves, et al.           Standards Track                     [Page 9]

RFC 5334                    Ogg Media Types               September 2008


   Interoperability considerations: None, as noted in section 8 of RFC
   5334.

   Published specification: RFC 3533

   Applications which use this media type: Multimedia applications,
   including embedded, streaming, and conferencing tools.

   Additional information:

   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
   correspond to the string "OggS".

   File extension(s): .oga, .ogg, .spx

   Macintosh File Type Code(s): OggA

   Person & Email address to contact for further information: See
   "Authors' Addresses" section.

   Intended usage: COMMON

   Restrictions on usage: The type "audio/ogg" SHOULD be used when the
   Ogg bitstream predominantly contains audio data.  Content served
   under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
   bitstream when using the default .oga file extension.  The .ogg and
   .spx file extensions indicate a specialization that requires no
   Skeleton due to backward compatibility concerns with existing
   implementations.  In particular, .ogg is used for Ogg files that
   contain only a Vorbis bitstream, while .spx is used for Ogg files
   that contain only a Speex bitstream.

   Author: See "Authors' Addresses" section.

   Change controller: The Xiph.Org Foundation.

11.  Acknowledgements

   The authors gratefully acknowledge the contributions of Magnus
   Westerlund, Alfred Hoenes, and Peter Saint-Andre.

12.  Copying Conditions

   The authors agree to grant third parties the irrevocable right to
   copy, use and distribute the work, with or without modification, in
   any medium, without royalty, provided that, unless separate
   permission is granted, redistributed modified works do not contain
   misleading author, version, name of work, or endorsement information.



Goncalves, et al.           Standards Track                    [Page 10]

RFC 5334                    Ogg Media Types               September 2008


13.  References

13.1.  Normative References

   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3533]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
               RFC 3533, May 2003.

   [RFC4281]   Gellens, R., Singer, D., and P. Frojdh, "The Codecs
               Parameter for "Bucket" Media Types", RFC 4281,
               November 2005.

   [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
               Registration Procedures", BCP 13, RFC 4288,
               December 2005.

13.2.  Informative References

   [CMML]      Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
               Media Markup Language (CMML)", Work in Progress,
               March 2006.

   [Codecs]    Pfeiffer, S. and I. Goncalves, "Specification of MIME
               types and respective codecs parameter", July 2008,
               <http://wiki.xiph.org/index.php/MIMETypesCodecs>.

   [Dirac]     Dirac Group, "Dirac Specification",
               <http://diracvideo.org/specifications/>.

   [FLAC]      Coalson, J., "The FLAC Format",
               <http://flac.sourceforge.net/format.html>.

   [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
               <http://xiph.org/ogg/doc/libogg>.

   [Ogg]       Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
               logical and physical bitstream overview, Ogg logical
               bitstream framing, Ogg multi-stream multiplexing",
               <http://xiph.org/ogg/doc>.

   [RFC3534]   Walleij, L., "The application/ogg Media Type", RFC 3534,
               May 2003.



Goncalves, et al.           Standards Track                    [Page 11]

RFC 5334                    Ogg Media Types               September 2008


   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
               Text on Security Considerations", BCP 72, RFC 3552,
               July 2003.

   [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
               Encodings", RFC 4648, October 2006.

   [RFC5215]   Barbato, L., "RTP Payload Format for Vorbis Encoded
               Audio", RFC 5215, August 2008.

   [Skeleton]  Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
               Bitstream", November 2007,
               <http://xiph.org/ogg/doc/skeleton.html>.

   [Speex]     Valin, J., "The Speex Codec Manual", February 2002,
               <http://speex.org/docs/manual/speex-manual>.

   [SpRTP]     Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
               "RTP Payload Format for the Speex Codec", Work
               in Progress, February 2008.

   [Theora]    Xiph.Org Foundation, "Theora Specification",
               October 2007, <http://theora.org/doc/Theora.pdf>.

   [ThRTP]     Barbato, L., "RTP Payload Format for Theora Encoded
               Video", Work in Progress, June 2006.

   [Vorbis]    Xiph.Org Foundation, "Vorbis I Specification", July 2004,
               <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.






















Goncalves, et al.           Standards Track                    [Page 12]

RFC 5334                    Ogg Media Types               September 2008


Authors' Addresses

   Ivo Emanuel Goncalves
   Xiph.Org Foundation
   21 College Hill Road
   Somerville, MA  02144
   US

   EMail: justivo@gmail.com
   URI:   xmpp:justivo@gmail.com


   Silvia Pfeiffer
   Xiph.Org Foundation

   EMail: silvia@annodex.net
   URI:   http://annodex.net/


   Christopher Montgomery
   Xiph.Org Foundation

   EMail: monty@xiph.org
   URI:   http://xiph.org



























Goncalves, et al.           Standards Track                    [Page 13]

RFC 5334                    Ogg Media Types               September 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Goncalves, et al.           Standards Track                    [Page 14]