Network Working Group                                     R. Sparks, Ed.
Internet-Draft                                               dynamicsoft
Expires: July 21, 2004 January 12, 2005                                 A. Hawrylyshen
                                                         Jasomi Networks
                                                             A. Johnston
                                                                     MCI
                                                            J. Rosenberg
                                                             dynamicsoft
                                                          H. Schulzrinne
                                                     Columbia University
                                                        January 21,
                                                           July 14, 2004

           Session Initiation Protocol Torture Test Messages
                  draft-ietf-sipping-torture-tests-03
                  draft-ietf-sipping-torture-tests-04

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 21, 2004. January 12, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This informational document gives examples of Session Initiation
   Protocol (SIP) test messages designed to exercise and "torture" a
   parser. SIP
   implementation.

Table of Contents

   1.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Document Conventions . . . . . . . . . . . . . . . . . . . .   4
     2.1  Representing Long Lines  . . . . . . . . . . . . . . . . .   4
     2.2  Representing Non-printable Characters  . . . . . . . . . .   5
     2.3  Representing Long Repeating Strings  . . . . . . . . . . .   5
   3.   SIP Test Messages  . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Parser tests (syntax)  . . . . . . . . . . . . . . . . . .   6
       3.1.1  Valid messages . . . . . . . . . . . . . . . . . . . . .   6
         3.1.1.1  A short tortuous INVITE  . . . . . . . . . . . . . . . .   6
         3.1.1.2  Wide range of valid characters . . . . . . . . . . . . .   8
         3.1.1.3  Valid use of the % escaping mechanism  . . . . . . . . .   9
         3.1.1.4  Escaped nulls in URIs  . . . . . . . . . . . . . . . . .  10
         3.1.1.5  Use of % when it is not an escape  . . . . . . . . . . .  11
         3.1.1.6  Message with no LWS between display name and < . . . . .  12  11
         3.1.1.7  Long values in header fields . . . . . . . . . . . . . .  12
         3.1.1.8  Extra trailing octets in a UDP datagram  . . . . . . . .  14
         3.1.1.9  Semicolon separated parameters in URI user part  . . . .  15
         3.1.1.10   Varied and unknown transport types . . . . . . . . . . .  15  16
         3.1.1.11   S/MIME signed message  . . . . . . . . . . . . . . . . .  16
         3.1.1.12   Unusual reason phrase  . . . . . . . . . . . . . . . . .  19
         3.1.1.13   Empty reason phrase  . . . . . . . . . . . . . . . . . .  20
       3.1.2  Invalid messages . . . . . . . . . . . . . . . . . . . .  20  21
         3.1.2.1  Extraneous header field separators . . . . . . . . . . .  20  21
         3.1.2.2  Content length larger than message . . . . . . . . . . .  21
         3.1.2.3  Negative Content-Length  . . . . . . . . . . . . . . . .  22
         3.1.2.4  Request scalar fields with overlarge values  . . . . . .  22  23
         3.1.2.5  Response scalar fields with overlarge values . . . . . .  23  24
         3.1.2.6  Unterminated quoted string in display-name . . . . . . .  24
         3.1.2.7  <> enclosing Request-URI . . . . . . . . . . . . . . . .  25
         3.1.2.8  Malformed SIP Request-URI (embedded LWS) . . . . . . . .  25  26
         3.1.2.9  Multiple SP separating Request-Line elements . . . . . .  26  27
         3.1.2.10   SP characters at end of Request-Line . . . . . . . . . .  27  28
         3.1.2.11   Escaped headers in SIP Request-URI . . . . . . . . . . .  27  29
         3.1.2.12   Invalid timezone in Date header field  . . . . . . . . .  28  29
         3.1.2.13   Failure to enclose name-addr URI in <> . . . . . . . . .  29  30
         3.1.2.14   Spaces within addr-spec  . . . . . . . . . . . . . . . .  29  31
         3.1.2.15   Non-token characters in display-name . . . . . . . . . .  30  31
         3.1.2.16   Unknown protocol version . . . . . . . . . . . . . . . .  30  32
         3.1.2.17   Start line and CSeq method mismatch  . . . . . . . . . .  31  32
         3.1.2.18   Unknown Method with CSeq method mismatch . . . . . . . .  31  32
         3.1.2.19   Overlarge response code  . . . . . . . . . . . . . . . .  32  33
     3.2  Transaction layer semantics  . . . . . . . . . . . . . .  32 .  33
       3.2.1  Missing transaction identifier . . . . . . . . . . . . .  32  34
     3.3  Application layer semantics  . . . . . . . . . . . . . .  33 .  34
       3.3.1  Missing Required Header Fields . . . . . . . . . . . . .  33  34
       3.3.2  Request-URI with unknown scheme  . . . . . . . . . . . .  33  35
       3.3.3  Request-URI with known but atypical scheme . . . . . . .  34  35
       3.3.4  Unknown URI schemes in header fields . . . . . . . . . .  34  36
       3.3.5  Proxy-Require and Require  . . . . . . . . . . . . . . .  35  37
       3.3.6  Unknown Content-Type . . . . . . . . . . . . . . . . . .  35  37
       3.3.7  Unknown authorization scheme . . . . . . . . . . . . . .  36  38
       3.3.8  Multiple values in single value required fields  . . . .  37  38
       3.3.9  Multiple Content-Length values . . . . . . . . . . . . .  38  39
       3.3.10   200 OK Response with broadcast Via header field
                value  .  38
   3.3.11   Max-Forwards of zero . . . . . . . . . . . . . . . . . .  39
   3.3.12   REGISTER with a contact header parameter . . . . .  40
       3.3.11   Max-Forwards of zero . . .  39
   3.3.13   REGISTER with a url parameter . . . . . . . . . . . . .  40  41
       3.3.12   REGISTER with a contact header parameter . . . . . .  41
       3.3.13   REGISTER with a url parameter  . . . . . . . . . . .  42
       3.3.14   REGISTER with a url escaped header . . . . . . . . . . .  40  43
       3.3.15   Unacceptable Accept offering . . . . . . . . . . . . . .  41  43
     3.4  Backward compatibility . . . . . . . . . . . . . . . . .  42 .  44
       3.4.1  INVITE with RFC2543 syntax . . . . . . . . . . . . . . .  42  44
   4.   Security Considerations  . . . . . . . . . . . . . . . .  42 . .  45
   5.       Open Issues and Remaining Work   IANA Considerations  . . . . . . . . . . . . .  43 . . . . . . .  45
   6.   Acknowledgments  . . . . . . . . . . . . . . . . . . . .  43 . .  45
   7.   Informative References . . . . . . . . . . . . . . . . .  44 . .  46
        Authors' Addresses . . . . . . . . . . . . . . . . . . .  44 . .  46
   A.   Bit-exact archive of each test message . . . . . . . . .  45 . .  47
     A.1  Encoded Reference Messages . . . . . . . . . . . . . . .  46 .  48
        Intellectual Property and Copyright Statements . . . . .  50 . .  52

1.  Overview

   This document is informational, and is NOT NORMATIVE on any aspect of
   SIP.

   This document contains test messages based on the current version
   (2.0) of the Session Initiation Protocol as defined in [RFC3261].
   Some messages exercise SIP's use of SDP as described in [RFC3264].

   These messages were developed and refined at the SIPIt
   interoperability test events.

   The test messages are organized into several sections.  Some stress
   only a SIP parser and others stress both the parser and the
   application above it.  Some messages are valid, and some are not.
   Each example clearly calls out what makes any invalid messages
   incorrect.

   This document does not attempt to catalog every way to make an
   invalid message, nor does it attempt to be comprehensive in exploring
   unusual, but valid, messages.  Instead, it tries to focus on areas
   that have caused interoperability problems or have particularly
   unfavorable characteristics if they are handled improperly.  This
   document is a seed for a test plan, not a test plan in itself.

   The messages are presented in the text using a set of markup
   conventions to avoid ambiguity and meet Internet-Draft layout
   requirements.  To resolve any remaining ambiguity, a bit-accurate
   version of each message is encapsulated in an appendix.

2.  Document Conventions

   This document contains many example SIP messages.  Although SIP is a
   text-based protocol, many of these examples cannot be unambiguously
   rendered without additional markup due to the constraints placed on
   the formatting of RFCs.  This document defines and uses the markup
   defined in this section to remove that ambiguity.  This markup uses
   the start and end tag conventions of XML, but does not define any XML
   document type.

   The appendix contains an encoded binary form of all the messages and
   the algorithm needed to decode them into files.

2.1  Representing Long Lines

   Several of these examples contain unfolded lines longer than 72
   characters.  These are captured between <allOneLine/> tags.  The
   single unfolded line is reconstructed by directly concatenating all
   lines appearing between the tags (discarding any line-feeds or
   carriage returns).  There will be no whitespace at the end of lines.
   Any whitespace appearing at a fold-point will appear at the beginning
   of a line.

   The following represent the same string of bits:

      Header-name: first value, reallylongsecondvalue, third value

      <allOneLine>
      Header-name: first value,
       reallylongsecondvalue
      , third value
      </allOneLine>

      <allOneLine>
      Header-name: first value,
       reallylong
      second
      value,
       third value
      </allOneLine>

    Note that this is NOT SIP header line folding where different
   strings of bits have equivalent meaning.

2.2  Representing Non-printable Characters

   Several examples contain binary message bodies or header field values
   containing non-ascii range UTF-8 encoded characters.  These are
   rendered here as a pair of hexadecimal digits per octet between <hex/
   > tags.  This rendering applies even inside quoted-strings.

   The following represent the same string of bits:

     Header-name: value one

     Header-name: value<hex>206F6E</hex>e

   The following is a Subject header field containing the euro symbol:

      Subject: <hex>E282AC</hex>

2.3  Representing Long Repeating Strings

   Several examples contain very large data values created with
   repeating bit strings.  Those will be rendered here using <repeat
   count=some_integer>value</repeat>.  As with <hex> this rendering
   applies even inside quoted-strings.

   For example, the value "abcabcabc" can be rendered as <repeat
   count=3>abc</repeat>.  A display name of "1000000 bottles of beer"
   could be rendered as

     To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
         <sip:beer.example.com>

    and a Max-Forwards header field with a value of one google will be
   rendered here as

      Max-Forwards: 1<repeat count=100>0</repeat>

3.  SIP Test Messages

3.1  Parser tests (syntax)

3.1.1  Valid messages

