idnits 2.17.1 draft-ietf-sip-dhcp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 47: '... SIP server: As defined in RFC 2543 [2]. This server MUST be an...' RFC 2119 keyword, line 67: '... agents MAY contain SIP clients, pro...' RFC 2119 keyword, line 71: '...proxy server. (SIP clients MAY contact...' RFC 2119 keyword, line 83: '... using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST...' RFC 2119 keyword, line 84: '...l-terminated. It MUST NOT end with a p...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 2001) is 8406 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 143 looks like a reference -- Missing reference section? '2' on line 146 looks like a reference -- Missing reference section? '3' on line 150 looks like a reference -- Missing reference section? '4' on line 154 looks like a reference -- Missing reference section? '5' on line 158 looks like a reference -- Missing reference section? '6' on line 162 looks like a reference -- Missing reference section? '7' on line 166 looks like a reference -- Missing reference section? '8' on line 170 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft H.Schulzrinne, G.Nair 4 draft-ietf-sip-dhcp-04.txt Columbia University 5 March 24, 2001 6 Expires: September 2001 8 DHCP Option for SIP Servers 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a DHCP option that contains a single name that 34 can be mapped to one or more SIP outbound proxy servers. This is one 35 of the many methods that a SIP client can use to obtain the addresses 36 of such a local SIP server. 38 1 Terminology 40 DHCP client: A DHCP [1] client is an Internet host that uses 41 DHCP to obtain configuration parameters such as a network 42 address. 44 DHCP server: A DHCP server is an Internet host that returns 45 configuration parameters to DHCP clients. 47 SIP server: As defined in RFC 2543 [2]. This server MUST be an 48 outbound proxy server, as defined in [3]. In the context of 49 this document, a SIP server refers to the host the SIP 50 server is running on. 52 SIP client: As defined in RFC 2543. The client can be a user 53 agent client or the client portion of a proxy server. In 54 the context of this document, a SIP client refers to the 55 host the SIP client is running on. 57 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 58 "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 59 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4]. 61 2 Introduction 63 The Session Initiation Protocol (SIP) [2] is an application-layer 64 control protocol that can establish, modify and terminate multimedia 65 sessions or calls. A SIP system has a number of logical components: 66 user agents, proxy servers, redirect servers and registrars. User 67 agents MAY contain SIP clients, proxy servers always do. 69 This draft specifies a DHCP option [1,5] that allows SIP clients to 70 locate a local SIP server that is to be used for all outbound SIP 71 requests, a so-called outbound proxy server. (SIP clients MAY contact 72 the address identified in the SIP URL directly, without involving a 73 local SIP server. However in some circumstances, when firewalls are 74 present, SIP clients need to use a local server for outbound 75 requests.) This is one of many possible solutions for locating the 76 outbound SIP server; manual configuration is an example of another. 78 3 SIP Server DHCP Option 80 The SIP server DHCP option carries a DNS (RFC 1035 [6]) fully- 81 qualified domain name to be used by the SIP client to locate a SIP 82 server. The FQDN is 16-bit Unicode text encoded into an octet stream 83 using UTF-8 (RFC 2044 [7]). The FQDN in the SIP server option MUST 84 NOT be null-terminated. It MUST NOT end with a period. 86 A SIP client obtains a FQDN through the SIP server option, which the 87 client then uses to locate the outbound proxy server by the mechanism 88 described in RFC XXXX [3]. In summary, the FQDN is used first in a 89 DNS SRV lookup and, if that fails because of a lack of matching DNS 90 SRV records, the FQDN is used in an address record lookup. Normative 91 details are contained in RFC XXXX [3]. 93 It is possible, but NOT RECOMMENDED that the string is the textual 94 representation of a network address, e.g., a "dotted quad" for IPv4 95 and the hexadecimal representation of RFC 2373 [8]. Implementations 96 MUST detect this case by checking whether all characters are decimal 97 digits or periods. 99 The code for this option is TBD. The length of the DNS name string is 100 specified in `Len'. The maximum length of this string is 255 octets 101 and minimum length is 1 octet. For example, a value may be 102 "sip.example.com". 104 Code Len DNS name of SIP server 105 +-----+-----+-----+-----+-----+-----+-----+-- 106 | TBD | n | s1 | s2 | s3 | s4 | s5 | ... 107 +-----+-----+-----+-----+-----+-----+-----+-- 109 4 Security Consideration 111 There are no security considerations beyond those described in RFC 112 2131 [1], RFC 2543 [2] and RFC XXXX [3]. 114 5 IANA Considerations 116 IANA has assigned a DHCP option number of TBD for the "SIP Servers 117 DHCP Option" defined in this document. 119 6 Acknowledgements 121 Robert Elz, Wenyu Jiang, Peter Koch, Thomas Narten, Erik Nordmark, 122 Jonathan Rosenberg, Kundan Singh, Sven Ubik and Bernie Volz provided 123 useful feedback. 125 7 Authors' Addresses 127 Henning Schulzrinne 128 Dept. of Computer Science 129 Columbia University 1214 Amsterdam Avenue, MC 0401 130 New York, NY 10027 131 USA 132 electronic mail: schulzrinne@cs.columbia.edu 134 Gautam Nair 135 Dept. of Computer Science 136 Columbia University 1214 Amsterdam Avenue, MC 0401 137 New York, NY 10027 138 USA 139 electronic mail: gnair@cs.columbia.edu 141 8 Bibliography 143 [1] R. Droms, "Dynamic host configuration protocol," Request for 144 Comments 2131, Internet Engineering Task Force, Mar. 1997. 146 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 147 session initiation protocol," Request for Comments 2543, Internet 148 Engineering Task Force, Mar. 1999. 150 [3] H. Schulzrinne and J. Rosenberg, "SIP: Session initiation 151 protocol -- locating SIP servers," Internet Draft, Internet 152 Engineering Task Force, Jan. 2001. Work in progress. 154 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 155 levels," Request for Comments 2119, Internet Engineering Task Force, 156 Mar. 1997. 158 [5] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 159 extensions," Request for Comments 2132, Internet Engineering Task 160 Force, Mar. 1997. 162 [6] P. V. Mockapetris, "Domain names - implementation and 163 specification," Request for Comments 1035, Internet Engineering Task 164 Force, Nov. 1987. 166 [7] F. Yergeau, "UTF-8, a transformation format of unicode and ISO 167 10646," Request for Comments 2044, Internet Engineering Task Force, 168 Oct. 1996. 170 [8] R. Hinden and S. Deering, "IP version 6 addressing architecture," 171 Request for Comments 2373, Internet Engineering Task Force, July 172 1998.