Network Working Group J. Lee Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: November 8, 2007 W. Kellerer Z. Despotovic DoCoMo Euro May 7, 2007 SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 8, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lee, et al. Expires November 8, 2007 [Page 1] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 Abstract This document describes the Session Initiation Protocol Uniform Resource Identifier (SIP URI) advertisement for DNS-based Service Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. DNS-SD/mDNS Overview . . . . . . . . . . . . . . . . . . . . . 6 4. SIP URI Advertisement . . . . . . . . . . . . . . . . . . . . 7 4.1. SIP URI Service Instance Name . . . . . . . . . . . . . . 7 4.2. TXT Record Attributes . . . . . . . . . . . . . . . . . . 8 4.2.1. txtvers . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. name . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. contact . . . . . . . . . . . . . . . . . . . . . . . 9 5. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 11 5.1. Forming Request . . . . . . . . . . . . . . . . . . . . . 11 5.2. Sending Request . . . . . . . . . . . . . . . . . . . . . 11 6. User Interface Guidelines . . . . . . . . . . . . . . . . . . 13 7. Other Related Mechanisms . . . . . . . . . . . . . . . . . . . 14 7.1. SIP Multicast . . . . . . . . . . . . . . . . . . . . . . 14 7.2. "sip" DNS-SD Service Type . . . . . . . . . . . . . . . . 14 7.3. Peer-to-Peer SIP . . . . . . . . . . . . . . . . . . . . . 15 8. Transport Protocol in Service Instance Name . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Lee, et al. Expires November 8, 2007 [Page 2] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] is a comprehensive application-layer protocol for controlling multimedia sessions such as voice-over-IP calls. A SIP Uniform Resource Identifier (SIP URI) represents who to contact or where to place a call in SIP communications. For example, sip:carol@chicago.com is a SIP URI for Carol's logical identity. Such a SIP URI is called an Address-of- Record (AOR). Another example is sip:carol@cube2214a.chicago.com, which indicates the specific host where Carol can be reached at the moment. Given an AOR, SIP offers a way to discover the SIP URI for the physical contact location (Section 10, [RFC3261]). This is achieved by introducing two SIP network elements, registrar and proxy server, that cooperatively manage the AOR-to-contact-URI bindings. Using the examples above, Carol registers sip:carol@cube2214a.chicago.com as the current contact location for sip:carol@chicago.com using the registrar for the chicago.com domain. When the proxy server for the chicago.com domain receives a call request for sip:carol@chicago.com, it looks up the binding and routes the request to cube2214a.chicago.com. However, this mechanism may not be applicable in some situations. Consider, for example, a wireless ad-hoc network that is formed for a short period of time. In this case, routing calls using the SIP servers is clearly impractical. What is needed here is a mechanism for the SIP UAs in the network to discover each other's URIs without relying on the functionality provided by the SIP registrar and proxy. This document proposes a way to discover SIP URIs without SIP servers using DNS-based Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. DNS-SD specifies a set of rules for naming and structuring standard DNS records of certain types (SRV, TXT and PTR record types in particular). The resulting system builds a service discovery protocol on top of the existing DNS protocol without modifying the core DNS protocol. This makes it possible to deploy DNS-SD using the current unicast DNS software implementations. The later sections of this document establish the DNS-SD naming structure for SIP URIs and specifies the behavior of a SIP user agent (UA) processing such a service instance. Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] often accompanies DNS-SD. mDNS runs on every host in a local link and it sends queries and responses via multicast. The mDNS instances running on each host in a local link form a self-organizing cluster, collectively providing the functionality of a conventional unicast DNS server. DNS-SD is compatible with mDNS (but it does not depend Lee, et al. Expires November 8, 2007 [Page 3] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 on it.) Furthermore, since DNS-SD and mDNS together satisfy the naming and service discovery requirements of Zero Configuration Networking [I-D.ietf-zeroconf-reqts], DNS-SD/mDNS implementations are widespread today (Section 21, [I-D.cheshire-dnsext-dns-sd]). It should be noted that the DNS-SD mechanism described in this document and the SIP server mechanism in [RFC3261] are not mutually exclusive. Implementing the SIP URI discovery via DNS-SD will merely augment the functionality of a SIP UA, making it more useful in an ad-hoc network where the SIP servers are unavailable. Section Section 6 discusses how such enhancements can be presented to the user. This document describes the advertisement and discovery of the SIP URIs only. The discovery methods of other SIP resources are beyond the scope of this specification. Lee, et al. Expires November 8, 2007 [Page 4] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Lee, et al. Expires November 8, 2007 [Page 5] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 3. DNS-SD/mDNS Overview At its core, DNS-SD provides the service-name-to-host-name mapping using SRV records. However, its usage of SRV records is a little different from the conventional SRV usage in that it adds a level of indirection using PTR records. The following example illustrate this concept: _sipuri._udp.local. PTR sip:bob@example.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@example.com._sipuri._udp.local. sip:bob@example.com._sipuri._udp.local. SRV 0 0 5060 bobs-machine.local. sip:bob@example.com._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:bob@bobs-machine.local. Here, the PTR records are used to enumerate the two service instances (sip:bob@example.com and sip:joe@example.com) that are currently registered for the "sipuri" service type. The host name and port number for a specific service instance (sip:bob@example.com in this case) is provided by a SRV record. Also shown here is the TXT record that DNS-SD uses to provide additional information about the service instance. The details of the service instance naming and the TXT record attributes are discussed in Section 4. In the mDNS environment, the mDNS daemons running on each host in a local link collectively store and manage the PTR, SRV and TXT records for the services registered in the local subnet. The queries and the answers are then exchanged via link-local multicast. Lee, et al. Expires November 8, 2007 [Page 6] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 4. SIP URI Advertisement 4.1. SIP URI Service Instance Name Section 4.1 of [I-D.cheshire-dnsext-dns-sd] specifies that a service instance name in DNS-SD has the following structure: . . The portion specifies the DNS sub-domain where the service instance is registered. It may be "local.", indicating the mDNS local domain, or it may be a conventional domain name such as "example.com.". The portion of the SIP URI service instance name MUST be "_sipuri._udp", "_sipuri._tcp", or "_sipuri._sctp", depending on the transport protocol desired by the UA advertising the service instance. If a UA supports multiple protocols, it SHOULD advertise multiple service instances. Note that, while this usage with the protocol part is in agreement with DNS SRV RR definition ([RFC2782]) and with the previous usage of SRV RR in SIP (Section 4.1, [RFC3263]), it does not agree with the DNS-SD guideline. This is discussed further in Section 8. The portion is a DNS label, containing UTF-8-encoded text, limited to 63 octets in length. It is meant to be a user-friendly description of the service instance, suitable for a menu-like user interface display. Thus it can contain any characters including spaces, punctuation, and non-Latin characters as long as they can be encoded in UTF-8. For the SIP URI service instance, however, there is a required format. The portion of the SIP URI service instance MUST start with a valid SIP or SIPS URI, optionally followed by a space character and an arbitrary text further describing the URI. In Augmented BNF (ABNF) [RFC2234], this is expressed as follows: instance = ( SIP-URI / SIPS-URI ) [ SP description ] The definition and the ABNF for SIP-URI and SIPS-URI are given in Section 19.1 and Section 25.1 of [RFC3261]. SP denotes a space character and "description" is an arbitrary UTF-8-encoded text string. The entire instance string cannot be more than 63 octets in length. For example, the SIP URI service instance names for Bob's two SIP devices may be: Lee, et al. Expires November 8, 2007 [Page 7] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 sip:bob@example.com - Softphone._sipuri._udp.local. sip:bob@example.com - PDA._sipuri._udp.local. This scheme is also compatible with the automatic name conflict resolution of Apple's mDNS implementation, which appends a numerical suffix such as " (2)" to a name in order to distinguish it from another instance with the same name. If both of Bob's devices advertise themselves as "sip:bob@example.com" in such an environment, the resulting service instance names will be: sip:bob@example.com._sipuri._udp.local. sip:bob@example.com (2)._sipuri._udp.local. Both are valid SIP URI service instance names. The reason for requiring that the instance name begins with a valid SIP URI is that having a SIP URI available in the name makes the service advertisement contain sufficient information for a UA to initiate a call. The UA resolves the service instance name and obtains the IP address and the port number. (This is done by issuing an SRV query. See Section 5, [I-D.cheshire-dnsext-dns-sd].) Then it can send a SIP request using the SIP URI from the service name as the Request-URI. This makes the information from the TXT record (described in the next section) optional, in accordance with the recommendation that the TXT record should be viewed as a performance optimization (Section 6.2, [I-D.cheshire-dnsext-dns-sd]). The SIP or SIPS URI in the service instance name SHOULD be an Address-of-Record (AOR). It is conceivable that a UA may not be configured with an AOR. A group of UAs in an ad-hoc network may be configured only with user names, for example. In such cases, the UA host names or IP addresses may be used to form a valid SIP URI for service advertisement. 4.2. TXT Record Attributes In addition to the service instance name, IP address and the port number, DNS-SD provides a way to publish other information pertinent to the service being advertised. The additional data can be stored as name/value attributes in a TXT record with the same name as the SRV record for the service. Each name/value pair within the TXT record is preceded by a single length byte, thereby limiting the length of the pair to 255 bytes. (See Section 6 of [I-D.cheshire-dnsext-dns-sd] and Section 3.3.14 of [RFC1035] for detail.) Lee, et al. Expires November 8, 2007 [Page 8] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 The following subsections describe the attributes defined for the SIP URI service. Note that, while the presence of any of these attributes in a SIP URI advertisement is optional, the presence of certain attributes affects the behavior of the UA processing the service instance. (See Section 5 for detail.) 4.2.1. txtvers This is the version number of the TXT record specification as recommended in Section 6.7, [I-D.cheshire-dnsext-dns-sd]. If present, this attribute MUST be the first name/value pair in the TXT record. For this specification, it MUST be "txtvers=1". 4.2.2. name This is the display name of the user. For example, "name=John Doe". It MUST conform to the "display-name" ABNF element in Section 25.1, [RFC3261], so that it can be used in the "To" SIP header, as in "To: John Doe ". 4.2.3. contact This attribute contains a SIP or SIPS URI that represents a direct route to the user. The URI usually contains a fully qualified domain name (FQDN) or an IP address indicating the physical contact location of the user. For example, "contact=sip:carol@cube2214a.chicago.com". Note that, while this attribute is the same in semantics as the "Contact" SIP header, the attribute does not allow the full syntax of the SIP header. First, only SIP or SIPS URIs are allowed in the attribute, whereas non-SIP URIs are allowed in the Contact header. Non-SIP URIs are not applicable in the SIP URI service discovery. Second, the attribute can contain only a single URI, whereas the Contact header can contain multiple URIs in a comma-separated list. We argue that multiple contact locations can (and should) be advertised as multiple service instances. [RFC3261] also defines two Contact parameters "q" and "expires". The "q" parameter is only applicable when there are multiple Contact locations. The "expires" parameter is also not relevant in this environment since the service instance must be created and removed according to the rules of the underlying service discovery system. The attribute name/value pair has the following syntax ABNF: Lee, et al. Expires November 8, 2007 [Page 9] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 contact-attr = "contact=" ( name-addr / uri ) *( SEMI contact-extension ) name-addr = [ display-name ] LAQUOT uri RAQUOT uri = SIP-URI / SIPS-URI SEMI, LAQUOT and RAQUOT denote ";", "<" and ">", respectively. Note that whitespace is often allowed around these characters. The contact attribute value has nearly the same syntax as the "contact- param" element in Section 25.1 of [RFC3261]. The difference is that the contact attribute syntax disallows non-SIP URIs and it omits the "q" and "expires" parameters. See Section 25.1 of [RFC3261] for the other syntax elements that are not expanded here, such as contact- extension and display-name. Also see Section 20.10 and the last paragraph of Section 20 of [RFC3261] for the important information regarding the Contact header parsing rules, which are equally applicable to the contact attribute. The attribute syntax allows one or more contact-extension elements, which are generic name/value parameter provisions for future extensions. Currently, [RFC3840] defines a mechanism by which SIP UAs can exchange information about their capabilities and characteristics through these parameters. Such a mechanism is particularly germane to service discovery. Lee, et al. Expires November 8, 2007 [Page 10] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 5. User Agent Client Behavior This section specifies the behavior of the UA that sends a SIP request using the discovered SIP URI service instance. In particular, it specifies how to form the Request-URI and the "To" header of the request, and how to determine the destination host to which the SIP request should be transported. Beyond that, Section 8.1 and 18.1 of [RFC3261] describe in detail the behavior of a UA generating and sending a SIP request. 5.1. Forming Request The "To" header MUST be formed using the SIP or SIPS URI from the service instance name. The URI is either the first DNS label of the service instance name if it contains no space, or the longest prefix in the first DNS label that does not include the first space character. (See Section 4.1.) If the "name" attribute of the TXT record is available, it MAY be used as the "display-name" in the "To" header according to the formatting rules outlined in Section 20.10 of [RFC3261]. The Request-URI MUST be formed using the SIP or SIPS URI from the "contact" attribute of the TXT record. If the "contact" attribute is not available, the Request-URI MUST be set to the same value as the "To" header. 5.2. Sending Request If the "contact" attribute of the TXT record is available, the host part MUST be taken as the destination host to which to send the request. For example, if the TXT record contains "contact=sip:carol@cube2214a.chicago.com", the request must be sent to cube2214a.chicago.com. If the "contact" attribute is not available, the UA MUST resolve the service instance name to obtain the host name and port number to which to send the request. The resolution is done by sending an SRV query or by calling the equivalent API routine in the DNS-SD library implementation (Section 5, [I-D.cheshire-dnsext-dns-sd]). The host name obtained either from the "contact" attribute or by resolving the service instance name can then be looked up using A/AAAA query to determine the target IP address. Note that no further resolution is performed on the host name extracted from the SIP URI in the "contact" attribute. This is in contrast with [RFC3263], which requires additional steps using NAPTR and SRV lookups in resolving a SIP URI. The additional flexibility provided Lee, et al. Expires November 8, 2007 [Page 11] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 by [RFC3263] is of limited value in the usual serverless setting of DNS-SD/mDNS, so it was deemed not a strong enough reason to deviate from the normal DNS-SD convention. Lee, et al. Expires November 8, 2007 [Page 12] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 6. User Interface Guidelines This section considers the user interface of a UA that implements the behavior specified in Section 5. As a model for our discussion, let us consider a typical graphical UA that presents three user interface elements: an address book window containing the AORs manually maintained by the human user, another window listing the SIP URIs currently available through DNS-SD, and a text edit box in which the user can directly type in a URI not listed in either window. The address book entries and the DNS-SD entries SHOULD be presented in a way that makes it clear to the user that they are two separate lists. When the user selects an entry from the DNS-SD list, the UA MUST follow the behavior outlined in Section 5. When the user selects an entry from the address book window, the UA MUST follow the normal user agent client behavior specified in Section 8.1 of [RFC3261]. This means that the SIP request is routed either using a configured outbound proxy or using the SIP server location mechanisms described in [RFC3263]. If such an effort fails, due to a network outage or a server failure for example, and there is a DNS-SD entry with the same URI as the address book entry that the user has selected, then (and only then) the UA MAY try the DNS-SD entry with the same URI, following the behavior in Section 5. In this case, the address book entry might indicate that the URI is also being announced via DNS-SD advertisement. The reason for requiring that the UA first follows the server mechanisms when processing an address book entry is discussed in Section 9. A URI directly typed in by the user MUST be processed as if it has been selected from the address book window. Lee, et al. Expires November 8, 2007 [Page 13] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 7. Other Related Mechanisms 7.1. SIP Multicast The previous SIP specification [RFC2543] included sending INVITE requests via multicast. The intended purpose was to provide the mechanism where a UA can send an INVITE message to a logical entity comprised of multiple hosts serving a single function such as a help desk. Due to the complexity of the mechanism, the multicast INVITE has been removed from the current specification. Currently the use of multicast is limited to "single-hop-discovery-like" services such as registrations. (Section 10.2.6 and 18.1.1, [RFC3261]) Multicast REGISTER requests provide another way to discover peer locations. The UAs would send the REGISTER requests to the SIP multicast address (sip.mcast.net or 224.0.1.75). They would also listen to that address and keep a local database of peer locations as they encounter REGISTER requests. This may seem similar to the SIP URI advertisement using DNS-SD/mDNS as described in this document. The most important difference is that the multicast REGISTER method provides passive discovery only. Unlike in the DNS-SD/mDNS environment where a UA can simply make a query, in the multicast REGISTER setting a newly arriving UA would not discover the existing UAs until their registrations are refreshed, which could introduce up to an hour delay even if we assume no packet loss. This makes multicast REGISTER unsuitable for high-churn environments such as wireless ad-hoc networks. 7.2. "sip" DNS-SD Service Type There is another DNS-SD service type related to SIP. The "sip" service type is primarily used for server advertisements. Most notably, it is used by Asterisk, a popular open-source software system for IP PBX (). In contrast, "sipuri" service type described in this document is intended for user agent advertisements. Some UA implementations are currently using the "sip" service type for user agent advertisements. This is not ideal because the TXT attributes defined for "sip" type is geared towards server announcements. This leads the UAs to use the "sip" type for its name only. For example, Ekiga softphone () uses it, but introduces a number of TXT attributes not defined for the "sip" type. We encourage the UA implementations to use the "sipuri" service type for user agent advertisements. Lee, et al. Expires November 8, 2007 [Page 14] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 7.3. Peer-to-Peer SIP The IETF Peer-to-peer SIP (P2PSIP) working group has been formed recently. The working group's goal is to develop protocols and mechanisms to replace or augment the centralized SIP servers with the services provided by the peer-to-peer network of SIP endpoints. This may seem similar to the DNS-SD/mDNS setting considered in this document. The difference is that, while DNS-SD/mDNS is primarily for local area networks, P2PSIP is concerned with the peer-to-peer overlays of SIP endpoints spanning the globe. In fact, its charter () specifically excludes multicast and dynamic DNS based approaches from the scope of its work. Lee, et al. Expires November 8, 2007 [Page 15] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 8. Transport Protocol in Service Instance Name Section 7 of [I-D.cheshire-dnsext-dns-sd] states: The "_tcp" or "_udp" should be regarded as little more than boilerplate text, and care should be taken not to attach too much importance to it. Some might argue that the "_tcp" or "_udp" should not be there at all, but this format is defined by RFC 2782, and that's not going to change. In addition, the presence of "_tcp" has the useful side-effect that it provides a convenient delegation point to hand off responsibility for service discovery to a different DNS server, if so desired. The web site for DNS-SD service type registration (see Section 10) goes further and says: Protocols that can run over either UDP or TCP (e.g. NFS) are usually advertised using whichever transport is considered the 'normal' or 'primary' mode of operation (and clients should attempt communication with the service using either or both transports, as appropriate for the client). This interpretation and policy are reasonable for those application protocols that have clear "primary" transport protocols, but they present difficulty in a protocol such as SIP that supports multiple transports without favoring any particular one. [RFC3263] specifies how NAPTR and SRV records are used to resolve a SIP URI into the IP address, port, and transport protocol of the request destination. The transport label in the SRV record ("_udp", "_tcp", or "_sctp") plays an important role in determining which transport protocol should be used. It would be inconsistent and confusing for a SIP UA to interpret the transport labels in SRV records differently depending on whether it is processing a DNS-SD service or not. This document follows the conventional SRV record interpretation that treats the transport label as indicating the desired transport protocol (Section 4.1). We believe the DNS-SD interpretation is an oversight and hope to see a change in the subsequent iterations of [I-D.cheshire-dnsext-dns-sd]. Lee, et al. Expires November 8, 2007 [Page 16] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 9. Security Considerations In DNS-SD/mDNS environment, there is no restriction on who can advertise what services. An attacker who has gained access to a local area network, such as an unsecured wireless network, can impersonate any SIP URI simply by advertising it using DNS-SD. At a minimum, a UA must be careful to present the URIs discovered through DNS-SD in a way clearly distinguishable from the ones in the user's address book. The discovered URIs and the address book entries SHOULD be presented to the user in two separate lists. Moreover, the DNS-SD entries can use the display names rather than the advertised URIs in order to further indicate the fact that the URIs are not authenticated in any way. This security concern underlies the user interface guidelines in Section 6. When it is important to verify the authenticity of the advertised AORs, SIPS URIs should be used. Ideally a UA advertising a SIPS URI should authenticate itself using a certificate signed by a certificate authority (CA), but the burden of obtaining a CA-signed certificate may not be justifiable for a few SIP end-points communicating directly with each other in a local area network. In such cases, self-signed certificates can be used to obtain most of the security benefits provided by TLS without having to acquire a CA- signed certificate. A self-signed certificate provides no authentication when the connection is made for the first time. The UA SHOULD present a clear warning to the user indicating that the SIPS URI that the user wants to contact is using a self-signed certificate, therefore it is unauthenticated, and encouraging the user to verify the authenticity in some other way. Once the user has successfully made the first connection (perhaps after checking the authenticity by external means), the UA can store the self-signed certificate in its local database so that all the subsequent connections can be authenticated by comparing the certificate being presented to the one stored in the local database. The usefulness of this mechanism is clearly demonstrated by the widespread adoption of SSH, which uses essentially the same mechanism for authenticating the servers. (Section 4.1, [RFC4251]) Since this document is essentially a naming and usage convention within the framework of DNS-SD and mDNS, the security considerations for those systems apply here as well. [I-D.cheshire-dnsext-dns-sd] recommends the use of DNSSEC [RFC2535] when the authenticity of information is important. [I-D.cheshire-dnsext-multicastdns] suggests, among other things, IPSEC and/or DNSSEC signatures when it is desirable to distinguish a group of cooperating nodes from other (possibly) antagonistic ones operating on the same physical link. Lee, et al. Expires November 8, 2007 [Page 17] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 10. IANA Considerations Currently, DNS-SD service type names are not managed by IANA. Section 19 of [I-D.cheshire-dnsext-dns-sd] proposes an IANA allocation policy for unique application protocol or service type names. Until the proposal is adopted and in force, Section 19 points to for instruction on how to register a unique service type name for DNS-SD. The service type "sipuri" for the discovery method presented in this document has been registered according to that instruction. Lee, et al. Expires November 8, 2007 [Page 18] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 11. Normative References [I-D.cheshire-dnsext-dns-sd] Krochmal, M. and S. Cheshire, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-04 (work in progress), August 2006. [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-06 (work in progress), August 2006. [I-D.ietf-zeroconf-reqts] Hattig, M., "Requirements for Automatic Configuration of IP Hosts", draft-ietf-zeroconf-reqts-12 (work in progress), September 2002. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [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. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Lee, et al. Expires November 8, 2007 [Page 19] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. Lee, et al. Expires November 8, 2007 [Page 20] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 Authors' Addresses Jae Woo Lee Columbia University Dept. of Computer Science 1214 Amsterdam Avenue New York, NY 10027 US Email: jae@cs.columbia.edu Henning Schulzrinne Columbia University Dept. of Computer Science 1214 Amsterdam Avenue New York, NY 10027 US Email: schulzrinne@cs.columbia.edu Wolfgang Kellerer DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany Email: kellerer@docomolab-euro.com Zoran Despotovic DoCoMo Communications Laboratories Europe Landsberger Str. 312 Munich 80687 Germany Email: despotovic@docomolab-euro.com Lee, et al. Expires November 8, 2007 [Page 21] Internet-Draft SIP URI Service Discovery using DNS-SD May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 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. Intellectual Property The IETF takes no position regarding the validity or scope of any 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made 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 implementers or users of this specification can be obtained from the IETF 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 that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires November 8, 2007 [Page 22]