Remove hardcoded docdir, mandir from {doc,src}/Makefile.am, to allow
[speexdsp.git] / doc / draft-ietf-avt-rtp-speex-01-tmp.txt
1
2
3
4 AVT                                                           G. Herlein
5 Internet-Draft
6 Intended status: Standards Track                                J. Valin
7 Expires: October 24, 2007                       University of Sherbrooke
8                                                             A. Heggestad
9                                                           April 22, 2007
10
11
12                  RTP Payload Format for the Speex Codec
13                       draft-ietf-avt-rtp-speex-01 (non-final)
14
15 Status of this Memo
16
17    By submitting this Internet-Draft, each author represents that any
18    applicable patent or other IPR claims of which he or she is aware
19    have been or will be disclosed, and any of which he or she becomes
20    aware will be disclosed, in accordance with Section 6 of BCP 79.
21
22    Internet-Drafts are working documents of the Internet Engineering
23    Task Force (IETF), its areas, and its working groups.  Note that
24    other groups may also distribute working documents as Internet-
25    Drafts.
26
27    Internet-Drafts are draft documents valid for a maximum of six months
28    and may be updated, replaced, or obsoleted by other documents at any
29    time.  It is inappropriate to use Internet-Drafts as reference
30    material or to cite them other than as "work in progress."
31
32    The list of current Internet-Drafts can be accessed at
33    http://www.ietf.org/ietf/1id-abstracts.txt.
34
35    The list of Internet-Draft Shadow Directories can be accessed at
36    http://www.ietf.org/shadow.html.
37
38    This Internet-Draft will expire on October 24, 2007.
39
40 Copyright Notice
41
42    Copyright (C) The Internet Society (2007).
43
44
45
46
47
48
49
50
51
52
53
54
55 Herlein, et al.         Expires October 24, 2007                [Page 1]
56
57 Internet-Draft                    Speex                       April 2007
58
59
60 Abstract
61
62    Speex is an open-source voice codec suitable for use in Voice over IP
63    (VoIP) type applications.  This document describes the payload format
64    for Speex generated bit streams within an RTP packet.  Also included
65    here are the necessary details for the use of Speex with the Session
66    Description Protocol (SDP).
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 Herlein, et al.         Expires October 24, 2007                [Page 2]
112
113 Internet-Draft                    Speex                       April 2007
114
115
116 Editors Note
117
118    All references to RFC XXXX are to be replaced by references to the
119    RFC number of this memo, when published.
120
121
122 Table of Contents
123
124    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
125    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
126    3.  RTP usage for Speex  . . . . . . . . . . . . . . . . . . . . .  6
127      3.1.  RTP Speex Header Fields  . . . . . . . . . . . . . . . . .  6
128      3.2.  RTP payload format for Speex . . . . . . . . . . . . . . .  6
129      3.3.  Speex payload  . . . . . . . . . . . . . . . . . . . . . .  6
130      3.4.  Example Speex packet . . . . . . . . . . . . . . . . . . .  7
131      3.5.  Multiple Speex frames in a RTP packet  . . . . . . . . . .  7
132    4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
133      4.1.  Media Type Registration  . . . . . . . . . . . . . . . . .  9
134        4.1.1.  Registration of media type audio/speex . . . . . . . .  9
135    5.  SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . . 11
136    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
137    7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
138    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
139      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
140      8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
141    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
142    Intellectual Property and Copyright Statements . . . . . . . . . . 18
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 Herlein, et al.         Expires October 24, 2007                [Page 3]
168
169 Internet-Draft                    Speex                       April 2007
170
171
172 1.  Introduction
173
174    Speex is based on the CELP [CELP] encoding technique with support for
175    either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
176    wideband (nominal 32kHz).  The main characteristics can be summarized
177    as follows:
178
179    o  Free software/open-source
180
181    o  Integration of wideband and narrowband in the same bit-stream
182
183    o  Wide range of bit-rates available
184
185    o  Dynamic bit-rate switching and variable bit-rate (VBR)
186
187    o  Voice Activity Detection (VAD, integrated with VBR)
188
189    o  Variable complexity
190
191    To be compliant with this specification, implementations MUST support
192    8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate.
193    The sampling rate MUST be 8, 16 or 32 kHz.
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 Herlein, et al.         Expires October 24, 2007                [Page 4]
224
225 Internet-Draft                    Speex                       April 2007
226
227
228 2.  Terminology
229
230    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232    document are to be interpreted as described in RFC2119 [RFC2119] and
233    indicate requirement levels for compliant RTP implementations.
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 Herlein, et al.         Expires October 24, 2007                [Page 5]
280
281 Internet-Draft                    Speex                       April 2007
282
283
284 3.  RTP usage for Speex
285
286 3.1.  RTP Speex Header Fields
287
288    The RTP header is defined in the RTP specification [RFC3550].  This
289    section defines how fields in the RTP header are used.
290
291       Payload Type (PT): The assignment of an RTP payload type for this
292       packet format is outside the scope of this document; it is
293       specified by the RTP profile under which this payload format is
294       used, or signaled dynamically out-of-band (e.g., using SDP).
295
296       Marker (M) bit: The M bit is set to one to indicate that the RTP
297       packet payload contains at least one complete frame
298
299       Extension (X) bit: Defined by the RTP profile used.
300
301       Timestamp: A 32-bit word that corresponds to the sampling instant
302       for the first frame in the RTP packet.
303
304 3.2.  RTP payload format for Speex
305
306    The RTP payload for Speex has the format shown in Figure 1.  No
307    additional header fields specific to this payload format are
308    required.  For RTP based transportation of Speex encoded audio the
309    standard RTP header [RFC3550] is followed by one or more payload data
310    blocks.  An optional padding terminator may also be used.
311
312         0                   1                   2                   3
313         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
314        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
315        |                         RTP Header                            |
316        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
317        |                 one or more frames of Speex ....              |
318        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319        |        one or more frames of Speex ....       |    padding    |
320        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
321
322                      Figure 1: RTP payload for Speex
323
324 3.3.  Speex payload
325
326    For the purposes of packetizing the bit stream in RTP, it is only
327    necessary to consider the sequence of bits as output by the Speex
328    encoder [speexenc], and present the same sequence to the decoder.
329    The payload format described here maintains this sequence.
330
331    A typical Speex frame, encoded at the maximum bitrate, is approx. 110
332
333
334
335 Herlein, et al.         Expires October 24, 2007                [Page 6]
336
337 Internet-Draft                    Speex                       April 2007
338
339
340    octets and the total number of Speex frames SHOULD be kept less than
341    the path MTU to prevent fragmentation.  Speex frames MUST NOT be
342    fragmented across multiple RTP packets,
343
344    An RTP packet MAY contain Speex frames of the same bit rate or of
345    varying bit rates, since the bit-rate for a frame is conveyed in band
346    with the signal.
347
348    The encoding and decoding algorithm can change the bit rate at any 20
349    msec frame boundary, with the bit rate change notification provided
350    in-band with the bit stream.  Each frame contains both "mode"
351    (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate)
352    information in the bit stream.  No out-of-band notification is
353    required for the decoder to process changes in the bit rate sent by
354    the encoder.
355
356    Sampling rate values of 8000, 16000 or 32000 Hz MUST be used.  Any
357    other sampling rates MUST NOT be used.
358
359    The RTP payload MUST be padded to provide an integer number of octets
360    as the payload length.  These padding bits are LSB aligned in network
361    octet order and consist of a 0 followed by all ones (until the end of
362    the octet).  This padding is only required for the last frame in the
363    packet, and only to ensure the packet contents ends on an octet
364    boundary.
365
366 3.4.  Example Speex packet
367
368    In the example below we have a single Speex frame with 5 bits of
369    padding to ensure the packet size falls on an octet boundary.
370
371        0                   1                   2                   3
372        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
373       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
374       |                      RTP Header                               |
375       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
376       |                        ..speex data..                         |
377       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
378       |                        ..speex data..               |0 1 1 1 1|
379       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
380
381 3.5.  Multiple Speex frames in a RTP packet
382
383    Below is an example of two Speex frames contained within one RTP
384    packet.  The Speex frame length in this example fall on an octet
385    boundary so there is no padding.
386
387    Speex codecs [speexenc] are able to detect the bitrate from the
388
389
390
391 Herlein, et al.         Expires October 24, 2007                [Page 7]
392
393 Internet-Draft                    Speex                       April 2007
394
395
396    payload and are responsible for detecting the 20 msec boundaries
397    between each frame.
398
399        0                   1                   2                   3
400        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
401       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
402       |                      RTP Header                               |
403       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
404       |                     ..speex frame 1..                         |
405       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
406       |       ..speex frame 1..       |      ..speex frame 2..        |
407       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
408       |                      ..speex frame 2..                        |
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 Herlein, et al.         Expires October 24, 2007                [Page 8]
448
449 Internet-Draft                    Speex                       April 2007
450
451
452 4.  IANA Considerations
453
454    This document defines the Speex media type.
455
456 4.1.  Media Type Registration
457
458    This section describes the media types and names associated with this
459    payload format.  The section registers the media types, as per
460    RFC4288 [RFC4288]
461
462 4.1.1.  Registration of media type audio/speex
463
464    Media type name: audio
465
466    Media subtype name: speex
467
468    Required parameters:
469
470    None
471
472    Optional parameters:
473
474       ptime: see RFC 4566.  SHOULD be a multiple of 20 msec.
475
476       maxptime: see RFC 4566.  SHOULD be a multiple of 20 msec.
477
478    Encoding considerations:
479
480       This media type is framed and binary, see section 4.8 in
481       [RFC4288].
482
483    Security considerations: See Section 6
484
485    Interoperability considerations:
486
487       None.
488
489    Published specification: RFC XXXX [This RFC].
490
491    Applications which use this media type:
492
493       Audio streaming and conferencing applications.
494
495    Additional information: none
496
497    Person and email address to contact for further information :
498
499
500
501
502
503 Herlein, et al.         Expires October 24, 2007                [Page 9]
504
505 Internet-Draft                    Speex                       April 2007
506
507
508       Alfred E. Heggestad: aeh@db.org
509
510    Intended usage: COMMON
511
512    Restrictions on usage:
513
514       This media type depends on RTP framing, and hence is only defined
515       for transfer via RTP [RFC3550].  Transport within other framing
516       protocols is not defined at this time.
517
518    Author: Alfred E. Heggestad
519
520    Change controller:
521
522       IETF Audio/Video Transport working group delegated from the IESG.
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 Herlein, et al.         Expires October 24, 2007               [Page 10]
560
561 Internet-Draft                    Speex                       April 2007
562
563
564 5.  SDP usage of Speex
565
566    When conveying information by SDP [RFC4566], the encoding name MUST
567    be set to "speex".  An example of the media representation in SDP for
568    offering a single channel of Speex at 8000 samples per second might
569    be:
570
571              m=audio 8088 RTP/AVP 97
572              a=rtpmap:97 speex/8000
573
574    Note that the RTP payload type code of 97 is defined in this media
575    definition to be 'mapped' to the speex codec at an 8kHz sampling
576    frequency using the 'a=rtpmap' line.  Any number from 96 to 127 could
577    have been chosen (the allowed range for dynamic types).
578
579    The value of the sampling frequency is typically 8000 for narrow band
580    operation, 16000 for wide band operation, and 32000 for ultra-wide
581    band operation.
582
583    If for some reason the offerer has bandwidth limitations, the client
584    may use the "b=" header, as explained in SDP [RFC4566].  The
585    following example illustrates the case where the offerer cannot
586    receive more than 10 kbit/s.
587
588              m=audio 8088 RTP/AVP 97
589              b=AS:10
590              a=rtmap:97 speex/8000
591
592    In this case, if the remote part agrees, it should configure its
593    Speex encoder so that it does not use modes that produce more than 10
594    kbit/s.  Note that the "b=" constraint also applies on all payload
595    types that may be proposed in the media line ("m=").
596
597    An other way to make recommendations to the remote Speex encoder is
598    to use its specific parameters via the a=fmtp: directive.  The
599    following parameters are defined for use in this way:
600
601       ptime: duration of each packet in milliseconds.
602
603
604       sr: actual sample rate in Hz.
605
606
607       ebw: encoding bandwidth - either 'narrow' or 'wide' or 'ultra'
608       (corresponds to nominal 8000, 16000, and 32000 Hz sampling rates).
609
610
611
612
613
614
615 Herlein, et al.         Expires October 24, 2007               [Page 11]
616
617 Internet-Draft                    Speex                       April 2007
618
619
620       vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults to
621       off).  If on, variable bit rate is enabled.  If off, disabled.  If
622       set to 'vad' then constant bit rate is used but silence will be
623       encoded with special short frames to indicate a lack of voice for
624       that period.
625
626
627       cng: comfort noise generation - either 'on' or 'off'.  If off then
628       silence frames will be silent; if 'on' then those frames will be
629       filled with comfort noise.
630
631
632       mode: Speex encoding mode.  Can be {1,2,3,4,5,6,any} defaults to 3
633       in narrowband, 6 in wide and ultra-wide.
634
635
636    Examples:
637
638       m=audio 8008 RTP/AVP 97
639       a=rtpmap:97 speex/8000
640       a=fmtp:97 mode=4
641
642    This examples illustrate an offerer that wishes to receive a Speex
643    stream at 8000Hz, but only using speex mode 4.
644
645    Several Speex specific parameters can be given in a single a=fmtp
646    line provided that they are separated by a semi-colon:
647
648       a=fmtp:97 mode=any;mode=1
649
650    The offerer may indicate that it wishes to send variable bit rate
651    frames with comfort noise:
652
653              m=audio 8088 RTP/AVP 97
654              a=rtmap:97 speex/8000
655              a=fmtp:97 vbr=on;cng=on
656
657    The "ptime" attribute is used to denote the packetization interval
658    (ie, how many milliseconds of audio is encoded in a single RTP
659    packet).  Since Speex uses 20 msec frames, ptime values of multiples
660    of 20 denote multiple Speex frames per packet.  Values of ptime which
661    are not multiples of 20 MUST be ignored and clients MUST use the
662    default value of 20 instead.
663
664    Implementations SHOULD support ptime of 20 msec (i.e. one frame per
665    packet)
666
667    In the example below the ptime value is set to 40, indicating that
668
669
670
671 Herlein, et al.         Expires October 24, 2007               [Page 12]
672
673 Internet-Draft                    Speex                       April 2007
674
675
676    there are 2 frames in each packet.
677
678              m=audio 8008 RTP/AVP 97
679              a=rtpmap:97 speex/8000
680              a=ptime:40
681
682    Note that the ptime parameter applies to all payloads listed in the
683    media line and is not used as part of an a=fmtp directive.
684
685    Values of ptime not multiple of 20 msec are meaningless, so the
686    receiver of such ptime values MUST ignore them.  If during the life
687    of an RTP session the ptime value changes, when there are multiple
688    Speex frames for example, the SDP value must also reflect the new
689    value.
690
691    Care must be taken when setting the value of ptime so that the RTP
692    packet size does not exceed the path MTU.
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 Herlein, et al.         Expires October 24, 2007               [Page 13]
728
729 Internet-Draft                    Speex                       April 2007
730
731
732 6.  Security Considerations
733
734    RTP packets using the payload format defined in this specification
735    are subject to the security considerations discussed in the RTP
736    specification [RFC3550], and any appropriate RTP profile.  This
737    implies that confidentiality of the media streams is achieved by
738    encryption.  Because the data compression used with this payload
739    format is applied end-to-end, encryption may be performed after
740    compression so there is no conflict between the two operations.
741
742    A potential denial-of-service threat exists for data encodings using
743    compression techniques that have non-uniform receiver-end
744    computational load.  The attacker can inject pathological datagrams
745    into the stream which are complex to decode and cause the receiver to
746    be overloaded.  However, this encoding does not exhibit any
747    significant non-uniformity.
748
749    As with any IP-based protocol, in some circumstances a receiver may
750    be overloaded simply by the receipt of too many packets, either
751    desired or undesired.  Network-layer authentication may be used to
752    discard packets from undesired sources, but the processing cost of
753    the authentication itself may be too high.
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 Herlein, et al.         Expires October 24, 2007               [Page 14]
784
785 Internet-Draft                    Speex                       April 2007
786
787
788 7.  Acknowledgements
789
790    The authors would like to thank Equivalence Pty Ltd of Australia for
791    their assistance in attempting to standardize the use of Speex in
792    H.323 applications, and for implementing Speex in their open source
793    OpenH323 stack.  The authors would also like to thank Brian C. Wiles
794    <brian@streamcomm.com> of StreamComm for his assistance in developing
795    the proposed standard for Speex use in H.323 applications.
796
797    The authors would also like to thank the following members of the
798    Speex and AVT communities for their input: Ross Finlayson, Federico
799    Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund.
800
801    Thanks to former authors of this document; Simon Morlat, Roger
802    Hardiman, Phil Kerr
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839 Herlein, et al.         Expires October 24, 2007               [Page 15]
840
841 Internet-Draft                    Speex                       April 2007
842
843
844 8.  References
845
846 8.1.  Normative References
847
848    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
849               Requirement Levels", BCP 14, RFC 2119, March 1997.
850
851    [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
852               Jacobson, "RTP: A Transport Protocol for Real-Time
853               Applications", STD 64, RFC 3550, July 2003.
854
855    [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
856               Description Protocol", RFC 4566, July 2006.
857
858 8.2.  Informative References
859
860    [CELP]     "CELP, U.S. Federal Standard 1016.", National Technical
861               Information Service (NTIS) website http://www.ntis.gov/.
862
863    [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
864               Registration Procedures", BCP 13, RFC 4288, December 2005.
865
866    [speexenc]
867               Valin, J., "Speexenc/speexdec, reference command-line
868               encoder/decoder", Speex website http://www.speex.org/.
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895 Herlein, et al.         Expires October 24, 2007               [Page 16]
896
897 Internet-Draft                    Speex                       April 2007
898
899
900 Authors' Addresses
901
902    Greg Herlein
903    2034 Filbert Street
904    San Francisco, California  94123
905    United States
906
907    Email: gherlein@herlein.com
908
909
910    Jean-Marc Valin
911    University of Sherbrooke
912    Department of Electrical and Computer Engineering
913    University of Sherbrooke
914    2500 blvd Universite
915    Sherbrooke, Quebec  J1K 2R1
916    Canada
917
918    Email: jean-marc.valin@usherbrooke.ca
919
920
921    Alfred E. Heggestad
922    Biskop J. Nilssonsgt. 20a
923    Oslo  0659
924    Norway
925
926    Email: aeh@db.org
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951 Herlein, et al.         Expires October 24, 2007               [Page 17]
952
953 Internet-Draft                    Speex                       April 2007
954
955
956 Full Copyright Statement
957
958    Copyright (C) The Internet Society (2007).
959
960    This document is subject to the rights, licenses and restrictions
961    contained in BCP 78, and except as set forth therein, the authors
962    retain all their rights.
963
964    This document and the information contained herein are provided on an
965    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
966    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
967    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
968    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
969    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
970    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
971
972
973 Intellectual Property
974
975    The IETF takes no position regarding the validity or scope of any
976    Intellectual Property Rights or other rights that might be claimed to
977    pertain to the implementation or use of the technology described in
978    this document or the extent to which any license under such rights
979    might or might not be available; nor does it represent that it has
980    made any independent effort to identify any such rights.  Information
981    on the procedures with respect to rights in RFC documents can be
982    found in BCP 78 and BCP 79.
983
984    Copies of IPR disclosures made to the IETF Secretariat and any
985    assurances of licenses to be made available, or the result of an
986    attempt made to obtain a general license or permission for the use of
987    such proprietary rights by implementers or users of this
988    specification can be obtained from the IETF on-line IPR repository at
989    http://www.ietf.org/ipr.
990
991    The IETF invites any interested party to bring to its attention any
992    copyrights, patents or patent applications, or other proprietary
993    rights that may cover technology that may be required to implement
994    this standard.  Please address the information to the IETF at
995    ietf-ipr@ietf.org.
996
997
998 Acknowledgment
999
1000    Funding for the RFC Editor function is provided by the IETF
1001    Administrative Support Activity (IASA).
1002
1003
1004
1005
1006
1007 Herlein, et al.         Expires October 24, 2007               [Page 18]
1008