idnits 2.17.1 draft-ietf-sipping-ipv6-torture-tests-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 4, 2007) is 6202 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3330 (Obsoleted by RFC 5735) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-v6-transition-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Informational C. Boulton 5 Expires: November 5, 2007 Ubiquity Software Corporation 6 R. Sparks 7 Estacado Systems 8 May 4, 2007 10 Session Initiation Protocol (SIP) Torture Test Messages for Internet 11 Protocol Version 6 (IPv6) 12 draft-ietf-sipping-ipv6-torture-tests-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 5, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This informational document provides examples of Session Initiation 46 Protocol (SIP) test messages designed to exercise and "torture" the 47 code of a SIP implementation that parses IPv6 addresses. 49 This work is being discussed on the sipping@ietf.org mailing list. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Document conventions . . . . . . . . . . . . . . . . . . . . . 3 55 3. SIP and IPv6 network configuration . . . . . . . . . . . . . . 4 56 4. Parser torture tests . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Valid SIP message with an IPv6 reference . . . . . . . . . 5 58 4.2. Invalid SIP message with an IPv6 reference . . . . . . . . 5 59 4.3. Port ambiguous in a URI . . . . . . . . . . . . . . . . . 6 60 4.4. Port unambiguous in a URI . . . . . . . . . . . . . . . . 6 61 4.5. IPv6 reference delimiters in Via header addresses . . . . 7 62 4.6. SIP request with IPv6 addresses in Session Description 63 Protocol (SDP) body . . . . . . . . . . . . . . . . . . . 8 64 4.7. Multiple IP addresses in SIP headers . . . . . . . . . . . 9 65 4.8. Multiple IP addresses in SDP . . . . . . . . . . . . . . . 10 66 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 67 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative references . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative references . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Bit-exact archive of each test message . . . . . . . 12 73 A.1. Encoded reference messages . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . . . . 15 77 1. Overview 79 This document is informational, and is NOT NORMATIVE on any aspect of 80 SIP. 82 This document contains test messages based on the current version 83 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 85 This document is expected to be used as a companion document to the 86 more general SIP torture test document [RFC4475], which does not 87 include specific tests for IPv6 network identifiers. 89 This document does not attempt to catalog every way to make an 90 invalid message, nor does it attempt to be comprehensive in exploring 91 unusual, but valid, messages. Instead, it tries to focus on areas 92 that may cause interoperability problems in IPv6 deployments. 94 2. Document conventions 96 This document contains many example SIP messages. The appendix 97 contains an encoded binary form containing the bit-exact 98 representation of the messages and the algorithm needed to decode 99 them into separate files. 101 The IPv6 addresses used in this document correspond to the 2001: 102 DB8::/32 address prefix reserved for documentation [RFC3489]. 103 Likewise, the IPv4 addresses used in this document correspond to the 104 192.0.2.0/24 address block as described in [RFC3330]. 106 Although SIP is a text-based protocol, some of these examples cannot 107 be unambiguously rendered without additional markup due to the 108 constraints placed on the formatting of RFCs. This document uses the 109 markup convention established in [RFC4475] to avoid 110 ambiguity and meet the Internet-Draft layout requirements. For the 111 sake of completeness, the text defining this markup from Section 2.1 112 of [RFC4475] is reproduced in its entirety below: 114 "Several of these examples contain unfolded lines longer than 72 115 characters. These are captured between tags. The 116 single unfolded line is reconstructed by directly concatenating all 117 lines appearing between the tags (discarding any line feeds or 118 carriage returns). There will be no whitespace at the end of lines. 119 Any whitespace appearing at a fold-point will appear at the beginning 120 of a line. 122 "The following represent the same string of bits: 124 Header-name: first value, reallylongsecondvalue, third value 126 127 Header-name: first value, 128 reallylongsecondvalue 129 , third value 130 132 133 Header-name: first value, 134 reallylong 135 second 136 value, 137 third value 138 140 "Note that this is NOT SIP header-line folding, where different 141 strings of bits have equivalent meaning." 143 3. SIP and IPv6 network configuration 145 System-level issues like deploying a dual-stack proxy server, 146 populating DNS with A and AAAA Resource Records (RRs), zero- 147 configuration discovery of outbound proxies for IPv4 and IPv6 148 networks, when should a dual-stack proxy Record-Route itself, and 149 media issues also play a major part in the transition to IPv6. This 150 document does not, however, address these issues. Instead, a 151 companion document [ID.sip-trans] provides more guidance on these 152 issues. 154 4. Parser torture tests 156 The test messages are organized into several sections. Some stress 157 only a SIP parser and others stress both the parser and the 158 application above it. Some messages are valid, and some are not. 159 Each example clearly calls out what makes any invalid messages 160 incorrect. 162 Please refer to the complete Augmented Backus-Naur Form (ABNF) in 163 [RFC3261] on representing IPv6 references in SIP. IPv6 references 164 are delimited by a "[" and "]". When an IPv6 reference is part of a 165 SIP Uniform Resource Identifier (URI), RFC3261 mandates that the 166 "IPv6reference" production rule be used to recognize tokens that 167 comprise an IPv6 reference. More specifically, the ABNF states: 169 SIP-URI = "sip:" [ userinfo ] hostport 170 uri-parameters [ headers ] 171 hostport = host [ ":" port ] 172 host = hostname / IPv4address / IPv6reference 173 IPv6reference = "[" IPv6address "]" 174 IPv6address = hexpart [ ":" IPv4address ] 175 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 176 hexseq = hex4 *( ":" hex4) 177 hex4 = 1*4HEXDIG 179 4.1. Valid SIP message with an IPv6 reference 181 The request below is well-formatted according to the grammar in 182 [RFC3261]. An IPv6 reference appears in the Request-URI (R-URI), Via 183 header field, and Contact header field. 185 Message Details: ipv6-good 187 REGISTER sip:[2001:db8::10] SIP/2.0 188 To: sip:user@example.com 189 From: sip:user@example.com;tag=81x2 190 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 191 Call-ID: SSG9559905523997077@hlau_4100 192 Max-Forwards: 70 193 Contact: "Caller" 194 CSeq: 98176 REGISTER 195 Content-Length: 0 197 4.2. Invalid SIP message with an IPv6 reference 199 The request below is not well-formatted according to the grammar in 200 [RFC3261]. The IPv6 reference in the R-URI does not contain the 201 mandated delimiters for an IPv6 reference ("[" and "]"). 203 An element receiving this request should respond with a 400 Bad 204 Request error. 206 Message Details: ipv6-bad 208 REGISTER sip:2001:db8::10 SIP/2.0 209 To: sip:user@example.com 210 From: sip:user@example.com;tag=81x2 211 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 212 Call-ID: SSG9559905523997077@hlau_4100 213 Max-Forwards: 70 214 Contact: "Caller" 215 CSeq: 98176 REGISTER 216 Content-Length: 0 218 4.3. Port ambiguous in a URI 220 IPv6 uses the colon to delimit octets. This may lead to ambiguity if 221 the port number on which to contact a SIP server is inadvertently 222 conflated with the IPv6 reference. Consider the REGISTER request 223 below. The sender of the request intended to specify a port number 224 (5070) to contact a server, but inadvertently, inserts the port 225 number inside the closing "]" of the IPv6 reference. Unfortunately, 226 since the IPv6 address in the R-URI is compressed, the intended port 227 number becomes the last octet of the reference. 229 From a parsing perspective, the request below is well-formed. 230 However, from a semantic point of view, it will not yield the desired 231 result. Implementations must ensure that when a raw IPv6 address 232 appears in a SIP URI, then a port number, if required, appears 233 outside the closing "]" delimiting the IPv6 reference. Raw IPv6 234 addresses can appear in the "sent-by" production rule of the Via 235 header field, the Contact header field, the Route and Record-Route 236 headers, among other headers. Implementers are urged to consult the 237 ABNF in [RFC3261] for a complete list of fields where a SIP URI can 238 appear. 240 Message Details: port-ambiguous 242 REGISTER sip:[2001:db8::10:5070] SIP/2.0 243 To: sip:user@example.com 244 From: sip:user@example.com;tag=81x2 245 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 246 Call-ID: SSG9559905523997077@hlau_4100 247 Contact: "Caller" 248 Max-Forwards: 70 249 CSeq: 98176 REGISTER 250 Content-Length: 0 252 4.4. Port unambiguous in a URI 254 In contrast to the example in Section 4.3, the following REGISTER 255 request leaves no ambiguity whatsoever on where the IPv6 address ends 256 and the port number begins. This REGISTER request is well formatted 257 per the grammar in [RFC3261]. 259 Message Details: port-unambiguous 260 REGISTER sip:[2001:db8::10]:5070 SIP/2.0 261 To: sip:user@example.com 262 From: sip:user@example.com;tag=81x2 263 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 264 Call-ID: SSG9559905523997077@hlau_4100 265 Contact: "Caller" 266 Max-Forwards: 70 267 CSeq: 98176 REGISTER 268 Content-Length: 0 270 4.5. IPv6 reference delimiters in Via header addresses 272 IPv6 references can also appear in Via header fields; more 273 specifically in the "sent-by" production rule and the "via-received" 274 production rule. In the "sent-by" production rule, the sequence of 275 octets comprising the IPv6 address is defined to appear as an 276 "IPv6reference" non-terminal, thereby mandating the "[" and "]" 277 delimiters. However, this is not the case for the "via-received" 278 non-terminal. The "via-received" production rule is defined thusly: 280 via-received = "received" EQUAL (IPv4address / IPv6address) 282 The "IPv6address" non-terminal is defined not to include the 283 delimiting "[" and "]". This has lead to the situation documented 284 during the 18th SIP Interoperability Event [Email-SIPit]: 286 Those testing IPv6 made different assumptions about enclosing 287 literal v6 addresses in Vias in []. By the end of the event, most 288 implementations were accepting either. Its about 50/50 on what 289 gets sent. 291 While it would be beneficial if the same non-terminal 292 ("IPv6reference") was used for both the "sent-by" and "via-received" 293 production rules, there has not been a consensus in the working group 294 to that effect. Thus, the best that can be suggested is that 295 implementations must follow the Robustness Principle [RFC1122] and be 296 liberal in accepting a "received" parameter with or without the 297 delimiting "[" and "]" tokens. When sending a request, 298 implementations must not put the delimiting "[" and "]" tokens. 300 The two test cases below are designed to stress this behavior. An 301 element receiving either of these messages must parse them 302 successfully. 304 The request below contains an IPv6 address in the Via received 305 parameter. The IPv6 address is delimited by "[" and "]". Even 306 though this is not a valid request based on a strict interpretation 307 of the grammar in [RFC3261], robust implementations must nonetheless 308 be able to parse the topmost Via header field and continue processing 309 the request. 311 Message Details: via-received-param-with-delim 313 BYE sip:[2001:db8::10] SIP/2.0 314 To: sip:user@example.com;tag=bd76ya 315 From: sip:user@example.com;tag=81x2 316 317 Via: SIP/2.0/UDP [2001:db8::9:1];received=[2001:db8::9:255]; 318 branch=z9hG4bKas3-111 319 320 Call-ID: SSG9559905523997077@hlau_4100 321 Max-Forwards: 70 322 CSeq: 321 BYE 323 Content-Length: 0 325 The OPTIONS request below contains an IPv6 address in the Via 326 received parameter without the adorning "[" and "]". This request is 327 valid according to the grammar in [RFC3261]. 329 Message Details: via-received-param-no-delim 331 OPTIONS sip:[2001:db8::10] SIP/2.0 332 To: sip:user@example.com 333 From: sip:user@example.com;tag=81x2 334 335 Via: SIP/2.0/UDP [2001:db8::9:1];received=2001:db8::9:255; 336 branch=z9hG4bKas3 337 338 Call-ID: SSG95523997077@hlau_4100 339 Max-Forwards: 70 340 Contact: "Caller" 341 CSeq: 921 OPTIONS 342 Content-Length: 0 344 4.6. SIP request with IPv6 addresses in Session Description Protocol 345 (SDP) body 347 This request below is valid and well-formed according to the grammar 348 in [RFC3261]. Note that the IPv6 addresses in the SDP [RFC4566] body 349 do not have the delimiting "[" and "]". 351 Message Details: ipv6-in-sdp 352 INVITE sip:user@[2001:db8::10] SIP/2.0 353 To: sip:user@[2001:db8::10] 354 From: sip:user@example.com;tag=81x2 355 Via: SIP/2.0/UDP [2001:db8::20];branch=z9hG4bKas3-111 356 Call-ID: SSG9559905523997077@hlau_4100 357 Contact: "Caller" 358 CSeq: 8612 INVITE 359 Max-Forwards: 70 360 Content-Type: application/sdp 361 Content-Length: 268 363 v=0 364 o=assistant 971731711378798081 0 IN IP6 2001:db8::20 365 s=Live video feed for today's meeting 366 c=IN IP6 2001:db8::20 367 t=3338481189 3370017201 368 m=audio 6000 RTP/AVP 2 369 a=rtpmap:2 G726-32/8000 370 m=video 6024 RTP/AVP 107 371 a=rtpmap:107 H263-1998/90000 373 4.7. Multiple IP addresses in SIP headers 375 Th request below is valid and well-formed according to the grammar in 376 [RFC3261]. The Via list contains a mix of IPv4 addresses and IPv6 377 references. 379 Message Details: mult-ip-in-header 381 BYE sip:user@host.example.net SIP/2.0 382 Via: SIP/2.0/UDP [2001:db8::9:1]:6050;branch=z9hG4bKas3-111 383 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKjhja8781hjuaij65144 384 385 Via: SIP/2.0/TCP [2001:db8::9:255];branch=z9hG4bK451jj; 386 received=192.0.2.200 387 388 Call-ID: 997077@lau_4100 389 Max-Forwards: 70 390 CSeq: 89187 BYE 391 To: sip:user@example.net;tag=9817--94 392 From: sip:user@example.com;tag=81x2 393 Content-Length: 0 395 4.8. Multiple IP addresses in SDP 397 The request below is valid and well-formed according to the grammar 398 in [RFC3261]. The SDP contains multiple media lines, and each media 399 line is identified by a different network connection address. 401 Message Details: mult-ip-in-sdp 403 INVITE sip:user@[2001:db8::10] SIP/2.0 404 To: sip:user@[2001:db8::10] 405 From: sip:user@example.com;tag=81x2 406 Via: SIP/2.0/UDP [2001:db8::9:1];branch=z9hG4bKas3-111 407 Call-ID: SSG9559905523997077@hlau_4100 408 Contact: "Caller" 409 Max-Forwards: 70 410 CSeq: 8912 INVITE 411 Content-Type: application/sdp 412 Content-Length: 181 414 v=0 415 o=bob 280744730 28977631 IN IP4 host.example.com 416 s= 417 t=0 0 418 m=audio 22334 RTP/AVP 0 419 c=IN IP4 192.0.2.1 420 m=video 6024 RTP/AVP 107 421 c=IN IP6 2001:db8::1 422 a=rtpmap:107 H263-1998/90000 424 5. Security considerations 426 This document presents NON-NORMATIVE examples of SIP session 427 establishment. The security considerations in [RFC3261] apply. 429 Parsers must carefully consider edge conditions and malicious input 430 as part of their design. Attacks on many Internet systems use 431 crafted input to cause implementations to behave in undesirable ways. 432 Many of the messages in this draft are designed to stress a parser 433 implementation at points traditionally used for such attacks. This 434 document does not, however, attempt to be comprehensive. It contains 435 some common pitfalls that the authors have discovered while parsing 436 IPv6 identifiers in SIP implementations. 438 6. IANA considerations 440 This document does not contain any actions for IANA. 442 7. Acknowledgments 444 The authors thank Jeroen van Bemmel, Dennis Bijwaard, Gonzalo 445 Camarillo, Bob Gilligan, Alan Jeffrey, Larry Kollasch, Erik Nordmark, 446 Kumiko Ono, Pekka Pessi, and other members of the SIP-related working 447 groups for input provided during the construction of the document and 448 discussion of the test cases. 450 A.B. Nataraju and A.C. Mahendran provided working group last call 451 comments. 453 8. References 455 8.1. Normative references 457 [RFC1122] Braden, R., "Requirements for Internet Hosts - 458 Communication Layers", STD 3, RFC 1122, October 1989. 460 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 461 A., Peterson, J., Sparks, R., Handley, M., and E. 462 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 463 June 2002. 465 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 466 September 2002. 468 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 469 "STUN - Simple Traversal of User Datagram Protocol (UDP) 470 Through Network Address Translators (NATs)", RFC 3489, 471 March 2003. 473 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 474 and H. Schulzrinne, "Session Initiation Protocol (SIP) 475 Torture Test Messages", RFC 4475, May 2006. 477 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 478 Description Protocol", RFC 4566, July 2006. 480 8.2. Informative references 482 [ID.sip-trans] 483 Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 484 Transition in the Session Initiation Protocol (SIP)", 485 draft-ietf-sipping-v6-transition-04.txt (work in 486 progress), September 2006. 488 [Email-SIPit] 489 Sparks, R., "preliminary report: SIPit 18", Electronic 490 Mail archived at http://www1.ietf.org/mail-archive/web/ 491 sip/current/msg14103.html, April 2006. 493 Appendix A. Bit-exact archive of each test message 495 The following text block is an encoded, gzip compressed TAR archive 496 of files that represent each of the example messages discussed in 497 Section 4. 499 To recover the compressed archive file intact, the text of this 500 document may be passed as input to the following Perl script (the 501 output should be redirected to a file or piped to "tar -xzvf -"). 503 #!/usr/bin/perl 504 use strict; 505 my $bdata = ""; 506 use MIME::Base64; 507 while(<>) { 508 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 509 if ( m/^\s*[^\s]+\s*$/) { 510 $bdata = $bdata . $_; 511 } 512 } 513 } 514 print decode_base64($bdata); 516 Alternatively, the base-64 encoded block can be edited by hand to 517 remove document structure lines and fed as input to any base-64 518 decoding utility. 520 A.1. Encoded reference messages 521 -- BEGIN MESSAGE ARCHIVE -- 522 H4sICN2EHkYAA2FyY2hpdmUudGFyAO1ZXXPiNhTNs3+FZl/65KAry5Ll1J202WzKd 523 LvLBJqZTifTEdiLTfFHbcMm++tXNjEQAjhpgN0mPi8YJPnaQufco6sgmTK9L92jPQ 524 IDxozSI4wxcIaLz+Ly7hNjSo0jwAxzEwPhXP0OhAI5wvt8qAqTLJepCjn9Z7i1X5z 525 7XrqlffYm1cvx3T7k/nB5ftHu9s4vURYkNlEzb7t9y7YBo2670yLHWOvFdtk4ybz0 526 1LuRYTL2jgdxqL1L43B900kuh44FN0S7CqRd3an1x9sO+msRQ9hwfdJPZTTwnS/Cv 527 6D932Rm6ACgncnxWG+/VUO7F8I0hcCmSQwhOOb81B/Lyd9UrSntd3mjv4vTzzJ1Mx 528 txrJ3FUS4HuY3eFHfw0jfox+L5BuWX06XYcP2Tdtb1/rWRsNSaRNU0lHfwolx/70X 529 D3LcR1rRv/RftFUHB/2Ec71MA6vlvLvhPaMl/hlnD/wPgHv+XCYKvGwV4BQpQ8j+I 530 9MxN9hajhv+AOan4TzAr87+BTaPh/wHQ/nDV7p0vOPwYCbjf59kqQPAzReDRnFeRK 531 tJbDAiavfx6ESkkoHebeDaSSTIOBjIP4qilaPJAIAizNG3qYC12ZJYFaj1FORIcuA 532 EcwOAWFxa2AGEVD7U7DC0/kJY574Oph6aB68Xok+e56FOcojx25e0PGQo9Lw+ioTZ 533 w1o3NHcMwLGoBWAIZBi/4RTBooSMnbhAjplYiuux1Wj9fdRDRpJPmSSiVz0MXnDDd 534 IC1L9VDdZ9EZJnTeXbFyMUB9Qb8Spv4VIayWKFb4SxbFV4RwMs71IClSgO9Jd6vE/ 535 VfU+T+17ub6D6RoB0owbfT/APjlzyXx9+MsP670O/LyufzXmTibYRNvEPEHY0Goq2 536 NyDCsDRv5IWtwCfzSRwYiZQOn9wb2zlcDENFdTBzVhNDpJvYGnVNV1qlikSBNVNrl 537 LIFtM5CxFCLA4UhO03gCr+SnzW2EfdV3QR+XB785cLvF/bxawjv+cszn/Ccz8n8nM 538 hv8HwHfg/56/C3y0ARTltm8z3+eW8GkOECyoHGA/7iNiYU4pN7C6EmpxGzBzfhTdE 539 9hiB505ysRhhOeWjRDDWJgwXBk/ulDNzXZtjUmEOg+XxGmuy7AfDCfxJNvPGqut/5 540 jz/A9G2a5cs4kb/h8Am+s/ton5/6MI9KSazwbyv9YiUMn/SbRXBXgK/ymB0v8bAA3 541 /D4At9d9SABr+v2z+TwOpV7slPZGpDPUo1l1vHIQ7i1HLf7Y4/zVZef7DgDbnP4fA 542 x06v/fFD99sd/8y36isb+4eSsCoHOz0OEssHQgTQ3by8eCFYw//PQe7vVAFq+U8W+ 543 d+c7f8Z5Q3/D4Gq/vdE7pcE77uc3cody0Bdge/ZB8QlxQ1F8aKy99Lp3aBBgwYb8R 544 U5DHG1ACoAAA== 545 -- END MESSAGE ARCHIVE -- 547 Authors' Addresses 549 Vijay K. Gurbani (editor) 550 Bell Laboratories, Alcatel-Lucent 551 2701 Lucent Lane 552 Rm 9F-546 553 Lisle, IL 60532 554 USA 556 Phone: +1 630 224 0216 557 Email: vkg@alcatel-lucent.com 558 Chris Boulton 559 Ubiquity Software Corporation 560 Building 3 561 West Fawr Lane 562 St Mellons 563 Cardiff, South Wales CF3 5EA 565 Email: cboulton@ubiquitysoftware.com 567 Robert J. Sparks 568 Estacado Systems 570 Email: RjS@estacado.net 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2007). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 583 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 584 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Intellectual Property 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Acknowledgment 614 Funding for the RFC Editor function is provided by the IETF 615 Administrative Support Activity (IASA).