idnits 2.17.1 draft-gellens-mime-bucket-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 559), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, I accept the provisions of Section 3 of RFC 3667 (BCP 78). == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6888 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) == Missing Reference: 'MP4-Reg' is mentioned on line 408, but not defined == Missing Reference: 'MIME-format' is mentioned on line 204, but not defined == Missing Reference: 'MIME-coding' is mentioned on line 296, but not defined == Unused Reference: 'MIME-Types' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'Media-Features' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'MP4-reg' is defined on line 480, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MP4-reg' Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Gellens 3 Document: draft-gellens-mime-bucket-04.txt Qualcomm 4 Expires: December 2005 D. Singer 5 Apple 6 P. Frojdh 7 Ericsson 8 June 2005 10 The Codecs Parameter for "Bucket" Media Types 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 By submitting this Internet-Draft, I accept the provisions of 20 Section 3 of RFC 3667 (BCP 78). 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. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt The list of 34 Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 Several MIME type/subtype combinations exist which can contain 44 different media formats. A receiving agent thus needs to examine 45 the details of such media content to determine if the specific 46 elements can be rendered given an available set of codecs. 47 Especially when the end system has limited resources, or the 48 connection to the end system has limited bandwidth, it would be 50 Gellens, Singer, Frojdh [Page 1] Expires December 2005 51 helpful to know from the Content-Type alone if the content can be 52 rendered. 54 This document adds a new parameter, "codecs", to various 55 type/subtype combinations to allow for unambiguous specification of 56 the codecs indicated by the media formats contained within. 58 By labeling content with the specific codecs indicated to render the 59 contained media, receiving systems can determine if the codecs are 60 supported by the end system, and if not, can take appropriate action 61 (such as rejecting the content, sending notification of the 62 situation, transcoding the content to a supported type, fetching and 63 installing the required codecs, further inspection to determine if 64 it will be sufficient to support a subset of the indicated codecs, 65 etc.) 67 Gellens, Singer, Frojdh [Page 2] Expires December 2005 68 Table of Contents 70 1. Conventions Used in this Document . . . . . . . . . . . . . 3 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Generic Syntax . . . . . . . . . . . . . . . . . . . . 6 74 3.2. ISO File Format Name Space . . . . . . . . . . . . . . . 7 75 3.3. ISO Syntax . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Use in Additional Media Types . . . . . . . . . . . . . . . 9 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Additional Media Feature Details . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 83 11. Informative References . . . . . . . . . . . . . . . . . . 11 84 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 85 Intellectual Property Statement . . . . . . . . . . . . . . . 12 86 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 88 1. Conventions Used in this Document 90 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 91 NOT", and "MAY" in this document are to be interpreted as described 92 in "Key words for use in RFCs to Indicate Requirement Levels" 93 [KEYWORDS]. 95 The syntax in this document uses the BNF rules specified in 96 [MIME-Format] and [MIME-Coding]. 98 2. Introduction 100 One of the original motivations for MIME is the ability to identify 101 the specific media type of a message part. However, due to various 102 factors, it is not always possible from looking at the MIME type and 103 subtype to know which specific media formats are contained in the 104 body part, or which codecs are indicated in order to render the 105 content. 107 There are several media type/subtypes (either currently registered 108 or deployed with registration pending) which may contain codecs 109 chosen from a set. It is currently necessary to examine each media 110 element in order to determine the codecs required to render the 111 content. For example, video/3gpp may contain any of the video 112 formats H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple 113 Profile, and/or any of the audio formats AMR, AMR-WB, Extended 114 AMR-WB, AAC, or Enhanced aacPlus, as specified in [3GPP-Formats]. 116 Gellens, Singer, Frojdh [Page 3] Expires December 2005 117 In some cases, the specific codecs can be determined by examining 118 the header information of the media content. While this isn't as 119 bad as examining the entire content, it still requires specialized 120 knowledge of each format and is resource consumptive. 122 This ambiguity can be a problem for various clients and servers. It 123 presents a significant burden to Multimedia Messaging (MMS) servers, 124 which must examine the media sent in each message in order to 125 determine which codecs are required to render the content. Only 126 then can such a server determine if the content requires transcoding 127 or specialized handling prior to being transmitted to the handset. 129 Additionally, it presents a challenge to smart clients on devices 130 with constrained memory, processing power, or transmission bandwidth 131 (such as cellular telephones and PDAs). Such clients often need to 132 determine in advance if they are currently capable of rendering the 133 content contained in an MMS or email message. 135 Current ambiguity: 137 o Audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or 138 Enhanced aacPlus contents as specified in [3GPP-Formats]. 139 o Audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), EVRC, SMV, 140 or VMR-WB, as specified in [3GPP2-Formats] (video/3gpp2 MIME 141 registration pending). 142 o Video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, 143 MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, 144 or Enhanced aacPlus, as specified in [3GPP-Formats]. 145 o Video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, 146 MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [13k]), 147 EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats] 148 (video/3gpp2 MIME registration pending). 150 Note that there are additional media types which are ambiguous, but 151 are outside the scope of this document, including: 152 o video/mpeg4-generic which can contain anything allowed by the 153 MPEG-4 specification, or any audio codec registered with the MP4 154 registration authority [MP4-Reg]; 155 o video/quicktime which can contain anything for which there is a 156 QuickTime codec component; since QuickTime is extensible, this 157 is not limited to the codecs that are or have been shipped by 158 Apple Computer. 160 With each "bucket" type, a receiving agent only knows that it has a 161 container format. It doesn't even know whether content labeled 162 video/3GPP or video/3GPP2 contains video; it might be audio only, 163 audio and video, or video only. 165 Gellens, Singer, Frojdh [Page 4] Expires December 2005 166 A solution which permits a receiving agent to determine the specific 167 codecs required to render media content would help provide efficient 168 and scalable servers, especially for Multimedia Messaging (MMS), and 169 aid the growth of multimedia services in wireless networks. 171 3. The Codecs Parameter 173 This document adds a parameter to allow unambiguous specification of 174 all codecs indicated to render the content in the MIME part. This 175 parameter is optional in all current types to which it is added. 176 Future types which contain ambiguity are strongly encouraged to 177 include this parameter. 179 Media types: 180 audio/3gpp, 181 audio/3gpp2*, 182 video/3gpp, 183 video/3gpp2*, 185 *registration pending 187 Parameter name: 188 Codecs 190 Parameter value: 191 A single value, or a comma-separated list of values identifying 192 the codec(s) indicated to render the content in the body part. 194 Each value consists of one or more dot-separated elements. The 195 name space for the first element is determined by the MIME type. 196 The name space for each subsequent element is determined by the 197 preceding element. 199 Note that, per [MIME-Format], some characters (including the 200 comma used to separate multiple values) require that the entire 201 parameter value be enclosed in quotes. 203 An element MAY include an octet that must be encoded in order to 204 comply with [MIME-format]. In this case, [MIME-Coding] is used: 205 an asterisk ("*") is placed at the end of the parameter name 206 (becoming "codecs*" instead of "codecs"), the parameter value 207 starts with two single quote ("'") characters (indicating that 208 neither character set nor language are specified), and each 209 octet which requires encoding is represented as a percent-sign 210 ("%") followed by two hexadecimal digits. Note that, when the 211 [MIME-Coding] form is used, the percent sign, asterisk, and 212 single quote characters have special meaning and so must 213 themselves be encoded. 215 Gellens, Singer, Frojdh [Page 5] Expires December 2005 216 Examples of Generic Syntax: 217 codecs=a.bb.ccc.d 218 codecs="a.bb.ccc.d, e.fff" 219 codecs*=''fo%2e 220 codecs*="''%25%20xz, gork" 222 When the Codecs parameter is used, it MUST contain all codecs 223 indicated by the content present in the body part. The Codecs 224 parameter MUST NOT include any codecs which are not indicated by any 225 media elements in the body part. 227 In some cases not all indicated codecs are absolutely required in 228 order to render the content. Therefore, when a receiver does not 229 support all listed codecs, special handling MAY be required. For 230 example, the media element(s) MAY need to be examined in order to 231 determine if an unsupported codec is actually required (e.g., there 232 may be alternative tracks (such as English and Spanish audio), there 233 may be timed text that can be dropped, etc.) 235 NOTE: Although the parameter value MUST be complete and accurate in 236 'breadth' (that is, it MUST report all four-character codes used in 237 all tracks for ISO-family files, for example) systems MUST NOT rely 238 on it being complete in 'depth'. If the hierarchical rules for a 239 given code (e.g., 'qvxy') were written after a server was 240 implemented, for example, that server will not know what elements to 241 place after 'qvxy'. 243 If a receiver encounters a body part whose Codecs parameter contains 244 codecs which are not indicated by any media elements, then the 245 receiver SHOULD process the body part by discarding the information 246 in the Codecs parameter. 248 If a receiver encounters a body part whose Codecs parameter does not 249 contain all codecs indicated by the media elements, then the 250 receiver MAY process the body part by discarding the information in 251 the Codecs parameter. 253 3.1. Generic Syntax 255 The Codecs parameter takes either of two forms. The first form is 256 used when the value does not contain any octets which require 257 encoding. The second form uses [MIME-Coding] to allow arbitrary 258 octets to be encoded. With either form, quotes allow for commas and 259 other characters in (quotes MAY be used even when not 260 required). 262 Gellens, Singer, Frojdh [Page 6] Expires December 2005 263 This BNF uses the rules specified in [MIME-Format] and 264 [MIME-Coding]. 266 codecs = cod-simple / cod-fancy 268 cod-simple = "codecs" "=" unencodedv 270 unencodedv = id-simple / simp-list 272 simp-list = DQUOTE id-simple *( "," id-simple ) DQUOTE 274 id-simple = element *( "." element ) 276 element = 1*octet-sim 278 octet-sim = 279 ; token defined in [MIME-Format] 281 cod-fancy = "codecs*" "=" encodedv 283 encodedv = fancy-sing / fancy-list 285 fancy-sing = "''" id-encoded 287 fancy-list = DQUOTE "''" id-list DQUOTE 289 id-list = id-encoded *( "," id-encoded ) 291 id-encoded = encoded-elm *( "." encoded-elm ) 293 encoded-elm = 1*octet-fancy 295 octet-fancy = ext-octet / attribute-char 296 ; ext-octet and attribute-char defined in [MIME-coding] 298 DQUOTE = %x22 ; " (double quote) 300 Initial name space: This document only defines values for files in 301 the ISO Base Media File Format family. Other file formats may also 302 define codec naming. 304 3.2. ISO File Format Name Space 306 Gellens, Singer, Frojdh [Page 7] Expires December 2005 307 For the ISO Base Media File Format, the first element of a 'Codecs' 308 parameter value is a sample description entry four-character code as 309 registered by the MP4 Registration Authority [MP4-Reg]. Values are 310 case-sensitive. 312 Note that there are potentially multiple tracks in a file, each 313 potentially carrying multiple sample entries (some but not all uses 314 of the ISO File Format restrict the number of sample entries in a 315 track to one). 317 When the first element of a value is 'mp4a' (indicating some kind of 318 MPEG-4 audio) or 'mp4v' (indicating some kind of MPEG-4 part-2 319 video), the second element is the hexadecimal representation of the 320 MP4 Registration Authority ObjectTypeIndication (OTI), as specified 321 in [MP4-Reg] and [MP41] (including amendments). Note that [MP4-Reg] 322 uses a leading "0x" with these values, which is omitted here and 323 hence implied. 325 One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). 326 For this value, the third element identifies the audio 327 ObjectTypeIndication (OTI) as defined in [MP4A] (including 328 amendments), expressed as a decimal number. 330 For example, AAC low complexity has the value 2, so a complete 331 string for AAC-LC would be "mp4a.40.2". 333 One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 334 video). For this value, the third element identifies the video 335 ProfileLevelIndication as defined in [MP4V] (including amendments), 336 expressed as a decimal number. 338 For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, 339 so a complete string for MPEG-4 Visual Simple Profile Level 0 would 340 be "mp4v.20.9". 342 3.3. ISO Syntax 344 id-simple =/ id-iso 346 id-encoded =/ id-iso 348 id-iso = iso-gen / iso-mpega / iso-mpegv 350 iso-gen = cpid *( "." 1(element / encoded-elm ) ) 351 ; used with 352 ; used with 354 iso-mpega = mp4a "." oti [ "." aud-oti ] 356 Gellens, Singer, Frojdh [Page 8] Expires December 2005 357 iso-mpegv = mp4v "." oti [ "." vid-pli ] 359 cpid = 4(octet-simple / octet-fancy) 360 ; used with 361 ; used with 363 mp4a = %x6d.70.34.61 ; 'mp4a' 365 oti = 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") 366 ; leading "0x" omitted 368 aud-oti = 1*DIGIT 370 mp4v = %x6d.70.34.76 ; 'mp4v' 372 vid-pli = 1*DIGIT 374 4. Use in Additional Media Types 376 This parameter MAY be specified for use with additional MIME media 377 types. 379 For ISO file formats where the name space as defined here is 380 sufficient, all that needs to be done is to update the media type 381 registration to specify the Codecs parameter with a reference to 382 this document. For existing media types, it is generally advisable 383 for the parameter to be optional; for new media types the parameter 384 MAY be optional or required, as appropriate. 386 For ISO file formats where the name space as defined here needs to 387 be expanded, a new document MAY update this one by specifying the 388 additional detail. 390 For non-ISO formats, a new document MAY update this one by 391 specifying the name space for the media type(s). 393 5. Examples 395 Content-Type: video/3GPP2; Codecs="sevc,s263" 396 (EVRC audio plus H.263 video) 397 Content-Type: audio/3gpp; Codecs=samr 398 (AMR audio) 400 Gellens, Singer, Frojdh [Page 9] Expires December 2005 401 Content-Type: video/3gpp; Codecs="s263, samr" 402 (H.263 video plus AMR audio) 403 Content-Type: audio/3gpp2; Codecs=mp4a.E1 404 (13k audio) 405 Content-Type: video/3gpp2; Codecs="mp4v.20.9, mp4a.E1" 406 (MPEG-4 Visual Simple Profile Level 0 plus 13K voice) 408 Note: OTI value 20 ("0x20" in [MP4-Reg]) says "Includes 409 associated Amendment(s) and Corrigendum(a). The actual object 410 types are defined in [MP4V] and are conveyed in the 411 DecoderSpecificInfo as specified in [MP4V], Annex K." 412 (references adjusted). 414 6. Additional Media Feature Details 416 It is sometimes helpful to provide additional details for a media 417 element (e.g., the number of X and Y pixels, the color depth, etc.). 418 These details are sometimes called "media features" and sometimes 419 "media characteristics". 421 When such additional features are included, the [Content-Features] 422 header provides a handy way to do so. 424 7. IANA Considerations 426 The IANA is kindly requested to add "Codecs" as an optional 427 parameter to the media types listed in Section 3, with a reference 428 to this document 430 8. Security Considerations 432 The codecs parameter itself does not alter the security 433 considerations of any of the media types for which it is available. 434 Each audio and video media type has its own set of security 435 considerations which continue to apply, regardless of the use of the 436 codecs parameter. 438 An incorrect codecs parameter might cause media content to be 439 received by a device which is not capable of rendering it, or might 440 cause media content to not be sent to a device which is capable of 441 receiving it. An incorrect codecs parameter is therefore capable of 442 some types of denial of service attacks. However, this is most 443 likely to arise by accident, as an attacker capable of altering 444 media data in transit could cause more harm by altering the media 445 format itself, or even the content type header, rather than just the 446 codecs parameter of the content type header. 448 Gellens, Singer, Frojdh [Page 10] Expires December 2005 449 9. Acknowledgments 451 Harinath Garudadri provided a great deal of help, which is very much 452 appreciated. Mary Barnes and Bruce Lilly provided detailed and 453 helpful comments. Reviews and comments by Sam Hartman, Russ 454 Housley, and Bert Wijnen were much appreciated. 456 10. Normative References 458 [Content-Features] Kline, G., "Indicating Media Features for MIME 459 Content", RFC 2912, September 2000. 461 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 462 Requirement Levels", March 1997, BCP 14, RFC 2119, 463 465 [MIME-Coding] Freed, N. and K. Moore, "MIME Parameter Value and 466 Encoded Word Extensions: Character Sets, Languages, and 467 Continuations", RFC 2231, November 1997. 469 [MIME-Format] Freed, N. and N. Borenstein, "Multipurpose Internet 470 Mail Extensions (MIME) Part One: Format of Internet Message 471 Bodies", RFC 2045, November 2996. 473 [MIME-Types] Freed, N. and N. Borenstein, "Multipurpose Internet 474 Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 475 1996. 477 [Media-Features] Holtman, K., A. Mutz and T. Hardie, "Media Feature 478 Tag Registration Procedure", RFC 2506, BCP 31, March 1999. 480 [MP4-reg] MP4REG, The MPEG-4 Registration Authority, 481 483 11. Informative References 485 [13k] Gellens, R and H. Garudadri, "The QCP File Format and Media 486 Types for Speech Data", RFC 3625, September 2003. 488 Gellens, Singer, Frojdh [Page 11] Expires December 2005 490 [3GPP-Formats] TS 26.244, Third Generation Partnership Project 491 (3GPP), "Transparent End-to-End Packet Switched Streaming Service; 492 3GPP file format (3GP)", URL: 493 495 [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File 496 Formats for Multimedia Service", URL: 497 499 [MP41] ISO/IEC 14496-1:2001, "Information technology--Coding of 500 audio-visual objects--Part 1: Systems". 502 [MP4A] ISO/IEC 14496-3:2001, "Information Technology--Coding of 503 Audio/Visual Object--Part 3: Audio". 505 [MP4V] ISO/IEC 14496-2:2001, "Information Technology--Coding of 506 Audio/Visual Object--Part 2: Video". 508 12. Authors' Addresses 510 Randall Gellens 511 QUALCOMM Incorporated 512 5775 Morehouse Drive 513 San Diego, CA 92121 514 USA 515 randy@qualcomm.com 517 David Singer 518 Apple Computer, Inc. 519 One Infinite Loop, MS:302-3MT 520 Cupertino CA 95014 521 USA 522 singer@apple.com 523 +1 408 974 3162 525 Per Frojdh 526 Ericsson Research 527 Multimedia Technologies 528 SE-164 80 Stockholm, SWEDEN 529 +46 8 7190000 530 Per.Frojdh@ericsson.com 532 Gellens, Singer, Frojdh [Page 12] Expires December 2005 533 Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed 537 to pertain to the implementation or use of the technology described 538 in this document or the extent to which any license under such 539 rights might or might not be available; nor does it represent that 540 it has made any independent effort to identify any such rights. 541 Information on the procedures with respect to rights in RFC 542 documents can be found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use 547 of such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository 549 at http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at 555 ietf-ipr@ietf.org. 557 Full Copyright Statement 559 Copyright (C) The Internet Society (2005). 561 This document is subject to the rights, licenses and restrictions 562 contained in BCP 78, and except as set forth therein, the authors 563 retain all their rights. 565 This document and the information contained herein are provided on 566 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 567 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 568 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 569 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 570 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 573 Gellens, Singer, Frojdh [Page 13] Expires December 2005