3.1.1.1  A short tortuous INVITE

   This short, relatively human-readable message contains:
   o  line folding all over
   o  escaped characters within quotes
   o  an empty subject
   o  LWS between colons, semicolons, header field values, and other
      fields
   o  both comma separated and separate listing of header field values
   o  mix or short and long form for the same header field name
   o  unknown header fields
   o  unknown header field with a value that would be syntactically
      invalid if it were defined in terms of generic-param
   o  unusual header field ordering
   o  unusual header field name character case
   o  unknown parameters of a known header field
   o  uri parameter with no value
   o  header parameter with no value
   o  integer fields (Max-Forwards and CSeq) with leading zeros
   All elements should treat this as a well-formed request.

   The UnknownHeaderWithUnusualValue header field deserves special
   attention.  If this header field were defined in terms of comma
   separated values with semicolon separated parameters (as many of the
   existing defined header fields), this would be invalid.  However,
   since the receiving element does not know the definition of the
   syntax for this field, it must parse it as a header-value.  Proxies
   would forward this header field unchanged.  Endpoints would ignore
   the header field.

      Message Details : wsinv

      INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
      TO :
       sip:vivekg@chair-dnrc.example.com ;   tag    = 1918181833n
      from   : "J Rosenberg \\\""       <sip:jdrosen@example.com>
        ;
        tag = 98asjd8
      MaX-fOrWaRdS: 0068
      Call-ID: 0ha0isndaksdj@192.0.2.1 wsinv.ndaksdj@192.0.2.1
      Content-Length   : 151
      cseq: 0009
        INVITE
      Via  : SIP  /   2.0
       /UDP
          192.0.2.2;branch=390skdjuw
      s :
      NewFangledHeader:   newfangled value
       continued newfangled value
      UnknownHeaderWithUnusualValue: ;;,,;;,;
      Content-Type: application/sdp
      Route:
       <sip:services.example.com;lr;unknownwith=value;unknown-no-value>
      v:  SIP  / 2.0  / TCP     spindle.example.com   ;
        branch  =   z9hG4bK9ikj8  ,
       SIP  /    2.0   / UDP  192.168.255.111   ; branch=
       z9hG4bK30239
      m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
            newvalue ;
        secondparam ; q = 0.33

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.3
      s=-
      c=IN IP4 192.0.2.4
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.2  Wide range of valid characters

   This message exercises a wider range of characters in several key
   syntactic elements than implementations usually see.  Of particular
   note:
   o  The Method contains non-alpha characters from token.  Note that %
      is not an escape character for this field.  A method of IN%56ITE
      is an unknown method.  It is not the same as a method of INVITE
   o  The Request-URI contain unusual, but legal, characters
   o  A branch parameter contains all non-alphanum characters from token
   o  The To header field value's quoted-string contains quoted-pair
      expansions, including a quoted NULL character
   o  The name part of name-addr in the From header field value contains
      multiple tokens (instead of a quoted string) with all non-alphanum
      characters from the token production rule.  That value also has an
      unknown header parameter whose name contains the non-alphanum
      token characters and whose value is a non-ascii range UTF-8
      encoded string.  The tag parameter on this value contains the
      non-alphanum token characters
   o  The Call-ID header field value contains the non-alphanum
      characters from word.  Notice that in this production:
      *  % is not an escape character.  (It is only an escape character
         in productions matching the rule "escaped")
      *  " does not start a quoted-string.  None of ',` or " imply that
         there will be a matching symbol later in the string
      *  The characters []{}()<> do not have any grouping semantics.
         They are not required to appear in balanced pairs
   o  There is an unknown header field (matching extension-header) with
      non-alphanum token characters in its name and a UTF8-NONASCII
      value

   If this unusual URI has been defined at a proxy, the proxy will
   forward this request normally.  Otherwise a proxy will generate a
   404.  Endpoints will generate a 501 listing the methods they
   understand in an Allow header field.

      Message Details : intmeth

      <allOneLine>
      !interesting-Method0123456789_*+`.%indeed'~
       sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
      :&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
      @example.com SIP/2.0
      </allOneLine>
      Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
      <allOneLine>
      To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
       <sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
      @example.com>
      </allOneLine>
      <allOneLine>
      From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
      ;fromParam''~+*_!.-%=
      "<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
      ;tag=_token~1'+`*%!-.
      </allOneLine>
      Call-ID: word%ZK-!.*_+'@word`~)(><:\/"][?}{ intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
      CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
      Max-Forwards: 255
      <allOneLine>
      extensionHeader-!.%*+_`'~:
      <hex>EFBBBFE5A4A7E5819CE99BBB</hex>
      </allOneLine>
      Content-Length: 0

3.1.1.3  Valid use of the % escaping mechanism

   This INVITE exercises the % HEX HEX escaping mechanism in several
   places.  The request is syntactically valid.  Interesting features
   include:
   o  The request-URI has sips:user@example.com embedded in its
      userpart.  What that might mean to example.net is beyond the scope
      of this document.
   o  The From and To URIs have escaped characters in their userparts.
   o  The Contact URI has escaped characters in the URI parameters.
      Note that the "name" uri-parameter has a value of "value%41" which
      is NOT equivalent to "valueA".  Per [RFC2396], unescaping URI
      components is never performed recursively.

   A parser must accept this as a well-formed message.  The application
   using the message must treat the % HEX HEX expansions as equivalent
   to the character being encoded.  The application must not try to
   interpret % as an escape character in those places where % HEX HEX
   ("escaped" in the grammar) is not a valid part of the construction.
   In [RFC3261], "escaped" only occurs in the expansions of SIP-URI,
   SIPS-URI, and Reason-Phrase

      Message Details : esc01

      INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
      To: sip:%75se%72@example.com
      From: <sip:I%20have%20spaces@example.net>;tag=938
      Max-Forwards: 87
      i: 239409asdfakjkn23onasd0-3234 esc01.239409asdfakjkn23onasd0-3234
      CSeq: 234234 INVITE
      Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
      C: application/sdp
      Contact:
        <sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.4  Escaped nulls in URIs

   This register request contains several URIs with nulls in the
   userpart.  The message is well formed - parsers must accept this
   message.  Implementations must take special care when unescaping the
   AOR in this request to not prematurely shorten the username.  This
   request registers two distinct contact URIs.

      Message Details : escnull

      REGISTER sip:example.com SIP/2.0
      To: sip:null-%00-null@example.com
      From: sip:null-%00-null@example.com;tag=839923423
      Max-Forwards: 70
      Call-ID: 39203ndfvkjdasfkq3w4otrq0adsfdfnavd escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
      CSeq: 14398234 REGISTER
      Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
      Contact: <sip:%00@host5.example.com>
      Contact: <sip:%00%00@host5.example.com>
      L:0

3.1.1.5  Use of % when it is not an escape

   Most of the places % can appear in a SIP message, it is not an escape
   character.  This can surprise the unwary implementor.  The following
   well-formed request has these properties:
   o  The request method is unknown.  It is NOT equivalent to REGISTER
   o  The display-name portion of the To and From header fields is
      "%Z%45".  Note that this is not the same as %ZE
   o  This message has two Contact header field values, not three.
      %lt;sip:alias2@host2.example.com%gt; is a C%6Fntact header field
      value

   A parser should accept this message as well formed.  A proxy would
   forward or reject the message depending on what the Request-URI meant
   to it.  An endpoint would reject this message with a 501.

      Message Details : esc02

      RE%47IST%45R sip:registrar.example.com SIP/2.0
      To: "%Z%45" <sip:resource@example.com>
      From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
      Call-ID: asdfnqwo34rq23i34jrjasdcnl23nrlknsdf esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
      Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
      CSeq: 29344 RE%47IST%45R
      Max-Forwards: 70
      Contact: <sip:alias1@host1.example.com>
      C%6Fntact: <sip:alias2@host2.example.com>
      Contact: <sip:alias3@host3.example.com>
      l: 0

3.1.1.6  Message with no LWS between display name and <

   This OPTIONS request is not valid per the grammar in RFC 3261.  since
   there is no LWS between the quoted string in the display name and <
   in the From header field value.  This has been identified as a
   specification bug that will be removed when RFC 3261 is revised.
   Elements should accept this request as well formed.

      Message Details : lwsdisp

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: "caller"<sip:caller@example.com>;tag=323
      Max-Forwards: 70
      Call-ID: 1234abcd@funky.example.com lwsdisp.1234abcd@funky.example.com
      CSeq: 60 OPTIONS
      Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
      l: 0

3.1.1.7  Long values in header fields

   This well-formed request contains header fields with many values and
   values that are very long.  Features include:
   o  The To header field has a long display name, and long uri
      parameter names and values
   o  The From header field has long header parameter names and values,
      in particular a very long tag
   o  The Call-ID is one long token

      Message Details : longreq

      INVITE sip:user@example.com SIP/2.0
      <allOneLine>
      To: "I have a user name of
       <repeat count=10>extreme</repeat> proportion"
      <sip:user@example.com:6000;
      unknownparam1=very<repeat count=20>long</repeat>value;
      longparam<repeat count=25>name</repeat>=shortvalue;
      very<repeat count=25>long</repeat>ParameterNameWithNoValue>
      </allOneLine>
      <allOneLine>
      F: sip:
      <repeat count=5>amazinglylongcallername</repeat>@example.net
      ;tag=12<repeat count=50>982</repeat>424
      ;unknownheaderparam<repeat count=20>name</repeat>=
      unknowheaderparam<repeat count=15>value</repeat>
      ;unknownValueless<repeat count=10>paramname</repeat>
      </allOneLine>
      Call-ID: one<repeat longreq.one<repeat count=20>really</repeat>longcallid
      CSeq: 3882340 INVITE
      <allOneLine>
      Unknown-<repeat count=20>Long</repeat>-Name:
       unknown-<repeat count=20>long</repeat>-value;
       unknown-<repeat count=20>long</repeat>-parameter-name =
       unknown-<repeat count=20>long</repeat>-parameter-value
      </allOneLine>
      Via: SIP/2.0/TCP sip33.example.com
      v: SIP/2.0/TCP sip32.example.com
      V: SIP/2.0/TCP sip31.example.com
      Via: SIP/2.0/TCP sip30.example.com
      ViA: SIP/2.0/TCP sip29.example.com
      VIa: SIP/2.0/TCP sip28.example.com
      VIA: SIP/2.0/TCP sip27.example.com
      via: SIP/2.0/TCP sip26.example.com
      viA: SIP/2.0/TCP sip25.example.com
      vIa: SIP/2.0/TCP sip24.example.com
      vIA: SIP/2.0/TCP sip23.example.com
      V :  SIP/2.0/TCP sip22.example.com
      v :  SIP/2.0/TCP sip21.example.com
      V  : SIP/2.0/TCP sip20.example.com
      v  : SIP/2.0/TCP sip19.example.com
      Via : SIP/2.0/TCP sip18.example.com
      Via  : SIP/2.0/TCP sip17.example.com
      Via: SIP/2.0/TCP sip16.example.com
      Via: SIP/2.0/TCP sip15.example.com
      Via: SIP/2.0/TCP sip14.example.com
      Via: SIP/2.0/TCP sip13.example.com
      Via: SIP/2.0/TCP sip12.example.com
      Via: SIP/2.0/TCP sip11.example.com
      Via: SIP/2.0/TCP sip10.example.com
      Via: SIP/2.0/TCP sip9.example.com
      Via: SIP/2.0/TCP sip8.example.com
      Via: SIP/2.0/TCP sip7.example.com
      Via: SIP/2.0/TCP sip6.example.com
      Via: SIP/2.0/TCP sip5.example.com
      Via: SIP/2.0/TCP sip4.example.com
      Via: SIP/2.0/TCP sip3.example.com
      Via: SIP/2.0/TCP sip2.example.com
      Via: SIP/2.0/TCP sip1.example.com
      <allOneLine>
      Via: SIP/2.0/TCP
       host.example.com;received=192.0.2.5;
      branch=very<repeat count=50>long</repeat>branchvalue
      </allOneLine>
      Max-Forwards: 70
      <allOneLine>
      Contact: <sip:
      <repeat count=5>amazinglylongcallername</repeat>
      @host5.example.net>
      </allOneLine>
      Content-Type: application/sdp
      l: 151
      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.8  Extra trailing octets in a UDP datagram

   This message contains a single SIP REGISTER request, which ostensibly
   arrived over UDP in a single datagram.  The packet contained extra
   octets after the body (which in this case has zero length).  Those
   octets happen to look like a SIP INVITE request, but (per section
   18.3 of [RFC3261]) they are just spurious noise that must be ignored.

   A SIP element receiving this datagram would handle the REGISTER
   request normally and ignore the extra bits that look like an INVITE
   request.  If the element is a proxy choosing to forward the REGISTER,
   the INVITE octets would not appear in the forwarded request.

      Message Details : dblreq

      REGISTER sip:example.com SIP/2.0
      To: sip:j.user@example.com
      From: sip:j.user@example.com;tag=43251j3j324
      Max-Forwards: 8
      I: 0ha0isndaksdj99sdfafnl3lk233412 dblreq.0ha0isndaksdj99sdfafnl3lk233412
      Contact: sip:j.user@host.example.com
      CSeq: 8 REGISTER
      Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
      Content-Length: 0

      INVITE sip:joe@example.com SIP/2.0
      t: sip:joe@example.com
      From: sip:caller@example.net;tag=141334
      Max-Forwards: 8
      Call-ID: 0ha0isnda977644900765@192.0.2.15 dblreq.0ha0isnda977644900765@192.0.2.15
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
      Content-Type: application/sdp
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.15
      s=-
      c=IN IP4 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m =video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.9  Semicolon separated parameters in URI user part

   This request has a semicolon-separated parameter contained in the
   "user" part of the Request-URI (whose value contains an escaped @
   symbol).  Receiving elements will accept this as a well formed
   message.  The Request-URI will parse such that the user part is
   "user;par=u@example.net".

      Message Details : semiuri

      OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
      To: sip:j_user@example.com
      From: sip:caller@example.org;tag=33242
      Max-Forwards: 3
      Call-ID: 0ha0isndaksdj semiuri.0ha0isndaksdj
      CSeq: 8 OPTIONS
      Accept: application/sdp, application/pkcs7-mime,
              multipart/mixed, multipart/signed,
              message/sip, message/sipfrag
      Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
      l: 0

3.1.1.10  Varied and unknown transport types

   This request contains Via header field values with all known
   transport types and exercises the transport extension mechanism.
   Parsers must accept this message as well formed.  Elements receiving
   this message would process it exactly as if the 2nd and subsequent
   header field values specified UDP (or other transport).

      Message Details : transports

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: <sip:caller@example.com>;tag=323
      Max-Forwards: 70
      Call-ID:  nfc9ehfdfaekijh4akdnaqjkwendsasfdj  transports.kijh4akdnaqjkwendsasfdj
      Accept: application/sdp
      CSeq: 60 OPTIONS
      Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
      Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
      Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
      Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
      Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
      l: 0

3.1.1.11  S/MIME signed message

   This is a signed INVITE request.  The signature is binary encoded.
   The body contains null (0x00) characters.  Receivers must take care
   to properly frame the received message.

   Parsers must accept this message as well formed, even if the
   application above the parser does not support multipart/signed.

      Message Details : smime01

      INVITE sip:receiver@example.com SIP/2.0
      Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3
      To: <sip:receiver@example.com>
      From: <sip:sender@example.org>;tag=2390234seiu3
      Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe smime01.uoqeiuavnklafekjq34iu43uawe
      CSeq: 282398492 INVITE
      Max-Forwards: 70
      Contact: <sip:sender@host5.example.org>
      Content-Length: 3134
      Content-Type: multipart/signed;
                    protocol="application/pkcs-7-signature";
                    micalg=sha1;
                    boundary="----34CF59C076641DD0879594444157C7EB"
      ------34CF59C076641DD0879594444157C7EB
                    boundary="----EABF38A0AAE8704C560F10418BA807CF"

      ------EABF38A0AAE8704C560F10418BA807CF
      Content-Type: message/sip

      INVITE sip:receiver@example.com SIP/2.0
      Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3
      To: <sip:receiver@example.com>
      From: <sip:sender@example.org>;tag=2390234seiu3
      Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe smime01.uoqeiuavnklafekjq34iu43uawe
      CSeq: 282398492 INVITE
      Max-Forwards: 70
      Contact: <sip:sender@host5.example.org>
      Accept: application/sdp, application/pkcs7-mime,
              multipart/mixed, multipart/signed,
              message/sip, message/sipfrag
      Content-Type: application/sdp
      Content-Length: 149

      v=0
      o=sender 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

      ------34CF59C076641DD0879594444157C7EB

      ------EABF38A0AAE8704C560F10418BA807CF
      Content-Type: application/pkcs-7-signature; name="smime.p7s"
      Content-Transfer-Encoding: binary
      Content-Disposition: attachment; filename="smime.p7s"

      <hex>3082088806092A86
      4886F70D010702A082087930820875020101310B300906052B0E03021A050030
      0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
      90008902240001300D06092A864886F70D01010505003070310B300906035504
      0613025553311330110603550408130A43616C69666F726E69613111300F0603
      550407130853616E4A6F7365310E300C060355040A1305736970697431293027
      060355040B135369706974546573744365727469666963617465417574686F72
      697479301E170D3033313032313134343332355A170D31333130313831343433
      32355A3062310B3009060355040613025553311330110603550408130A43616C
      69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
      040A13057369706974311B30190603550403141273656E646572406578616D70
      6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
      818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
      56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
      6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
      D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
      4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
      406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
      041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
      9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
      310B3009060355040613025553311330110603550408130A43616C69666F726E
      69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
      6970697431293027060355040B13536970697454657374436572746966696361
      7465417574686F72697479820100300D06092A864886F70D0101050500038181
      006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
      2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
      102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
      278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
      5E30820339308202A2A00302010202080090008902240001300D06092A864886
      F70D01010505003070310B300906035504061302555331133011060355040813
      0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
      0C060355040A1305736970697431293027060355040B13536970697454657374
      4365727469666963617465417574686F72697479301E170D3033313032313134
      343332355A170D3133313031383134343332355A3062310B3009060355040613
      025553311330110603550408130A43616C69666F726E69613111300F06035504
      07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
      550403141273656E646572406578616D706C652E6F726730819F300D06092A86
      4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
      2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
      76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
      FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
      79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
      0603551D1104163014811273656E646572406578616D706C652E6F7267300906
      03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
      E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
      546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
      30110603550408130A43616C69666F726E69613111300F060355040713085361
      6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
      69706974546573744365727469666963617465417574686F7269747982010030
      0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
      7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
      C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
      C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
      242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
      70310B3009060355040613025553311330110603550408130A43616C69666F72
      6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
      736970697431293027060355040B135369706974546573744365727469666963
      617465417574686F7269747902080090008902240001300906052B0E03021A05
      00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
      06092A864886F70D010905310F170D3033313032323135323930325A30230609
      2A864886F70D010904311604144A2FD5856B6006413209FA56A0C1D85179DBCB
      5F305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
      06092A864886F70D010905310F170D3034303731343230333630375A30230609
      2A864886F70D010904311604142830DBEDC758BAA9750138384431E8F1819717
      C8305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
      06082A864886F70D030202020080300D06082A864886F70D0302020140300706
      052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
      01010500048180C1C3193CF4A8BE1278B5529ACFA1C51DDEDECF0D3DC4C18FC5
      9A5B120E6D559F4953A3C3C7C97B4EAD8388F1508F7AD2FC71CC7B9ED2844789
      60A3ECF87984E25A15B4AB63F150C30570B6315A2327E381EE11E866DC1405DA
      29E74CC20201816F1516DD893332D9A8E26FBAEC237C494F3EFAEF4EBCD2122C
      DE7D57DECD</hex>------34CF59C076641DD0879594444157C7EB--
      0101050004818060FF00161CFAC1E641D0C993FACD949DC239F9DDF527F834A6
      ECF837B5D2C7B756F30A2755F5EF7A833351721F30A4392921E0A73594AA0BF2
      4E6BD3981362DEA4F22844CB505ED3C6C0CCADD524066593ABED4023243055CA
      0CE0AE83F13868E29E91E3AA588BDC11B2A18F39001885E17879503523699A87
      982C6D48D4918A</hex>------EABF38A0AAE8704C560F10418BA807CF--

3.1.1.12  Unusual reason phrase

   This 200 response contains a reason phrase other than "OK".  The
   reason phrase is intended for human consumption, and may contain any
   string produced by

       Reason-Phrase   =  *(reserved / unreserved / escaped
                          / UTF8-NONASCII / UTF8-CONT / SP / HTAB)

   This particular response contains unreserved and non-ASCII UTF-8
   characters.This response is well formed.  A parser must accept this
   message.

      Message Details : unreason

      <allOneLine>
      SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
      D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
      D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
      BED0B5</hex>
      </allOneLine>
      Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
      Call-ID: 0384840201234ksdfak3j2erwedfsASdf unreason.1234ksdfak3j2erwedfsASdf
      CSeq: 35 INVITE
      From: sip:user@example.com;tag=11141343
      To: sip:user@example.edu;tag=2229
      Content-Length: 159
      Content-Type: application/sdp
      Contact: <sip:user@host198.example.com>

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.198
      s=-
      c=IN IP4 192.0.2.198/127
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.1.13  Empty reason phrase

   This well formed response contains no reason phrase.  A parser must
   accept this message.  The space character after the reason code is
   required.  If it were not present, this message could be rejected as
   invalid (a liberal receiver would accept it anyway).

      Message Details : noreason

      SIP/2.0 100<hex>20</hex>
      Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
      Call-ID: adsn2309jasndj203insdf99223ndf noreason.asndj203insdf99223ndf
      CSeq: 35 INVITE
      From: <sip:user@example.com>;tag=39ansfi3
      To: <sip:user@example.edu>;tag=902jndnke3
      Content-Length: 0
      Contact: <sip:user@host105.example.com>

3.1.2  Invalid messages

   This section contains several invalid messages reflecting errors seen
   at interoperability events and exploring important edge conditions
   that can be induced through malformed messages.  This section does
   not attempt to be a comprehensive list of all types of invalid
   messages.

3.1.2.1  Extraneous header field separators

   The Via and header field of this request contains contain additional
   semicolons and commas without parameters or values.  The Contact
   header field contains additional semicolons without parameters.  This
   message is syntactically invalid.

   An element receiving this request should respond with a 400 Bad
   Request error.

      Message Details : badinv01

      INVITE sip:user@example.com SIP/2.0
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=134161461246
      Max-Forwards: 7
      Call-ID: 0ha0isndaksdjasdf3234nas badinv01.0ha0isndaksdjasdf3234nas
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 192.0.2.15;;,;,,
      Contact: "Joe" <sip:joe@example.org>;;;;
      Content-Length: 153
      Content-Type: application/sdp

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.15
      s=-
      c=IN IP4 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.2  Content length larger than message

   This is a request message with a Content Length that is larger than
   the length of the body.

   When sent UDP (as this message ostensibly was), the receiving element
   should respond with a 400 Bad Request error.  If this message were
   received over a stream-based transport such as TCP, there's not much
   you can do but wait for more data on the stream and close the
   connection if none is forthcoming in a reasonable period of time.

      Message Details : clerr

      INVITE sip:user@example.com SIP/2.0
      Max-Forwards: 80
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=93942939o2
      Contact: <sip:caller@hungry.example.net>
      Call-ID: 0ha0isndaksdjweiafasdk3 clerr.0ha0isndaksdjweiafasdk3
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
      Content-Type: application/sdp
      Content-Length: 9999

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.155
      s=-
      c=IN IP4 192.0.2.155
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.3  Negative Content-Length

   This request has a negative value for Content-Length.

   An element receiving this message should respond with an error.  This
   request appeared over UDP, so the remainder of the datagram can
   simply be discarded.  If a request like this arrives over TCP, the
   framing error is not recoverable and the connection should be closed.
   The same behavior is appropriate for messages that arrive without a
   numeric value in the Content-Length header field such as:

       Content-Length: five

   Implementors should take extra precautions if the technique they
   choose for converting this ascii field into an integral form can
   return a negative value.  In particular, the result must not be used
   as a counter or array index.

      Message Details : ncl

      INVITE sip:user@example.com SIP/2.0
      Max-Forwards: 254
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=32394234
      Call-ID: 0ha0isndaksdj2193423r542w35 ncl.0ha0isndaksdj2193423r542w35
      CSeq: 0 INVITE
      Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
      Contact: <sip:caller@example53.example.net>
      Content-Type: application/sdp
      Content-Length: -999

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.53
      s=-
      c=IN IP4 192.0.2.53
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.4  Request scalar fields with overlarge values

   This request contains several scalar header field values outside
   their legal range.
   o  the CSeq sequence number is >2**32-1.
   o  the Max-Forwards value is >255.
   o  the Expires value is >2**32-1.
   o  the Contact expires parameter value is >2**32-1.

   An element receiving this request should respond with a 400 Bad
   Request due to the CSeq error.  If only the Max-Forwards field were
   in error, the element could choose process the request as if the
   field were absent.  If only the expiry values were in error, the
   element could treat them as if they contained the default values for
   expiration (3600 in this case).

   Other scalar request fields that may contain aberrant values include,
   but are not limited to,  the Contact q value, the Timestamp value,
   and the Via ttl parameter.

      Message Details : scalar02

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
      To: <sip:user@example.com>
      From: <sip:user@example.com>;tag=239232jh3
      CSeq: 36893488147419103232 REGISTER
      Call-ID: asdnw3qjr23o0pd9vanlq3wnrlnewofjas9ui32 scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
      Max-Forwards: 300
      Expires: 1<repeat count=100>0</repeat>
      Contact: <sip:user@host129.example.com>
        ;expires=280297596632815
      Content-Length: 0

3.1.2.5  Response scalar fields with overlarge values

   This response contains several scalar header field values outside
   their legal range.
   o  the CSeq sequence number is >2**32-1.
   o  The Retry-After field is unreasonably large (note that RFC 3261
      does not define a legal range for this field).
   o  The Warning field has a warning-value with more than 3 digits

   An element receiving this response will simply discard it.

      Message Details : scalarlg

      SIP/2.0 503 Service Unavailable
      Via: SIP/2.0/TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw
      To: <sip:user@example.com>
      From: <sip:other@example.net>;tag=2easdjfejw
      CSeq: 9292394834772304023312 OPTIONS
      Call-ID: nvoao34irnoase0of0234hn2qofoaf0232aewf2394r scalarlg.noase0of0234hn2qofoaf0232aewf2394r
      Retry-After: 949302838503028349304023988
      Warning: 1812 overture "In Progress"
      Content-Length: 0

3.1.2.6  Unterminated quoted string in display-name

   This is a request with an unterminated quote in the display name of
   the To field.  An element receiving this request should return an 400
   Bad Request error.

   An element could attempt to infer a terminating quote and accept the
   message.  Such an element needs to take care that it makes a
   reasonable inference when it encounters

      To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>

      Message Details : quotbal

      INVITE sip:user@example.com SIP/2.0
      To: "Mr. J. User <sip:j.user@example.com>
      From: sip:caller@example.net;tag=93334
      Max-Forwards: 10
      Call-ID: 0ha0isndaksdj quotbal.aksdj
      Contact: <sip:caller@host59.example.net>
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
      Content-Type: application/sdp
      Content-Length: 153

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.15
      s=-
      c=IN IP4 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.7  <> enclosing Request-URI

   This INVITE request is invalid because the Request-URI has been
   enclosed within in "<>".

   It is reasonable to always reject a request with this error with a
   400 Bad Request.  Elements attempting to be liberal with what they
   accept may choose to ignore the brackets.  If the element forwards
   the request, it must not include the brackets in the messages it
   sends.

      Message Details : ltgtruri

      INVITE <sip:user@example.com> SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=39291
      Max-Forwards: 23
      Call-ID: 1@192.0.2.5 ltgtruri.1@192.0.2.5
      CSeq: 1 INVITE
      Via: SIP/2.0/UDP 192.0.2.5
      Contact: <sip:caller@host5.example.net>
      Content-Type: application/sdp
      Content-Length: 160

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.5
      s=-
      c=IN IP4 192.0.2.5
      t=3149328700 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.8  Malformed SIP Request-URI (embedded LWS)

   This INVITE has illegal LWS within the Request-URI.

   An element receiving this request should respond with a 400 Bad
   Request.

   An element could attempt to ignore the embedded LWS for those schemes
   (like sip) where that would not introduce ambiguity.

      Message Details : lwsruri

      INVITE sip:user@example.com; lr SIP/2.0
      To: sip:user@example.com;tag=3xfe-9921883-z9f
      From: sip:caller@example.net;tag=231413434
      Max-Forwards: 5
      Call-ID: asdfasdoijweoi2323-asdfwern23-asd8ia0swn34rk423 lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423
      CSeq: 2130706432 INVITE
      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
      Contact: <sip:caller@host1.example.net>
      Content-Type: application/sdp
      Content-Length: 160

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=3149328700 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.9  Multiple SP separating Request-Line elements

   This INVITE has illegal multiple SP characters between elements of
   the start line.

   It is acceptable to reject this request as malformed.  An element
   that is liberal in what it accepts may ignore these extra SP
   characters while processing the request.  If the element forwards the
   request, it must not include these extra SP characters in the
   messages it sends.

      Message Details : lwsstart

      INVITE  sip:user@example.com  SIP/2.0
      Max-Forwards: 8
      To: sip:user@example.com
      From: sip:caller@example.net;tag=8814
      Call-ID: 2304u0qwsdfknq234oi243099adsdfnawe3@example.com lwsstart.dfknq234oi243099adsdfnawe3@example.com
      CSeq: 1893884 INVITE
      Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
      Contact: <sip:caller@host1.example.net>
      Content-Type: application/sdp
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.10  SP characters at end of Request-Line

   This OPTIONS request contains SP characters between the SIP-Version
   field and the CRLF terminating the Request-Line.

   It is acceptable to reject this request as malformed.  An element
   that is liberal in what it accepts may ignore these extra SP
   characters while processing the request.  If the element forwards the
   request, it must not include these extra SP characters in the
   messages it sends.

      Message Details : trws

      OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
      Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093
      To: <sip:remote-target@example.com>
      From: <sip:local-resource@example.com>;tag=329429089
      Call-ID: afewroicu34958239neffasdhr2345r trws.oicu34958239neffasdhr2345r
      Accept: application/sdp
      CSeq: 238923 OPTIONS
      Max-Forwards: 70
      Content-Length: 0

3.1.2.11  Escaped headers in SIP Request-URI

   This INVITE is malformed as the SIP Request-URI contains escaped
   headers.

   It is acceptable for an element to reject this request with a 400 Bad
   Request.  An element could choose to be liberal in what it accepts
   and ignore the escaped headers.  If the element is a proxy, the
   escaped headers must not appear in the Request-URI of forwarded
   request (and most certainly must not be translated into the actual
   header of the forwarded request).

      Message Details : escruri

      INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=341518
      Max-Forwards: 7
      Contact: <sip:caller@host39923.example.net>
      Call-ID: 23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
      CSeq: 149209342 INVITE
      Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
      Content-Type: application/sdp
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.12  Invalid timezone in Date header field

   This INVITE is invalid as it contains a non GMT time zone in the SIP
   Date header field.

   It is acceptable to reject this request as malformed (though an
   element shouldn't do that unless the contents of the Date header
   field were actually important to its processing).  An element wishing
   to be liberal in what it accepts could ignore this value altogether
   if it wasn't going to use the Date header field anyhow.  Otherwise,
   it could attempt to interpret this date and adjust it to GMT.

   RFC 3261 explicitly defines the only acceptable timezone designation
   as "GMT".  "UT", while synonymous with GMT per [RFC2822], is not
   valid.  "UTC" and "UCT" are also invalid.

      Message Details : baddate

      INVITE sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=2234923
      Max-Forwards: 70
      Call-ID: 239423mnsadf3j23lj42--sedfnm234 baddate.239423mnsadf3j23lj42--sedfnm234
      CSeq: 1392934 INVITE
      Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
      Date: Fri, 01 Jan 2010 16:00:00 EST
      Contact: <sip:caller@host5.example.net>
      Content-Type: application/sdp
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.5
      s=-
      c=IN IP4 192.0.2.5
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.13  Failure to enclose name-addr URI in <>

   This REGISTER request is malformed.  The SIP URI contained in the
   Contact Header field has an escaped header, so the field must be in
   name-addr form (which implies the URI must be enclosed in <>).

   It is reasonable for an element receiving this request to respond
   with a 400 Bad Request.  An element choosing to be liberal in what it
   accepts could infer the angle brackets since there is no ambiguity in
   this example.  In general, that won't be possible.

      Message Details : regbadct

      REGISTER sip:example.com SIP/2.0
      To: sip:user@example.com
      From: sip:user@example.com;tag=998332
      Max-Forwards: 70
      Call-ID: k345asrl3fdbv@10.0.0.1 regbadct.k345asrl3fdbv@10.0.0.1
      CSeq: 1 REGISTER
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
      Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
      l: 0

3.1.2.14  Spaces within addr-spec

   This request is malformed since the addr-spec in the To header field
   contains spaces.  Parsers receiving this request must not break.  It
   is reasonable to reject this request with a 400 Bad Request response.
   Elements attempting to be liberal may ignore the spaces.

      Message Details : badaspec

      OPTIONS sip:user@example.org SIP/2.0
      Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
      Max-Forwards: 70
      From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
      To: "Watson, Thomas" < sip:t.watson@example.org >
      Call-ID: sdf0234n2nds0a099u23h3hnnw009cdkne3 badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3
      Accept: application/sdp
      CSeq: 3923239 OPTIONS
      l: 0

3.1.2.15  Non-token characters in display-name

   This OPTIONS request is malformed since  the display names in the To
   and From header fields contain non-token characters but are unquoted.

   It is reasonable to always reject this kind of error with a 400 Bad
   Request response.

   An element may attempt to be liberal in what it receives and infer
   the missing quotes.  If this element were a proxy, it must not
   propagate the error into the request it forwards.  As a consequence,
   if the fields are covered by a signature, there's not much point in
   trying to be liberal - the message should be simply rejected.

      Message Details : baddn

      OPTIONS sip:t.watson@example.org SIP/2.0
      Via:     SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards:      70
      From:    Bell, Alexander <sip:a.g.bell@example.com>;tag=43
      To:      Watson, Thomas <sip:t.watson@example.org>
      Call-ID: 31415@c.example.com baddn.31415@c.example.com
      Accept: application/sdp
      CSeq:    3923239 OPTIONS
      l: 0

3.1.2.16  Unknown protocol version

   To an element implementing [RFC3261], this request is malformed due
   to its high version number.

   The element should respond to the request with a 505 Version Not
   Supported error.

      Message Details : badvers

      OPTIONS sip:t.watson@example.org SIP/7.0
      Via:     SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
      Max-Forwards:     70
      From:    A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
      To:      T. Watson <sip:t.watson@example.org>
      Call-ID: 31417@c.example.com badvers.31417@c.example.com
      CSeq:    1 OPTIONS
      l: 0

3.1.2.17  Start line and CSeq method mismatch

   This request has mismatching values for the method in the start line
   and the CSeq header field.  Any element receiving this request will
   respond with a 400 Bad Request.

      Message Details : mismatch01

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=34525
      Max-Forwards: 6
      Call-ID: 0ha0isndaksdj0234sxdfl3 mismatch01.dj0234sxdfl3
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
      l: 0

3.1.2.18  Unknown Method with CSeq method mismatch

   This message has an unknown method, and a CSeq method tag which does
   not match it.

   Any element receiving this response will should respond with a 501
   Not Implemented.  A 400 Bad Request is also acceptable, but choosing
   a 501 (particularly at proxies) has better future-proof
   characteristics.

      Message Details : mismatch02

      NEWMETHOD sip:user@example.com SIP/2.0
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=34525
      Max-Forwards: 6
      Call-ID: 0ha0isndaksdj0234sxdfl3 mismatch02.dj0234sxdfl3
      CSeq: 8 INVITE
      Contact: <sip:caller@host.example.net>
      Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
      Content-Type: application/sdp
      l: 139

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.1
      c=IN IP4 192.0.2.1
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.1.2.19  Overlarge response code

   This response has a response code larger than 699.  An element
   receiving this response should simply drop it.

      Message Details : bigcode

      SIP/2.0 4294967301 better not break the receiver
      Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
      Call-ID: asdof3uj203asdnf3429uasdhfas3ehjasdfas9i bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
      CSeq: 353494 INVITE
      From: <sip:user@example.com>;tag=39ansfi3
      To: <sip:user@example.edu>;tag=902jndnke3
      Content-Length: 0
      Contact: <sip:user@host105.example.com>

3.2  Transaction layer semantics

   This section contains tests that exercise an implementation's parser
   and transaction layer logic.

3.2.1  Missing transaction identifier

   This request indicates support for RFC 3261-style transaction
   identifiers by providing the z9hG4bK prefix to the branch parameter,
   but it provides no identifier.  A parser must not break when
   receiving this message.  An element receiving this request could
   reject the request with a 400 Response (preferably statelessly, as
   other requests from the source are likely to also have a malformed
   branch parameter), or it could fall back to the RFC 2543 style
   transaction identifier.

      Message Details : badbranch

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.org;tag=33242
      Max-Forwards: 3
      Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
      Accept: application/sdp
      Call-ID: sadonfo23i420jv0as0derf3j3n badbranch.sadonfo23i420jv0as0derf3j3n
      CSeq: 8 OPTIONS
      l: 0

3.3  Application layer semantics

   This section contains tests that exercise an implementation's parser
   and application layer logic.

3.3.1  Missing Required Header Fields

   This request contains no Call-ID, From, or To header fields.

   An element receiving this message must not break because of the
   missing information.  Ideally, it will respond with a 400 Bad Request
   error.

      Message Details : insuf

      INVITE sip:user@example.com SIP/2.0
      CSeq: 193942 INVITE
      Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdjuw 192.0.2.95;branch=z9hG4bKkdj.insuf
      Content-Type: application/sdp
      l: 153

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.95
      s=-
      c=IN IP4 192.0.2.95
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.3.2  Request-URI with unknown scheme

   This OPTIONS contains an unknown URI scheme in the Request-URI.  A
   parser must accept this as a well-formed SIP request.

   An element receiving this request will reject it with a 416
   Unsupported URI Scheme response.

   Some early implementations attempt to look at the contents of the To
   header field to determine how to route this kind of request.  That is
   an error.  Despite the fact that the To header field and the Request
   URI frequently look alike in simplistic first-hop messages, the To
   header field contains no routing information.

      Message Details : unkscm

      OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=384
      Max-Forwards: 3
      Call-ID: 2340923nasdfasser0q239nwsdfasdkl34 unkscm.nasdfasser0q239nwsdfasdkl34
      CSeq: 3923423 OPTIONS
      Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
      Content-Length: 0

3.3.3  Request-URI with known but atypical scheme

   This OPTIONS contains an Request-URI with an IANA registered scheme
   that does not commonly appear Request-URIs of SIP requests.  A parser
   must accept this as a well-formed SIP request.

   If an element will never accept this scheme as meaningful in a
   request-URI, it is appropriate to treat it as unknown and return a
   416 Unsupported URI Scheme response.  If the element might accept
   some URIs with this scheme, then a 404 Not Found is appropriate for
   those URIs it doesn't accept.

      Message Details : novelsc

      OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=384
      Max-Forwards: 3
      Call-ID: 2340923nasdfasser0q239nwsdfasdkl34 novelsc.asdfasser0q239nwsdfasdkl34
      CSeq: 3923423 OPTIONS
      Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
      Content-Length: 0

3.3.4  Unknown URI schemes in header fields

   This message contains registered schemes in the To, From and Contact
   header fields of a request.  The message is syntactically valid.
   Parsers must not fail when receiving this message.

   Proxies should treat this message as they would any other request for
   this URI.  A registrar would reject this request with a 400 Bad
   Request response since the To: header field is required to contain a
   SIP or SIPS URI as an AOR.

      Message Details : unksm2

      REGISTER sip:example.com SIP/2.0
      To: isbn:2983792873
      From: <http://www.example.com>;tag=3234233
      Call-ID: 0ha0isndaksdj@hyphenated-host.example.com unksm2.daksdj@hyphenated-host.example.com
      CSeq: 234902 REGISTER
      Max-Forwards: 70
      Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
      Contact: <name:John_Smith>
      l: 0

3.3.5  Proxy-Require and Require

   This request tests proper implementation of SIP's Proxy-Require and
   Require extension mechanisms.

   Any element receiving this request will respond with a 420 Bad
   Extension response containing an Unsupported header field listing
   these features from either the Require or Proxy-Require header field
   depending on the role in which the element is responding.

      Message Details : bext01

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:j_user@example.com
      From: sip:caller@example.net;tag=242etr
      Max-Forwards: 6
      Call-ID: 0ha0isndaksdj bext01.0ha0isndaksdj
      Require: nothingSupportsThis, nothingSupportsThisEither
      Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
      CSeq: 8 OPTIONS
      Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
      Content-Length: 0

3.3.6  Unknown Content-Type

   This INVITE request contains a body of unknown type.  It is
   syntactically valid.  A parser must not fail when receiving it.

   A proxy receiving this request would process it just like any other
   INVITE.  An endpoint receiving this request would reject it with a
   415 Unsupported Media Type error.

      Message Details : invut

      INVITE sip:user@example.com SIP/2.0
      Contact: <sip:caller@host5.example.net>
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=8392034
      Max-Forwards: 70
      Call-ID: 0ha0isndaksdjadsfij34n23d invut.0ha0isndaksdjadsfij34n23d
      CSeq: 235448 INVITE
      Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
      Content-Type: application/unknownformat
      Content-Length: 40

      <audio>
       <pcmu port="443"/>
      </audio>

3.3.7  Unknown authorization scheme

   This REGISTER request contains an Authorization header field with an
   unknown scheme.  The request is well-formed.  A parser must not fail
   when receiving it.

   A proxy will treat this request as any other REGISTER.  If it
   forwards the request, it will include this Authorization header field
   unmodified in the forwarded messages.

   A registrar that does not care about challenge-response
   authentication will simply ignore the Authorization header field,
   processing this registration as if the field were not present.  A
   registrar that does care about challenge-response authentication will
   reject this request with a 401, issuing a new challenge with a scheme
   it understands.

   Endpoints choosing not to act as registrars will simply reject the
   request.  A 405 Method Not Allowed is appropriate.

      Message Details : regaut01

      REGISTER sip:example.com SIP/2.0
      To: sip:j.user@example.com
      From: sip:j.user@example.com;tag=87321hj23128
      Max-Forwards: 8
      Call-ID: 0ha0isndaksdj regaut01.0ha0isndaksdj
      CSeq: 9338 REGISTER
      Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
      Authorization: NoOneKnowsThisScheme opaque-data=here
      Content-Length:0

3.3.8  Multiple values in single value required fields

   The message contains a request with multiple Call-ID, To, From,
   Max-Forwards and CSeq values.  An element receiving this request must
   not break.

   An element receiving this request would respond with a 400 Bad
   Request error.

      Message Details : multi01

      INVITE sip:user@company.com SIP/2.0
      Contact: <sip:caller@host25.example.net>
      Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
      Max-Forwards: 70
      CSeq: 5 INVITE
      Call-ID: 98asdh@192.0.2.1 multi01.98asdh@192.0.2.1
      CSeq: 59 INVITE
      Call-ID: 98asdh@192.0.2.2 multi01.98asdh@192.0.2.2
      From: sip:caller@example.com;tag=3413415
      To: sip:user@example.com
      To: sip:other@example.net
      From: sip:caller@example.net;tag=2923420123
      Content-Type: application/sdp
      l: 155
      Contact: <sip:caller@host36.example.net>
      Max-Forwards: 5

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.25
      s=-
      c=IN IP4 192.0.2.25
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.3.9  Multiple Content-Length values

   Multiple conflicting Content-Length header field values appear in
   this request.

   From a framing perspective, this situation is equivalent to an
   invalid Content-Length value (or no value at all).

   An element receiving this message should respond with an error.  This
   request appeared over UDP, so the remainder of the datagram can
   simply be discarded.  If a request like this arrives over TCP, the
   framing error is not recoverable and the connection should be closed.

      Message Details : mcl01

      OPTIONS sip:user@example.com SIP/2.0
      Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
      To: sip:user@example.com
      From: sip:other@example.net;tag=3923942
      Call-ID: 234asdfhn2323orihawfdoa3o4r52o3irsdf mcl01.fhn2323orihawfdoa3o4r52o3irsdf
      CSeq: 15932 OPTIONS
      Content-Length: 13
      Max-Forwards: 60
      Content-Length: 5
      Content-Type: text/plain

      There's no way to know how many octets are supposed to be here.

3.3.10  200 OK Response with broadcast Via header field value

   This message is a response with a 2nd Via header field value's
   sent-by containing 255.255.255.255.  The message is well formed -
   parsers must not fail when receiving it.

   Per [RFC3261] an endpoint receiving this message should simply
   discard it.

   If a proxy followed normal response processing rules blindly, it
   would forward this response to the broadcast address.  To protect
   against this being used as an avenue of attack, proxies should drop
   such responses.

      Message Details : bcast

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
      Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
      Call-ID: 0384840201234ksdfak3j2erwedfsASdf bcast.0384840201234ksdfak3j2erwedfsASdf
      CSeq: 35 INVITE
      From: sip:user@example.com;tag=11141343
      To: sip:user@example.edu;tag=2229
      Content-Length: 159
      Content-Type: application/sdp
      Contact: <sip:user@host28.example.com>

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.198
      s=-
      c=IN IP4 192.0.2.198/127
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.3.11  Max-Forwards of zero

   This is a legal SIP request with the Max-Forwards header field value
   set to zero.

   A proxy should not forward the request and respond 483 (Too Many
   Hops).  An endpoint should process the request as if the Max-Forwards
   field value were still positive.

      Message Details : zeromf

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:user@example.com
      From: sip:caller@example.net;tag=3ghsd41
      Call-ID: 2304sadjfasdlfnm2o2l43r5u0asdfas zeromf.jfasdlfnm2o2l43r5u0asdfas
      CSeq: 39234321 OPTIONS
      Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i
      Max-Forwards: 0
      Content-Length: 0

3.3.12  REGISTER with a contact header parameter

   This register request contains a contact where the 'unknownparam'
   parameter must be interpreted as being a contact-param and not a
   url-param.

   This REGISTER should succeed.  The response must not include
   "unknownparam" as a url-parameter for this binding.  Likewise,
   "unknownparam" must not appear as part of the binding during
   subsequent fetches.

   Behavior is the same, of course, for any known contact-param
   parameter names.

      Message Details : cparam01

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards: 70
      From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
      To: sip:watson@example.com
      Call-ID: 70710@saturn.example.com cparam01.70710@saturn.example.com
      CSeq: 2 REGISTER
      Contact: sip:+19725552222@gw1.example.net;unknownparam
      l: 0

3.3.13  REGISTER with a url parameter

   This register request contains a contact where the URI has an unknown
   parameter.

   The register should succeed and a subsequent retrieval of the
   registration must include "unknownparam" as a url-parameter.

   Behavior is the same, of course, for any known url-parameter names.

      Message Details : cparam02

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards: 70
      From: sip:watson@example.com;tag=838293
      To: sip:watson@example.com
      Call-ID: 70710@saturn.example.com cparam02.70710@saturn.example.com
      CSeq: 3 REGISTER
      Contact: <sip:+19725552222@gw1.example.net;unknownparam>
      l: 0

3.3.14  REGISTER with a url escaped header

   This register request contains a contact where the URI has an escaped
   header.

   The register should succeed and a subsequent retrieval of the
   registration must include the escaped Route header in the contact URI
   for this binding.

      Message Details : regescrt

      REGISTER sip:example.com SIP/2.0
      To: sip:user@example.com
      From: sip:user@example.com;tag=8
      Max-Forwards: 70
      Call-ID: k345asrl3fdbv@192.0.2.1 regescrt.k345asrl3fdbv@192.0.2.1
      CSeq: 14398234 REGISTER
      Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
      M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
      L:0

3.3.15  Unacceptable Accept offering

   This request indicates the response must contain a body in an unknown
   type.  In particular, since the Accept header field does not contain
   application/sdp, the response may not contain an SDP body.  The
   recipient of this request could respond with a 406 Not Acceptable
   with a Warning/399 indicating that a response cannot be formulated in
   the formats offered in the Accept header field.  It is also
   appropriate to respond with a 400 Bad Request since all SIP UAs
   supporting INVITE are required to support application/sdp.

      Message Details : sdp01

      INVITE sip:user@example.com SIP/2.0
      To: sip:j_user@example.com
      Contact: <sip:caller@host15.example.net>
      From: sip:caller@example.net;tag=234
      Max-Forwards: 5
      Call-ID: 0ha0isndaksdj9342dasdd sdp01.ndaksdj9342dasdd
      Accept: text/nobodyKnowsThis
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
      Content-Length: 151
      Content-Type: application/sdp

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.5
      s=-
      c=IN IP4 192.0.2.5
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

3.4  Backward compatibility

3.4.1  INVITE with RFC2543 syntax

   This is a legal message per RFC 2543 (and several bis versions) which
   should be accepted by RFC 3261 elements which want to maintain
   backwards compatibility.
   o  There is no branch parameter at all on the Via header field value
   o  There is no From tag
   o  There is no explicit Content-Length (The body is assumed to be all
      octets in the datagram after the null-line)
   o  There is no Max-Forwards header field
      Message Details : inv2543

      INVITE sip:UserB@example.com SIP/2.0
      Via: SIP/2.0/UDP iftgw.example.com
      From: <sip:+13035551111@ift.client.example.net;user=phone>
      Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
      To: sip:+16505552222@ss1.example.net;user=phone
      Call-ID: 1717@ift.client.example.com inv2543.1717@ift.client.example.com
      CSeq: 56 INVITE
      Content-Type: application/sdp

      v=0
      o=mhandley 29739 7272939 IN IP4 192.0.2.5
      s=-
      c=IN IP4 192.0.2.5
      t=0 0
      m=audio 492170 RTP/AVP 0

4.  Security Considerations

   This document presents NON NORMATIVE examples of SIP session
   establishment.  The security considerations in [RFC3261] apply.

   Parsers must carefully consider edge conditions and malicious input
   as part of their design.  Attacks on many Internet systems use
   crafted input to cause implementations to behave in undesirable ways.
   Many of the messages in this draft are designed to stress a parser
   implementation at points traditionally used for such attacks.  This
   document does not, however, attempt to be comprehensive.  It should
   be considered a seed to stimulate thinking and planning, not simply a
   set of tests to be passed.

5. Open Issues and Remaining Work

   1.  All of the messages in this  IANA Considerations

   This document should be considered new.
       They are either new additions or major revisions of the previous
       versions. They all need to be carefully reviewed by the working
       group

   2.  Are the header field values in Section 3.1.1.7 long enough?
       Should we push each field over 256 octets or even longer? Where
       is the threshold of reason?

   3.  Is this really possible to recover from embedded whitespace in a
       SIP Request-URI as suggested in Section 3.1.2.8?

   4.  Can we modify the example in Section 3.1.2.15 such that it is not
       obvious where to infer quotes?

   5.  Can we modify the example in Section 3.1.2.13 such that it is not
       obvious (due to ambiguity perhaps) where to infer angle brackets?

   6.  Is the message at Section 3.3.11 sufficiently tortuous to include
       in this document? has no actions for IANA.

6.  Acknowledgments

   The authors wish to thank the following individuals for their
   participation in the review of earlier versions of this document:
   Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen
   Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson,
   Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua
   and Tom Taylor.

   Thanks to Neil Deason for contributing several messages and Kundan
   Singh for performing parser validation of messages in earlier
   versions..
   versions.

   The following individuals provided significant comments during the
   early phases of the development of this document: Jean-Francois Mule,
   Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti,
   Matt Cannon, John Hearty, the whole MCI WorldCom IPOP Design team,
   Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny
   Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom
   Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI
   WorldCom, 3Com, Cisco, Lucent and Nortel.

7  Informative References

   [RFC2396]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
              "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

Authors' Addresses

   Robert J. Sparks (editor)
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: rsparks@dynamicsoft.com

   Alan Hawrylyshen
   Jasomi Networks
   2033 Gateway Place
   Suite 500
   San Jose, CA  95110

   EMail: alan@jasomi.com
   Alan Johnston
   MCI
   100 South 4th Street
   St. Louis, MO  63102

   EMail: alan.johnston@mci.com

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07052

   Phone: +1 973 952 5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   1214 Amsterdam Ave.
   New York, NY  10027
   USA

   EMail: schulzrinne@cs.columbia.edu

Appendix A.  Bit-exact archive of each test message

   The following text block is an encoded, gzip compressed TAR archive
   of files that represent each of the example messages discussed in
   Section 3.

   To recover the compressed archive file intact, the text of this
   document may be passed as input to the following Perl script (the
   output should be redirected to a file or piped to "tar -xzvf -").

   #!/usr/bin/perl
   use strict;
   my $bdata = "";
   use MIME::Base64;
   while(<>) {
    if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
        if ( m/^\s*[^\s]+\s*$/) {
            $bdata = $bdata . $_;
        }
     }
   }
   print decode_base64($bdata);

                               Figure 58

   Alternatively, the base-64 encoded block can be edited by hand to
   remove document structure lines and fed as input to any base-64
   decoding utility.

A.1  Encoded Reference Messages

   -- BEGIN MESSAGE ARCHIVE --
   H4sIABptDEACA+xdy3PbSHq3PZnHaqJNbc0tJ1g1XM9YItXoxpMyNfLYmh2N
   H+OyZE/VZlOeFtEQQYIABYCk5VScxIet7CW1e04OW6mkUjllc0tqq5Iqzx+V
   a74GXyAAkpAsPuxB2xAJ4MOjQfy+/t59TA3qt1i1ZNDgypwaEhFSFOkKgqbG
   PnmTsXgFqdDgj6ioQE8UIl0R0JUFtLYfUE8Qrnh1v0W9hj+Jbtb+t7R9++jo
   4NuHh4Jvtcptn3l77DlttmxWcr0T4fDg0TYuofW1pxYtD9a2n9x9JNRcP5BK
   A9qq2yzLSEE7xx51qrXKC732C+n4XsOotyWCibS+9oA+L37lel3qGX5ZUOGU
   X3lwkLDxJbPtLeG2DadyDOZtCLf4ndDSSekY9uxFrrC7E9CTikSIhMn62pEL
   B39HA991toSjmtukPhwbdiModcPtY13ZXV+7Q227eHC3LPiGieCuHOwYPqJI
   19uY1EjNcboI6VWj4TC4wO1qlbWCskBbLduq0sBynW3faMFpDtlpWSA6hp7p
   Qv/5ra/ZZQF6tb72lv3+x9To/WhzZACz8E9UieNfViRFVGTE8a+qJMf/UvEP
   iBvhn6MtjWIAY76vCvAa5x8hYAnBEo4zAJLCUkQdvpVwSYxxkWlQHCKaGq5j
   uphYEkb1DqI+AmZikjpxBoDV3nqozgv/AHw2z+F/Fv5FJMpx/EtSPv4vpB08
   fHpwtH/58HdYEMIfw0Cr8wE7KQEM0QvjKIzpTQdQDJDFxK5LuFj0mWE6zVB6
   6CFYhDFXJ5LQu+UJQklUJkkRR7rra3fhdS8LX3nWloBE4RvqCBheQUFUygjB
   f2H/8Aiu6DoBrQLPuRXpGz+/XIr0cLdHyJygeHTWYmkcqr/7PnNOghr0QRY5
   5+lUoP9upVkDocdmZwLWVZAlVKxCB3XooHDwSBoyRHl9za8U19eqleSOoII4
   L2tWaNuwXAEetagi4fHRo+3bTx8J0CvMd3Ysg7kCwVgd7iJwH7TiBa0mbZWJ
   KNx/dCdniD9S/u/Mlftn0P9Qgv+LJJf/Fi7/pSpO4zogb1GWW82iA3bj3D9s
   IyUQWkwNnK0F9galsI1rgb1D07oSVQGJKIny3tjdz1T5oE3Q+t5u/FtOB4nL
   tP+oGCXkP0XJ8b9y8l+9dAEJEH5MURHhp8WSkhADI5BENYos3zFowzfq1AdR
   kNtoqD9S4CYKfkPVUd7Z2drZ2orIbxvfuKxvVKq7bIwd7EBLk9DITKnunAKc
   OFGCE5cuwgH+O8zzl6n/IQkGe5HbgTgVwT385+P/6oz/amL8V9PG/6xD/9jI
   f7sUDv6zRvzTLnOt0xaLjPtHpf7Qn33IV+ND/nBkF3+k5qHjKgWleanyP+wl
   CflfFnP8L6L1h1EBIyR8e2/a2KprMXyLBPdMO4ljsCyXIkv8OJ8eM48fOBr7
   iSZpEsJIhDEfxn+TNkgdM6/LDNO/fWiYQ7eLPJQCRoJHXCjpiR0i4J0MFIUE
   GTPaffsU1tOEAD2TaWdkIgpPzg1EWItymN3zCwu6NlFa0LVtEau51Sdvl8f/
   2fNgvtpfBvsPKHsx/z9Guf63cPkvgwL47CIuAAmzwIsLgsok1W997TE7bVse
   8FzHDWqWc3LYbrVcL/CPapa/lbZx3wpqDK7wyHOfnxUjh/MNFvP7tIPjvbvu
   becsuS/FVTg2tB3dPxRM1zaKwMeL8NqE48gs8Tc+tKyYaHlsnVRdY6n+PySj
   qP9fDPU/Wc3xv0j5T8K6pCsqQaJwzIKAeRxnwrHHaEMAcAkeqzKrw0E2WUJE
   cUkPE10DVLssgnXqG65J2nWMCHx1TAJXbsO3mkl9wmqh5Yf6ujWS+IikSzGp
   71Yau+opikSnjm9afbnvVprg1yPUEa47htNgJBWkE8Q76GRCvnubf/8qcGxv
   yf4fVZbj+McI5/hfGfvv+MitvalFWOf+fvjj4kmO9rZz4p3FPe2p0kKXWRT4
   hdEgGezE4w785JBd5P4dqYiJjMm5Xfs6tAuYhqfYhhdhHK7CS02by/X/SCpK
   jP9qbv9ZSHu8/4uDw6P9xyFeU8GfQJFPg7bnXMjxO7L88svF7LUDy83dhvn0
   pN7wggddyrx79wZG3/RDIowB9EcR7SVvb8AZsDDobYTv8LNuirqKZVnG0PZO
   umKU8+y0nYbjdp0QJ++ecbiPf7xU/MtKEv+5/v9jxb9GNBgqLwnzJA3zt84F
   +t132SVkHNseO12q/Y8HCMTxT/L8n1XBfzZRP7m3H6iFZbFO6gQnkoC09bWD
   mDCv61z5Nx2b2A0Mr4CIYwN1/yrxQN+R6D8C+2QzBZbTWFUYpzzBXAd3OlKT
   omEkYw9qcI/j+7NEyEjwwqc9n6TKo6sAHEnn+JH3olEk54mRSek90VAv0nr+
   4cyXEA0jZNZ4cu/WjMb86rzdP7P9/zzmZ4z/4zz/a/H2H1j8ArnNOWxBQhEW
   FmVYyXGhoMo+K6g4jemFgtZBAQP/6jD4gEdYZX70fH1bLNES7E9dX7N6uSFI
   D43CjXrDwcR1YAUVSSQxBPOUUCmr2Ydz3XRPzRQn//qaMLRQFZQ7ackgO7Ad
   HsOOU1DEJqt04MNuQ6flApEKRNy9JO45kXnmYQF5uxj/x0u2/ytKQv7nIWE5
   /1+I/F+QVBCZC5Lc0wE8dmL5gUe90kRtYKPwSyDvR1V7zHfbXnVM5t0dpvfP
   pAzZv4kJrlPDrI8FhXGm75x2XSJ5p5hYRKp73DtYdWxMHM9uOD6PCxv30N+Z
   mQWIkV4wX/gOs6MjiE4kSYg+i9SExTH7AbUt6os9p2DMJXinoHyVIMW98LA4
   afKcJCQkMcI5mSAA/07btpfr/ydqHP8yye1/K6b/89ekWECoyL9M0nAnEvUt
   e7qOe/U7pqQDEx0j4hhmp1E3qG82TklXcgPvFFHDN4El0I4xTAmWiK5x2W+K
   3j/L6ReJ0xkBEbqwlzhwN4VqEuH98tthMAT8e23PWm7+fwr+pdz/t2j9L27A
   ++Kx2w5YpUDuxHhDgexfSm0AIoEGpKXlhE3Kvg/5x6S4gFBVLHKpoVYv0joj
   x14ReMMp0rVu0aRd5tXwabEmOfKIfQCrgaEfT9cdi65ZDGqsWAPxJXvA3zxN
   aLkSmLfLaZbjt80l639SSvyXmPt/ls3/Rzy+zy3DuK3ZHgZdvhBjtPu5t+fk
   hfpEd4Ke10fJgv+gyYLaUuU/TBL1H3P5b0HtOrwAzGN+YDknxQfwJrhGmIQn
   K6qmP7u5+X2pYDkGY8aNlyGTEJ+1nbbfpnbpyeODl58FbvGYXffbHvv855bv
   3Ag2reDT7apHX5x9sbW9s3Oz/HMr2KxRvyJudZnlGddvtqj/add9aTwLXLf0
   meEyfljRCj7fmx1+MrDviNOCOEvXC4py89nm9zde9u1VX+7fL//qQ+HhE/i4
   Itzla3/TN0qdtz+pZq7AbTBHfPl97wu+sfms943cLFwvFXsXarYdgzox45cJ
   hz/iMSY3brzcvPkMiAuVjR9+9/pvf/jt6z/A8p+w/A+svwrXf/f6H2D5DXz/
   L1j+eyMUop+FV3op3tj8Hq5WLEUE4q7rGYVf3iteL8HTuLHHV79/+flnu7fK
   v9re+Mu/+OKv/ypSWkvEmGiycI73IS64Yx6wyp4Dj/eBqX/NqME8uHbh5uYz
   +CnKP/zH6z++/t8f/vX1v7z+N/j7d6//6Yd/f/2Pr/+48iky77j818GyRJZq
   /1MUJRn/n9v/Fi3/PQH578u9bDGAlhmcdEuTPL6bIkFElmUR2h6Qlqq2BQAf
   j7CDq1VaNddhuzzjrwrMqRgaHPrnSNzNTpMahlfx/bi1fWCB2OTFAwYBfVGy
   8ctFGKSoimra/UVCimRlKPBeblGYN6jqd5nMEfDfDpbt/0MJ/x/GOf5XSP/L
   Wg3zjdKCtNDwL031DYwXiTJ806rzQt7EGMWCyJI0JQzOd5ssW53QyXDvBweb
   rtekQVJ8kUL55VaIXXgmwq1WtdkWeJJxZUOSyMY2bLy1Pdi95N/fdp2TeQcA
   z8C/wvfF6j/JGOX4Xxn8h0rUgcCDuAQqcDrBoU0muKYA8r7HmuwNP4SW53KA
   ALo2UnN7ywq8H2NR+WKlw7wz/vpe5tKhdpvt8G/hRXgv571U/Br0vHfheXQp
   bQl1TgaK3kP4+M4Kag/dp/wGuEbb49G0SV+ACmiHt9Nj2Pxm57k5GReNdW0V
   /0tYGryKtVDLncu7UuldInKF8B25nD+D+w9/dZv5/rALl/4lMnqD9O0xWDlb
   /N/Bq2YNJQWi8cgBNBQVnvSeSPE+UF7mUuQYKwv9B168bCgXe7/n/M7fGvCK
   YsjzK4u4UtinFNsfcCZCxtW0TpICj1M8TVKIMYq066A4ze0EDdZjNAfJ84zX
   A+M0KedRY31KuR+sxGlSziPHaNLuR4rTpJwn9oyfCmUhQRN7yp00mvhzFoTk
   tVD8PEkaUU/8XilEWpIohUqd/dOLSgYaOQONlIGGZKDBGWgyvNIimk2jzybR
   ZpNkeMgZnnGGR5zhCWd4wFme7wyShE7ZL5hjVIZ2nYGauSghbxFLr0t9dj0z
   YnYJMuUF5uywf0xBOXZwEsw7AHCm/W9s/q9Q/1flXP9fpP6fXlDrcqL8dKyL
   CV9hNNBf3IvYvvsOydlhJvIcZ+lR0CXb84ko6QRrKlo1PmB3fcPyW0v1/xFV
   jONflvP8n4W0y5n/b6OHvY1bKXxgVJlvRtw/DzOgx1VjzwQN8yzNGaegCZU5
   OV9IHJVu1s8n/4vjf/nx/xJK4F/J638u2/6/I9jebBbQg/ZzkxV1GM00jRRf
   6GaWqsCkV5894e+TYymAvGCoVefTP/C5l8L4/i4I972vmkWR33WI5DXCtKK+
   E1AkSEXcl5ShHsbE4kWY6NNkDHHxMsZ0FWNlZYy8rTT/5wwwWOr8XypJ6n85
   /18k/0+X/yZWgH0jhVDTRGksbQtJbXQKeojZcE5BBgRGLxGk69TgCeC0y8he
   iiwoajrRtBlVP8RZ8iDRB5Ve58LjV9+M1Kzay67/g2RVieMfiXn8/wrpf+cu
   qcMLKmCSjU24fPKGNLMRTzcaYxRSmNzpcDnQ9awa7ZqGS4kreTJ2ieX5o3mC
   RBlEoZGymABmQhNVUJJKjgM+YM+D7ZZNLYfD+ghum93wBccVuvRMCFyB+0Xh
   0XSFJnXOBLcasMAXqMcEn08y4TODEx0zgR9YWg0ltGn5TRpUa/NkAjPtP3Lc
   /ivBthz/q2f/uVBcJ5FkLGee/oXXIfSfG6adtaB7bvK5FPzj5eFfRTiJ/9z+
   u5D2cP+7B/tHX3979+3gABMl9ZigPp1TTC4BONszTPSLiPRp0vxKWGiabTuw
   5qwBzLL/ikrC/0uUfP6Xpdh/AdAtEF4z5n9geRbuBu87lrPWh+/nXY0gP2AS
   usanidqLIKhPqs+kxVOY1NCGzc3RvATxZJ1lsCehsWSxd4eVr3gubbYAlGmm
   Z6LEHnvCgn5ODoUneq/xpRdRyOWwVWpO1Z6z9SeD/CfF7b9YkXL9b9n+v0nW
   XyxLbyoPhqYdIk2SALEYmo88WcJdMowJQhligkiW4n7jdyWTNzPyFi8y7xcv
   dDMhXIgsNFzQcT1GfddZ6vw/GCf8Pyj3/yykDeb/hJ9IePO5PQ3fwQTpdQpI
   5jN8WrxGr65jzOt5TpzDPZ/Nc4njv9thtl9davyfhOVk/ac8/3+x9l+XtkrH
   jLXK29sj0JMyQQhfThiwloj0IePOHQQaktOL+IHTo1PgME63FwDUsEe1ukmv
   hPCkObr7uRh6Fs+vlNceOm27wTFdbv1vVUr4f2Upt/+ujvwf5v8/8ErCNyWB
   1+XpjaJJ0X830+S/KXNdiRNrfEwL8tfjgnvWObBkvSwjGWVgC5kDPcgy5sG6
   BBXAYye0HSx5/l9JTYz/JI//WEib8/x/mkqwWKtjImIt0wR3fcyHSAZWMXFG
   Pz7Oj2yUE9T+2+2g5nrWixC5ZeGh+63D7jlu1z+qWf5htcYrj7gtetpmRXj9
   aYXHZSTA/W5LBID/Y2pUg+XO/4vj+Ffy/L9Vw/809KdiX9c1QvDUlJ8GkWTq
   ezYxjePOnohK/J84SgKcNp0nkUuiBtSEL2TKFMRjM4hOn+QAltL4RAfvevQI
   4J9PAbJc/EvR+u8kt/+9G/jXzgP9uFP3Emf2eTDBwjgL+m/RLD4Xbz4oVNSb
   7xSAM/V/IsXxL6Nc/l8R/KcXYMfTDGxEwr5hupPN9lFbwRTrP+baOK7XhoFg
   RNF0IvEEElUSdT5xMMERDhHNG3S65LTuYeKilqF3qGOfkq7j2Q7rumad+nrb
   SsomBEF/95+3LI+FRokFtMmuifEnzAuJCjusd28VrCGsq7KuKARrovwGZswe
   /u2TZeJf7sV/j8n/ai7/L9T/JyMiHDKvY1WZ8MShHWrZ9Nhm54Q/CuH/4sVz
   w+LzdvrdzAwgEVLV5wAMoFw3Wb07NArgMDFEI5Kq8tQxhAkRo6keAx7gdFwK
   92B5jkt9hlyTx5XWHHzqmi7lK5iyrsnP5fEC5IF3VrxtBsyDS0g6QVgjGjwU
   /slX+XV0DUSa76jnWM4JT0CDy7od5gVtjwkbB47wyHNPAJ3+xlvkVvCN1tLz
   v3iyZ2z8R3n97xWz/4dGvmdJJWBy7mQ8NjRDSYCpxQDGbIQ8QMgA3mCsr92u
   Vlkr6GdnOe6xa5wNjXzncAqIM6atGkvqXJm5AN7UEeCzprXk+h9IVpLyf27/
   W0yL53/tQCcr7YKEIuA8P1OYCHXXO+lFAxAs4WnxAKkOAW00zA9AH4Pe1tiG
   VqPqq8Wm1WRbXHzutTDjAXoZbDet58zYimzwrRMHtkRoYTSnJwx2wJkjK6ZH
   T6axkrcnD83nT2e5+R8qSo7/RM7zPxY9/vcrll4sBZwDe/ylBzHdc3qxOxEt
   IO0i45qAzxxjnGMMjQFhZhiz2lFGQU2nUWee1XZPYQ/tOA2bmqxRPwXRvy2R
   Nu2yYVkgjcvwMIIOhYFZFUv795Lo6m5SLCBiMm4gzll2Rpyl11qeG7hV165s
   xNlWUS3yYyhXLjYSxzWB1D6p+DUqJvYdu3ymOe+sslGERqQ7X8n6HcCbIol3
   7yJN1WVdgibK6h11/8sNzpCKxSykid6N+CE/Sf4mXfBNWoWh7LzxLlI05L3X
   t1Upa3LR13kaAnfC+U4qG+FoWWqpURX/yOMhyswr7jtV1whNA8eWAwAckdy1
   /JbrW70oBBrAa1FrwvYdwbRsljzz+hp69dHff/CTm7/++tf/t371w2u/f/XR
   GWxqX7t6VfwY/eSD9zd/+t61P3//Cvp4RHT1968+eIFevaejV9f++ffvXbt6
   7dpHV3575TfXPr1yFa0P6a6+D4e1wrO89+RPPvjk2pND8RP0M77y0SccC5bp
   eo5FxZ+hP+MbP/zko0PqfOP6TPwp+lO+Ze2T9+G1sQLxc3SDr3/8/+1dDVAb
   xxVGApuaBJNgYpJi2i2044Qg2PuR0QkrQ+o0iakrbAubjONJfOhOSEjc4bsT
   Mo49QdiN40xTZjJuZuI2sRk3YzIdd9o49jieJA52fsfJGDEpzQ/QNJ7Wps3P
   uNNpUpqf7t5JIAkJcNqIlO7Hj3R7t6fV23333r597+0SFz5sFFVtlahoPg8m
   ohh1vdA64beK8yFDQZqiWJahrZuK8yl0SNmih7D5v9KYEngdPs4uKpzK9TB8
   IJ4CpgVZ2eEHs2B4rzkczjq7y7ywoPCVcUvxfQ9V9qrDf+06VVLywMf11JW+
   4OMbD7sLjr97y1tj+4bf2P9FZ8cLzb/vu+A8+8895b8+tfzhD0aa3U07AjeG
   hnfAK1yOD47966dHu+8d+vTnNU8fHO0+UHJVeIjuO3LgN3n3Lbr+Ys+ed5/u
   PCneUP/y0GDkgW2v+BsOM3uc5eZsU5bpUHgMhv8MS9E3KL06ZyksCqf6FphI
   pUtyzDDLuHJxztKcorovll1ZcsK75oniXY+2j+38ZOTOLREY3o/Pl+eEH4Lh
   nq4i/63FRX/Z1/G9rkZpSePbvecbi3qP92q/VDI6DrpNWUnDMBtRX/78m7Wb
   L+aeGan87B9j2+5dvWz3Ox8PR0qfHOq7f2f1+b9V/cK775Hvd/8p7+AfPl/2
   rPP0aXPxrm+fPrKi4NLzo6V/vNh+VeX4Ix+uXbPz+TeDFW5E2ttHRsdHN7w0
   sO7S643nLvS7lu9tfnzlR/yJYP9nK7Ux5buVJ03U0RMv5Z762dFt36l84vBd
   hGEIwxCGuQyGobpNQ7DbNIhEEdyRUXrEceekBDwY/i28doJIi7KpeIkIl02e
   WUAVRNmKpqw00v82wfLJszkUGhn11b/7sX/LwpvpReMbD/a/ua7znbN3w/WT
   FxVQP4CrYN7CbxgF2blw8cR7s9mc1YW6a/LYVAdzjWbmJpZfn8RaOeGu/jPX
   rfx733OF246t33+u98XS0dFz+Y4X+nte3H9n4eK2DQdWuw6defnVe5xHdt1/
   aW3P9sFPt752z2ODu2/bu+XQ+5907n5v0zVP/cp9ae2ZBe3HqU3ly8+HP7z6
   ome4aMHbN1xYc9psCsvXLB3Zy9Bv9b0nn3y/fMfqhpvGP3I+M1hYObqzafT1
   2alLFgsJ3Z6H0BC3fdUB4DP6fyXkfzfWf1ji/5Vp+w8f4KW6Vl6V23zRdBcN
   AE1XkkuNCbbCB9q9iUbfH/F3WDwNShO/XnDZAerytA7e8e5ed3Ru395poe1A
   8/pUgH41rwikYFszmlGiyRMwgkOMqxj7xHxbL0jw0UANEHljadYjy6AZ9Srq
   MdxgWcYHiv6SYi5rm+1yDuYVdH+HnsNjvvA/nr3irTfVOcz/tSLZ/ssyFOH/
   OVn/+XL7P/xH+z4AyePmRK9H8PCi39fqZXm/IPFbW/0hpNKrvOrBC0BpjGSz
   2hli5jTASZVcqxpRLXq6WgFebRW8nmT/mDUuoDHT1KM5GwxKAv5Gic10/tDZ
   0OQEGjtNZV4VoIcRpRROOdP6wUKe8wkeSRRTLEFpSkida/lvhVP9P8j+D5nn
   f0VskzXRgujRknrRF4B0/mD66Esz4rGrBuQSTfdpPijRfh+Q0SPFooiqHFTc
   YqoHC8eiqZyNSzDiiyFF9rmDDMtZsZVeEj04gtyr0AxrVWZ8kNCMjYsPLk9t
   158/EeNBya+6277aJ8DM8R/MlPVfwv+Z5f8kvykjONKuyRrePNmIkXQbA59k
   g5hPwPzfRs8x/zNx8Z81UOd/yBL+zwRmF//lU5slO9JdmRqOttUwE1Laq2k4
   YUwoFKpKpfYjxkzr01Xn7Wz3ihKviYIlOY33pDBmORgf4DFVGqdPOErNJiR0
   JV59tdfLXuluV5tP8970/5YtPCjNef43CtLx8p/V4z8pkv8xI4hp9jSEwAHo
   igoGVABrRQUNBp4deA5EwpFu9DLw1MCxgScjPbgsqSjSHfkJsICBU5Gu2LmB
   Y9P5RnK2JJ6kGJrlEjaEhUg9sLFQz5bL+rHQ9zOttKiERMGj3uyaJpVc2mBU
   ijK2m0ujtYhC0HANomkulcs3NysXmVRhXJxtSoa5y0sTw9nSus5wtmqKrvk6
   by9N8DVHSPVJHXMb/0PVWKfofzRL4n8zvf7T4esQ/S11bi/vUyyCpLgTJk1o
   ooAmhxKiAR+vHDYAe37ezNVBLQAAPWCxJ6IDPcAoG/5hGCk/z6PgneaAHZTV
   g/WyKkrNotICNm/eXFYWdV00so0JCj5ZNyUmFv/Dd3boSd9bBduXXYlKfOrr
   TdJjfdyqnn0YQg5/VFwcEb4CUQKAanSxTg6ARZ3hczmhh8akHcNBNap+qpho
   TjF0Ky+1BEThdpEXcNwhAJIY8hhloIMPBEV0Kzzr9klBVDL15AajT4z6TUh9
   3SAF1SAf2IhP20FtbWUl+qudUXbpiRBwP0ZdVfUwUDWh+wNKbASE0Oc49AbE
   SiySbNELUId02EGMJrrBsBrgOTiG2u7D4i5hVES7z6AQHhkAxHx+ff5WGwDY
   gXWCxMYd0VusT+gEplbYqmirtQpJd3yv6I0cqFIsEh2HbSLhZy9bF5TRVAOo
   muKT0PAqw8Mr7cBCt0LUNsa6I+ZDi0r0b2m0WcX2EMG4pBZsRW2HVczlZ4FL
   mweazYxY3y4i9vPM8fyfhsn6P7OC6P//Q+t/01n6WryqwFJJG36qvNCKTXkB
   j9RGy3SAZRRrEBrmvgTTHkNT06zszWqPT2xF8CXbDiBJ/UpAQEBAQEBAQEBA
   QEBAQEBAQEBAQEBAQEBAQEBAQEBAQDAP8G/qAJOHABgBAA==
   H4sIAHCZ9UACA+xdy3PbSHq3PZnHaqNNbc0tJ1g1XM9YItXobrwoUyONLe9o
   /BiXJXuqNpvytIiGCBIEKAAULafiJD5sZS+p3JPDVipVuW5uSW1V8i94/og9
   5JRjrukG+MCLJPTgw2P0DC2SaDy6+f1+/X1ff/31EdGJ16H1ik78azMqQARA
   lvE1wIqS+MuLhOA1VkWRkIgliX0vIlkUrwng2hxK1/OJKwjX3KbXIW7LG1dv
   2vF3tHz75HD/28cHgmd2ql2Pujv0JWl3LFpx3GPhYP/JJqyA1ZXnJqkOPm0+
   u/dEaDiejyuDunWnXZWADLaOXGLXG7VXWuOX+OhBS292MYIIr648Ii/L9x23
   R1zdqwoKu+R9l50krH1FLWtD2LXYpWydumvCHf4kpHJcOWJHdiJ32N7yyXEN
   I4QhWl05dNjJ3xHfc+wN4bDhtInHzg2a4Vd6wfexpmyvrtwlllXev1cVjgYy
   7+kGYI9nQ1v3AAGa1oWogRq23QNAq+stm7I77dbrtONXBdLpWGad+KZjb3p6
   h13vgJ5UBaRB1kRN6Hfk6opVFVjzVlfejd+f9UX4o82QAKbhHwM5iX/2vsD/
   QvHPEDfCP0dbVo0BjPmxOoNXnD8CwCIEMUwSAMqgFFFj7yqwIiZYZBICI4ju
   S7FHdMc2HIhMDEHzFBAPMFoxUBPZA8Sq7ypWZ4R/Bnw6y+F/Gv5FAKUk/jEq
   xv+5lP3Hz/cP964e/jb1A/hDNr5qfMBOawBR9AYyyIZRNra3bYZhBliIrCaG
   5bJHdcNuB1pEiF+RDbkawkL46GOUk6hukqGW9FZX7rFbVoX7rrkhAFH4htgC
   ZKIoiHIVAPa/sHdwyO7o2D6pM+65E2kjv75UibR0O6xIbb98eNahWUzVP/yQ
   2sd+g7VBEjnvnNZYPzi1doMpPxY9E6CmMFVCgQproMYaKOw/wUNilFZXvFp5
   daVeSx/wa4AzWbtGurrpCKzLRQUITw+fbO4+fyKwVkF+8NTUqSMgCJXhIcSe
   g9Rcv9MmnSoShYdP7r7PdPhe8r89U/bPYf+JKMn/oigX/D9v/S/TcIrbgLxE
   qbaexwbsJdk/KCMjkJWEGTjdCgwHpaDErcDw1KymJExAJvZM3kRpJ9aGqfYe
   K2NMvncV/6Z9CsRF+n8UpuyN8C8F+h/7U+B/2fS/ZuUCGiD7MUVZxLIIsZxS
   A+OQDCURNAgwPVsnLU9vEo/pgtxHQ7yR/TZW8xvakNLW1sbWxkZEgVv7xqF9
   71LToTFe2GIlS0VDU9W6c2pw4lgVTlyUDsd6/ZS63iLtP4AxSuFfUQr8L834
   r6TGfyVr/M879MdG/t1KMPhPG/FPetQxTzo0Mu4fVvpDf+4hP5B0PugryUF/
   OLaL75lz6KhOmLG8UP1fBGJq/BdRMf7PpfRHTwECIHz7YNKQqqkJfIsIhq6d
   1DlQkiqRV/I8jxxRl584wmYghQCpWMUAApEN+GzwN0gLNSF1e1Q3vN0D3RjO
   uUhDFWCkfiRVk1D5EBna0cBcSFWjerfvpYJalgag5XLsjBxEwcW5ewiqUX7Z
   Pr+moKljVQVN3RShUvh8inIV/E9f+rO1/nL4fxQpxf8yLPh/3vpfDgPwxUWm
   ADCkvptUBOUo/YdCGDP8Vlee0pOu6TLStR2/YdrHB91Ox3F977BhehtZX+6Z
   foOyGz1xnZdn5cjp/AuTev26g/Pde86ufZY+ljFPGBvhDh8eCIZj6WVG5GUm
   PcFAMk0LTo4ty6JZHpnHdUdf6PwfkEScsv8wLvA/T/0PQw1rsoKAyNDo+9Tl
   ABOOXEpaAkOV4NI6NU85usZriCCp6UGkqQzODo1ivS9wxNMdA3WbECD21jYQ
   e4Iue9cwiIdoI3D8EE8zRzofwhpO6H13smgrNBiRRmzPMPua350s1S+sqAHY
   tHW7RVEmSscoeKyxKQ3vXfz964yx3QXP/ygySo//hf23PP7f+MitXtYjrPF5
   fvaPA8dNsHftY/csOcM+YJBQZGPKQo+ahLGF3kI5nMTx6fv0iF3m8zu4DJEE
   0bkn9jVWLuAXnuAYnq1nuM6EmrQXO/8jgYz5H1Dgfx7l6d4v9w8O954GeM0E
   fwo/HvG7rn2hid+R55ffLuGvHfhs7rWM58fNlus/6hHqPngwcPpmnxIlhoEs
   K0ARwU76OQfkAIVBsyMExC+/LmoKZCIIWdk57olRCtrq2i3b6dnBTX403uF+
   n8FF4h/LSgr/cqH/v6/4V5HKBsnzYR5OxTzKwvydc4F++0c4J6QfWS49Waj/
   T0RSCv8IFvO/S4L/fKp++mg/UAtKYhM1EUwtAlJXV/arQl/+Ytq8pnHb37At
   ZLUgQliEiWG6f7NknO9I9x9Bfby3AkpZjBWEK49x17EHHllL0SCSWH8NnjF+
   PE+gDGZyn9VNQ7JLdpamMBhhjaNJ2omGkpwnUCajE5AKwnjr2Qc1X0FIjJDb
   8ilmuVKFevVZT/9Mn//HIMH/UJGK+N95+3/YyyuhXU6tJQwi3BVlqvS4UFIk
   j5YUmMV2gX61X4KMsU4p+8O6sE696PX6PlikpnhPWV0xq0Ion3xlCNACl3Cr
   2bIhcmz2AZRRZFkI5AtDcV63Dyfd7ImaCZP8qyvC0E9Vku9mLQXZYt+zztiy
   S7LYprVT9sfqsqZLJYRLSNy+ItYcS5pFWEBRzsv/cMH+fzll/0NFKfz/c9L/
   S1hhunIJS6EN4NJj0/Nd4lbGWgNrpV+x6v1gapd6Ttetx5Td7eHy/qk1A/o3
   IIJNohvNWFBYKJqc9O2TnoOwewKRiXDT5XODdduCyHatlu3xuLD4BP3dqWsA
   IdBKxivPplZ0BNEQxkK0RzKXLcacB8QyiSeGU4KJCcG7Jfl+qioMw8OSVdPX
   REFFlKh45f4H1sl217IWO/+PU/a/BIv1/0tm/3MxKZcAKPM340zbsZX6nj1N
   g2H+jgnLgQciiTQIkK0bp62mTjyjdYJ62PHdE0B0z2CkQE714ZJgjDSVa38T
   DP9p036RQJ0RFFlTdlInbmfUGlfxYXW5/YWss92uay52/X8M/3KI/8L/N2/7
   L+nA+/Kp0/VprYTuJrihhPauJDcAwsz2UbPWhI1bdR/wx7i4gIEoB8ZimesN
   jWaZNCk6csuMG06ApvbKBulRtwFPyg1sSyP6YFTDBn842XosO0bZb9Byg6kx
   +SP+Zuk8K8zAolyumLbXNRZs/2FZTPK/qBT+v0Xz/4jj+ywZxG1Nn1PQMuYU
   KoGcTSVFq7/s9pw8qI2dRNCK3CjT8O+3qd9YqP4HQQr/PCVIgf85lJtMAKhL
   Pd+0j8uPmCQ4erD8TpIVVXtxe/37Ssm0dUr1W68DkhBfdO2u1yVW5dnT/def
   +075iN70ui794hemZ9/y103/s826S16dfbmxubV1u/oL019vEK8mbvSo6eo3
   b3eI91nPea2/8B2n8rnuUH5a2fS/2JkefjLw7IiTwjcrN0uyfPvF+ve3Xvf9
   VV/tPaz++mPh8TP255pwj3/6m75T6rztyXRz+U6L2uLr78M38Nb6i/Adul26
   WSmHN2p3bZ3YCeeXwU5/wkNLbt16vX77Batcqq398Ldvf//239/+1w9v3v7+
   h3/44bdv/+Ptf64FCvOL4KqvxVvr37MrlysR5XeA457j6qVfPSjfrLAeuLXD
   P37/+ovPt+9Uf7259pd/8eVf/1UkjZYIIVIl4RwykFTWIQ9PpS8Zp3uMxL+m
   RKcuu3fp9voL1v3V//3Df//xX//tj3/3z//zT39Y3jUw77f+dwoljBbq/5MV
   Oa3/FfF/89b/njH976udfDGApuEf9yrjZnzXRQSQJEkiKzusaqVumQz48cA6
   drdap+HYdJsv9aszoioHDof+NVJPs9Umuu7WPC/pZx94INZFWQKDOL5otfjt
   YqQZCr+oiErWc0ZiiiR5qPhebU6YS2T1uwryZF3Q9Rc9/wdS/j8Ii/yfS2T/
   5c2CeallQWrg8McT5wZCcY1niNI9w2zyLN5IH8WCSBhPCH/znDbNlyV0PNj7
   kcGG47aJn1ZucKDd3AmQy3pGuNOpt7sCX2NcW8MYrW2yL+9sDg4v7Pe3HPt4
   1gHAU/AvywpO2X9F/pclwn9gRO0LPIhLIAKvJ9ikTQXHEJju79I2veQfoeM6
   HBoMV2uZa3qrMhOUWDC+WDul7hkX36t8nRKrS7f4u+AmvJWzftW8Bmt5eONZ
   NCnrFdiclBl9j9mf70y/8dh5zh+AW7QhR5M2ecXMQSt4nJCw+cPO8ut0QDTU
   1GX8H0M8EMVGYPHORFZq4S0idwhk5Gr+GTx/8Ktb1POGTbjyN5HRezDYMC3c
   pezLs/n/OxA5c6grIJVHDoChsvAs7JnyQ1bzKl9ljrWq0O/48lVDuhz+rrO7
   fmfAGeWA+2vzuFPQpgwfIGMohOJm2mm6BozXeJ6uISZqZN0HJOvspupALVFn
   P32deEYwXifjOkqiTRnPA+VknYzrSIk6Wc+Dk3UyrpPo4+dCVUjVSfTyaVad
   ZD8LQvpeIHmddB1RS/1eGZXUdKWMWsr0n16Uc9SRctTBOeqgHHVgjjo5RFoE
   0+to06uo06vk6OQcfZyji3P0cI4OztO/U6qkrMp+4hy9NvTrDAzNeSl783iF
   TerT9dSY2QXolhfYs8N6H4JyLP/Yn3UA4NT8P0BK2v9KEf83V/s/O5HW1UT5
   aVATU/OG0UD/oQyKOxHnd3+Wcnq8iTTDbXpkcMUOfSbiGoKqApaECKyep5te
   Z7H53zPiP4r9v+ZTrmb/v7UQcmt3MnhglJFvStz/QBR56AE5qus7BrMwz7Im
   42QwJjUnp4XUWdmO/WLrvwH+Fx//j1Lz/5Jc5P9atP9/S7Dc6RQQQvulQcsa
   G8RUFZVfaUaerMAozMyemu+T4pQQSGeYDFR3qGPyrZeC4P6ea4fvVITdVrCo
   qD/5JyKmUsoY5YhVFcemLoJIm6RYiPNXLCYbFsumWBTlXeF/ToD+Qu0/BaXs
   P1zE/86T/7P1v7EZYC9lEKqqiOMc35dAo2WfMN2PcTxGQNOIzpd+kx5FOxk6
   oKhqSFWn5PsQp+mBSBvkeJ0Jyy+/+6hdtxad/wdIqfjPIv/Dctl/506mw1Mp
   QJSPJhy+a0OW24gvN4oQRSiqRsPmKqDjmg3SM3SHIAe7EnSQ6XqjHYJEiSlD
   IyMxBcyUJSqDdC0pCXifvvQ3OxYxbQ7rQ/bY9JYn2I7QI2eC7wh8PpR1TU9o
   E/tMcOo+9T2BuFTw+O4SHtV5pSMq8BMry2F8tk2vTfx6Y5YkMA3/SErGf2FQ
   xH8uo//nQnGdCEtQmrT9S1QGmzzzoPdSN6y8qdwLV8+V4B8uDv8KgBH8KyH+
   C//PXMrjve8e7R1+/e295WAAOIUBxmrqCUV9MlOMT/43fUYYaRdR6bO0+aXw
   0bS7lm/O2AKYvv4XJ/CPmPZY4H8R/l8G6A5TXnOu/4DSNNwN5D0723LmfFC4
   3moE+SFJ9EVVU/k2UTsRJPVP0XKfAyeQ1tCnzd3TPAnxeBtmcCRlweTxfweZ
   sPg623yBKJOc0UhO/Awpj/o5GQuOncSGV55QodDLFlnsujVj708O/S+W/4vz
   P5RRkf9l0fN/47y/UMKX1QcD1w6KeoG5HMaW9UExcCG5EoY9NAwHAjnCgVCe
   xH7xJ5PQ5Ry95Yvs+sUT3YyJFEJzCxW0HZcSz7EXuv8PTNp/SC7W/8+nDPb/
   ZP0vXHpvz6EwEYZivrOnybPzahqEPI/n2N3bi108Fzj+O6fU8uqLjf+DUhL/
   EizwP1//r0M6lSNKO9XNzRHoURUBAK8mDFhNRfqgGHWEchhG+rDLgxPGMHYv
   DPxpWaMs3ShMITxuc+7+Ggwtz8wvLnISnXQd/4gsNv+3guUU/lHh/10e/T9Y
   ///IrQjfVASelyccRdOq/3auzX8zNrkSo3HAA5EMzIBJsf1aUmnPu+uVpFUl
   IIEctJA70AMtYuerK/ARu/SYdP3F7v+LZZDCPyj8v3MpM97/T1UQFBtNiESo
   TtrZbiiGMR/AANKMM8bu6ccH/JFzcoztv9v1G45rvgogXBUeO9/a9IHt9LzD
   hukd1Bs8BYnTISddWmY4IDUeoJFC+Y9SNWAdf0T0ur9Y/KOU/V+M/8uG/0no
   z8S+pqkIwYlLfobS10JYIp5rIUM/Ot0RQYX/J44WAU7a0BNJFVFltRF/oQl7
   Ecf2EJ282wF7VeI7HvxIw0jYL8D3TVgs/iU57f8r4j/fdfyr06AfCl4C+slZ
   3Svc2ufRGFfjNOi/A9v4XLh4zKAi7my3AJxq/6NU/AeWC/wvCf6zE7DDSQ42
   hKGnG854t33UVzDB+w+5NQ6bjWEgGJJVDWG+gETBoiYCxA5HiGFILkOphsgB
   HV07JbZ1gnq2a9m05xhN4mldM62bIMDau/eyY7o0cErMoYyfmoj3ME8hKmzR
   8NlqUAVQUyRNlhFURekSbsywp6zjReJfklL4l3Ex/z/X+T8JIOGAuqdmnQrP
   bHJKTIscWfSc8AcB/F+9eqmbfMdOr5ebAFIhVH0GoMTTmwZt9oa+ABgsDFER
   VhSIAAYQITG61CPOAUyybYd4FDgGjytt2PDEMRzCP0BCewa/lssTkPvuWXnX
   8KnLboE1BKCKVNYp/C//yO+jqUyl+Y64tmkf8wVo7LbOKXX9rkuFtX1beOI6
   xwyd3to7NK3g6Z2Fr/9SpGT8DwJi4f9bLv9/4OR7kTYCxq+dTMaG5kgJMDEZ
   QCiqfdcgDw7SGTfoqyu79Trt+P3VWbZz5OhnQ9/eOSYFRGlyTHhsUefS7AFw
   2YkAj7bNBef/AFI0/7cMiv0/51iS67+2WCNr3RIGEXCenxTGQt1xj8NoAAQx
   nBQPMJDLzPkAdTTcD8CfgOBG7ItOq+4p5bbZphtcjQ5LEBrOWutvts2XVN+I
   fOGZxzb7JlKXjerkmLID7MqRD4ZLjidRyvKvR/N4ryx2/YcCovs/hvhHxf7f
   cx//+5lKL7YEnAM7LuxMTXftMHYnYgVk3SRuCXjU1uOMMXQGBCvDqNmNEUVf
   gLvOCTtCTu2WRQzaap4gbHYx6pIeHSYGUrkOz0bQoTIwLVNp/1lSTd1OqwVI
   TMcNJBlla8QoYem4ju/UHau2lqSrslLm5xBuXKylzmuzqtZxzWsQMXXsyOE7
   zblntbUyK3u7X91H6i7Y3d1TFYDvMnzdFwEW1a92VaDcvb/GiahczlM11boR
   D/KLFJJ0QUlahiHsvPEuOBruHrZtWdKaXFScJyFwK9jvpLYWiEilo0RN/EOX
   hyhTt7xn1x09cA0cmTYD4KjKPdPrOJ4ZBh8Qn4lFo82+3xIM06LpK6+ugDef
   /P1HP7n9m69/83+r1z++8bs3n5yxr7o3rl8Xfwp+8tGH6z/74Maff3gN/HRU
   6frv3nz0Crz5QANvbvzL7z64cf3GjU+u/eO139747Np1sDqsd/1DdlonuMoH
   z/7ko09vPDsQPwU/5x8++ZRjwTQc1zaJ+HPwZ/zLjz/95IDY3zgeFX8G/vT/
   27sWoKiuM8wCSoMaksBIWqA5ATsoZfHcx7J7F+mQajPGGFABdRInzd3du+xl
   l7vkPlhxdMJCGxv7cJLQPGwTZWqqpmOm1ZoaZxIf7aitzXTXpPQRoKZOE2lr
   M9pJY2gTe869u7BPwLRZGns+nvfcx577n/8/5z//+f//4JL8wlmIbUSVWgQr
   8fGcwmZ82CIo6lJBVkU3JqIQ8bhQu+Fni+dBhoI0RbEsQ1vuLZ5HoUPKFjmE
   jv9KZUrgp/FxTtEtyVIPgztjKWCalZUT/GYWDD6SHQxmnenLnl1wy+kxc/HD
   j1UPKEN/6TlaUrLtvRXUXFF7bu0eZ8GL55b9brR/6PUdV7u7fub4zd63G8+8
   v7XihaOVT1wcdjjXbfZ9PjC0Gc5prr946J/fOtj70OC/vmN9addI786Sm4KD
   9N79O3+Y//ANCy9s33rupe4jwqIVpwbPhrdtPO1t2sNsbazIzjFlmb4XHIXB
   t2AZeoOym3Pnw6JgqrfARCorzM1GCpJ+5Y2583OLGq6Wzi057Fm5r7jvmc7R
   LVeG73sgDIM78PmK3OBjMLi9p8h7Z3HRn/u7PtfTIhW2/H7gfEvRwIsD6m45
   o3zQa8pKYMMcRH3/h5+p23Ah76fD1R/8Y3TjQ3eVfuWN94bCZQcG935ty+Lz
   l2u+6+l/+ou9f8rf9YcPS19uPHEiu7jvthP7awsuHRspe/NC503VY0//bdXK
   Lcd+q1U5EWmXD4+MjbSeDK2+9GrLr94+3lz5iOO5Je/wh7XjHyxRR+UF1UdM
   1MHDJ/OOfvvgxtur9+25nwgMERgiMNcgMFSvaRD2ms6ioQhuzig9YqRzYgTc
   FfwRvHWcSDfkULEjIiydODOLKkBixUIrxdKQqYXWe2HFxNlcCnHGQvjGxVPr
   j+zTTDbbMurCpeCTxafhmomLCqgvwaUwf/anjIKcPHjj+P/Z2dlZPai5Jo5N
   DTDPqGZefPnCBNHKDfY8cDVrfunY8bfuCP388bFX+585wb0//G7lFfb7f71i
   PXT21E/W/j2/svXddzb1Mavl2+BubtHt5/ZY+p+fc7nR+9pThY6R3ZcXLjuz
   6v7XTh775f5fL5gtPP6Diw0VC2DrL+aee6Hvks3zx2cfPf/8+q8P3XxgYDuX
   detX39zYvcpSIe7Y+lR1x/LXH902PYXJbCbB2tcdVCRtH3cA+JT+X7H5/wz7
   D2TI+k+m7T+8j5ca2nnF3yFG0ls0ATRdSSw1Jtgy7+v0xBt97+HXm91N8jp+
   javZDlCTxzp463wWZ8yNdfVa371pU7eZRpd5RAWgb9UjAEnrcKBpJZpBASNC
   xLiKsY9PuvWCOEcNVAuBN9Zn3X4/cKCmRc2Ga+334wNZ/5NiQmub7poOfhH0
   /Ho9ccd1IP949oq33lRmMP9XrTVB/lma+H/OzPrPR9v/4T/a9wHE8KBXbPew
   vNcl8Q+2ewNIpVd4xY0XftIYyaa1I8TUaYATbmpe2oLuoie7y8cr7S6PO9E/
   ZmUzUJlJ7qM5G9QkF36j+Go23t3YtK4RqOwkN/OKC7oZQUrhlDOp+yvkOdHl
   lgQhxdKTKgeUmR7/LdCaNP6zRP4zLv+y0OFXBTOiR1vqRV8A0vmD6dyXhuOx
   qwbk4k33aT4o3n7v86MuxSwLil+TnUKqjoVjaQ7auFg9A/OzX3RqDMtZsJVe
   Etw4gtwj0wxrkafsSGjGxsUGl6e2618/EeOa5FWcHR9vDzCl/s8ySeu/RP4z
   K/8JflNGTKRd9at402QjNNJpMH4mskFEuFIi2SAyIf8d9AzLP0Mnyj9dS+b/
   GcH04r9ExSHZke7KWDnaZmXGR2mPquKEMYFAoCaV2o8EM1GqdV7Tp/+e7k6P
   IPGq4DInpvGeGIxZDsYGeCSPxukTjlLTiQRdgldf7Sv8HunLzR2i6vnC/1u2
   cE2a8fxvFKSTxv9aK5H/jCCq2dMQgnpAV1UxoApYqqpoEHo59AoIB8O96E/o
   x6FDoQPh7bgsoSjcG/4GMIPQ0XBP9Fzo0GQ+kZwtQSZRb89ydHxHEWFKvBWk
   Fw/6XqadFuSA4HIrdzRPkkoubTAqRRnbzaXRWgSXZrgG0TSXyuWbm5aLTKow
   Ls6WlGHu2tLEcLa0rjOcbTFFW/8Xt5Um+IQgoIhS18zG/1BWS7L+RxH//0yv
   /3SJXYK3rcHp4UXZ7JJkZ9ykCSlvaHIoIRrwscphE7DPy5/6dlAHAEAdLPZE
   rEcdGGXDXwwjzct3y3inOWAH5SvAGr8iSA5BbgMbNmwoL4+4LhrZxlwyPtmQ
   FBOLf+En1wOc5L3dZZtiJcrg+BSLUPG9vl4lPdbHqeiZhyHk8EfFxBHhKxAl
   AFiMLtbJAfBQZ/hcjuuh0dGO4aASUT8VTLRGIXAnL7X5BNdygXfhuEMAJCHg
   NspAF+/TBPQoPOsWJQ2VJJ9sNdrEuH8dUl9bJU3ReN9afNoO6uqqq9FP3ZRj
   l57/ALdjxFVVDwNV4prfJ0c5IIA+p16vQLTELPnNegFqkC47iNJENxguBngO
   jqF0ini4i+OKSPMZFMKcAUDU51f0ttsAwA6s4yQ2noj+xfqETmCq1lZDWyw1
   aHTHz4o8qB7dFI1Ex2GbaPCzl6/W/GiqARRVFiXEXuWYvdIyFnoUorbB6/VR
   H1pUor+lUWcF20NcxiV14EFUd1jDXHsWuLQ5oNnMDOubBCR+7hme/9Mw2f5H
   9P9P0PrfZJa+No/iYqmYDjjCcu3YlOdzSx20n/axjGzRoGHuizPtIU1gkpW9
   ae3xia0IYqLtAJLUrwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE
   BNcB/g03l0QmABgBAA==
   -- END MESSAGE ARCHIVE --

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.

Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees. Validity

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.