INTERNET-DRAFT Dusseault, Microsoft Expires Sept 1998 Mohr, Activerse Addressing and Location for RVP draft-dusseault-rvp-addr-00.txt Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract A core part of a presence and instant messaging protocol, such as RVP [7], must be the ability to find users online. This draft defines several aspects of finding a user online: - Schema of RVP URL - How to find a user’s RVP address (URL) - How to find a RVP server The problem may be generalized to finding a non-user object online. In this draft, the client is the process which is searching for a RVP object. This can be a RVP server acting as a client or on behalf of a user. The server is the process which is responsible for answering queries and receiving messages for a RVP object. A RVP client may sometimes act as its own server. 1. URLs RVP URLs are used in RVP requests and headers to indicate the originator and target of an RVP message, and to specify redirection addresses. Since the URL is only an address, an RVP message must also include headers to specify the action, properties, and other details of a request or a response. Dusseault & Mohr [Page 1] INTERNET-DRAFT RVP Addressing March 1998 The target of a RVP request is always a node in the RVP namespace. Nodes are identified by URL syntax. The URL is only used to identify a node, much as a HTTP URL identifies a directory or document. The URL follows the syntax for hierarchical schemes set out in RFC1738 [6]: rvp://:/ The scheme name is "rvp". The host component is used to resolve to the server or servers which is responsible for the node named in the path. The path is an identifier for a particular node in that server’s namespace. The path needs to be unique for that host, but not unique for all hosts. Note that the path may be literally the path to the node in a storage system, depending on the implementation, but this is not required of implementations. 1.2 URL Format RVP-URL = "rvp://" host [ ":" port ] "/" path host = defined in RFC 1738 port = *digit path = name | name "/" path name = alphanumeric atom Note that all URL reserved characters must be encoded. Examples of user URLs: rvp://rvp.widgets.com/users/juser rvp://rvp.widgets.com/users/engineering/username Examples of general-purpose node URLs: rvp://rvp.widgets.com/engineering/SDE rvp://rvp.widgets.com/engineering/SDE/announce rvp://rvp.widgets.com/engineering/SDE/discussion 1.3. Default URLs There are many cases where a user may have more than one RVP address. In these cases, a user may have multiple URLs. To make the case of multiple RVP addresses simpler for clients, the concept of the "default" address is introduced. A "default" address is one that the user has designated as the address that other users should use to send instant messages or find out if the user is online. The default URL should be marked as such in VCard or LDAP entries. 1.4 Identity URLs Dusseault & Mohr [Page 2] INTERNET-DRAFT RVP Addressing March 1998 The RVP URLs which users share are "identity URLs", which serve to both identify a person and provide the canonical location for reaching them. Internally, RVP also uses syntactically-equivalent "location URLs" to describe the endpoints of communication. However, such URLs are not useful or visible to end-users, and are hence not discussed further here. Identity URLs are used to initiate contact with others, identify the originator of communications, and qualify access-privileges for RVP objects. For the purposes of comparing two RVP identity URLs, to determine if they refer to the same RVP object, RVP applications must follow the rules set forth in Section 3.2.3 of the HTTP/1.1 specification. Fielding et. al. RFC 2068]. This implies that RVP applications... - MUST NOT treat case as significant in the 'scheme' or 'host' portions of an URL. - MUST treat case as significant in the 'url-path' portion of an URL, as per Section - MUST NOT consider hostnames which resolve to the same IP address as identical. - MUST NOT consider the presence or absence of a trailing "/" to be significant, if the 'url-path' portion is empty. - MUST NOT consider the explicit specification of the default port to be any different than implied specification of the default port. For example, the following RVP identity URLs are prima facie identical: rvp://rvp.widgets.com RVP://rvp.widgets.com rvp://RVP.widgets.COM rvp://rvp.widgets.com/ rvp://rvp.widgets.com:XXXX RVP://rvp.WIDgets.com:XXXX/ The following two URLs MUST NOT be assumed to represent the same identity: rvp://rvp.widgets.com/bill rvp://rvp.widgets.com/Bill Similarly, the following two URLs MUST NOT be assumed to represent the same identity, even if the current DNS resolution of "rvp.widgets.com" is "207.8.29.7": rvp://rvp.widgets.com/bill rvp://207.8.29.7/bill Dusseault & Mohr [Page 3] INTERNET-DRAFT RVP Addressing March 1998 If a particular RVP server wishes to adopt a policy of case- insensitivity or hostname-equivalence, it should choose a preferred identity URL representation for each RVP object hosted. Requests for that entity under acceptably-close "Subject" names MAY then generate "301-Moved Permanently" replies which include the preferred name. For example, a request for "rvp://207.8.29.7/BILL" might result in a 301 reply, with the new "Location" as "rvp://rvp.widgets.com/Bill". 2. Discovering RVP Addresses 2.1. Manual Transfer The simplest way to obtain these URLs is for a user to communicate the URLs using some out-of-band mechanism such as verbally, in an e- mail message, on a web page, or by printing these URLs on a paper business card. When using this mechanism, the user obtains these URLs using an out- of-band mechanism and enters these URLs into their client manually. Manual transfer is the typical way for non-user addresses to be discovered. 2.2. Personal Data Exchange Using A vCard A more sophisticated way to obtain user URLs is for users to publish vCards containing these URLs. The vCard object can be transferred between one another. Since many e-mail clients allow a user to automatically include a vCard with every message that the user sends, this provides a simple transparent way for a user to distribute their online presence URLs. On the receiving end, an e-mail client that provides an integrated vCard database can provide a way to lookup RVP URLs for users whose vCards are stored locally. 2.2.1. vCard Schema Extensions Since the vCard [1] specification doesn't specify how to encode RVP URLs in a vCard, this section is provided as an extension to vCard which specifies how to encode RVP URLs within a vCard. Inside a vCard object, a new property is defined: "RVPURL". Any vCard can have one or more of these properties, each representing a RVP URL that is associated with the user. One of these properties can be designated as the "default" by adding the "PREF" parameter. Here is a simple example of a vCard containing a "RVPURL". BEGIN:VCARD Dusseault & Mohr [Page 4] INTERNET-DRAFT RVP Addressing March 1998 VERSION:3.0 FN:Joe User N:User,Joe ORG:Microsoft Corporation ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA TEL;WORK;MSG:+1-206-936-2472 TEL;WORK;FAX:+1-206-936-7329 EMAIL;INTERNET:user@host1.com RVPURL;PREF:http://rvp.host1.com/user END:VCARD Next step is to register this property with IANA. 2.3. Directory Lookup Using The LDAP v3 Protocol Another way to obtain user URLs is to look them up in a directory using the LDAP protocol. If an user’s e-mail address or domain is known, then using DNS [4], the attendee’s directory server can be found. From the directory server, the client can look up the RVP URL. Here’s how it works: the client first parses the domain name from the rfc822 mailbox name. For the fictitious mailbox "joeuser@host1.com", the domain name would be "host1.com". Given the domain name, the client prepends "ldap.tcp" to the domain name and formulating a host. Next the client queries the DNS server for the SRV record for "ldap.tcp.host1.com". The mechanism for adding "ldap.tcp" onto the original domain name is described in detail in[3], [2]. The DNS server returns the IP address for the associated server for "ldap.tcp.host1.com". Once the IP address for the LDAP server has been obtained, the client obtains a list of possible search bases by querying the LDAP server with a NULL baseObject. The client iterates through each baseObject and queries the server for all entries where the attribute named "mail" [5] "equalityMatch"es the user’s email address. From the first matching entry, the client obtains the RVP URL. If a user’s RVP URL can be found using directory lookup, they should, in general, be considered "more up-to-date" than URLs in any vCards that are stored locally. 2.3.1. LDAP Schema Extensions In order to encode the RVP URLs in the directory, the following are defined: Dusseault & Mohr [Page 5] INTERNET-DRAFT RVP Addressing March 1998 one object class: @ RVPEntry and two attributes: @ RVPURL @ RVPOtherURLs The RVPURL attribute contains the user’s RVP URL. The RVPOtherURLs is a multi-valued property containing other RVP URLs that the user may have. There is no predetermined order to the values in a multi-valued property. TBD: Define precisely the RVPEntry object class and attributes. 3. Finding RVP Servers 3.1. DNS SRV Records RFC 2052 [2] recommends use of DNS SRV records to discover the responsible server for a service. Given the domain name, which can be parsed from the URL, the client prepends "rvp.tcp." or "rvp.udp." to the domain name. Next the client queries the DNS server for the SRV record for "rvp.tcp.host1.com". The mechanism for adding "rvp.tcp" onto the original domain name is described in detail in [3], [2]. The DNS server returns the IP address for the associated server for "rvp.tcp.host1.com". The RVP packet is sent to this server. DNS A records can be consulted if DNS SRV records are not present. There is some discussion of whether use of DNS SRV records pollutes the DNS namespace, but this issue is not well-understood yet. 3.2. Use Service Location Protocol The Service Location Protocol version 2.0 [8] is in development but may serve our needs in the future. A SLP URL for an RVP server could look like: Server:rvp://widgets.com However, SLP may not be useful on the internet and this bears more investigation. Dusseault & Mohr [Page 6] INTERNET-DRAFT RVP Addressing March 1998 Authors' Addresses Lisa Dusseault Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: lisadu@microsoft.com Fax: (425) 936-7329 Gordon Mohr Activerse, Inc. 1301 W. 25th St Suite 500 Austin, TX 78705 Email: gojomo@activerse.com Bibliography [1] Dawson F. and Howes T., 'vCard MIME Directory Profile', INTERNET-DRAFT , May 1998 [2] Gulbrandsen A. and Vixie P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, , October 1996. [3] Leach P., ‘Locating Native Internet LDAP Servers’, INTERNET DRAFT , March 1997 [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [5] Network Applications Consortium 'Lightweight Internet Person Schema', April 1997, [6] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource Locators (URL)", RFC 1738, Dec 1994. Dusseault & Mohr [Page 7] INTERNET-DRAFT RVP Addressing March 1998 [7] Calsyn M. and Dusseault L., "RVP: A Presence Information Protocol", INTERNET-DRAFT , March 1998. [8] Day M, Veizades J., Perkins C. and Guttman E. "Service Location Protocol", INTERNET-DRAFT , March 1998 Dusseault & Mohr [Page 8]