draft-uls-1.txt Microsoft Corp February 1996 User Location Service Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table of Contents 1. Introduction 2. Elements of the User Location Service 3. User Location Protocol 4. Server Discovery 5. Transport Considerations 6. Security Considerations 7. References 8. Author's Address 1. Introduction This memo describes a proposed protocol for locating and connecting users together on an internet. In the last year, there has been an explosion in the number of client applications on the Internet that communicate directly with another client or clients. These applications include internet "telephones", video phones, whiteboards, and other conferencing applications. Each of these applications uses a proprietary or ad-hoc solution for providing a directory of currently connected users and performing name to address mapping. Expires September 1996 [Page 1] INTERNET-DRAFT USER LOCATION SERVICE February 1996 The User Location Service (ULS) provides a well-known location a client can use to: - Publish connection information, such as the transport address of an application. - Retrieve a directory of other users who are running compatible applications. - Connect to other users. 2. Elements of the User Location Service USER LOCATION SERVERS are server programs that maintain dynamic information about users and the applications they are running. The server is similar to a DNS server in that the set of resource information associated with a particular user is composed of separate resource records. The user location server differs from traditional directory services such as DNS in that: - Resource records are created by client applications rather than administered on the server. Records may change very rapidly as users connect and disconnect from the system. Due to the unreliable nature of the typical client application, records are expunged from the server if the client fails to refresh the message at a regular interval. - Records are tagged with both a name, application ID, and property ID to facilitate common directory queries. (for example: "find me all users who are running internet phone"). - The nature of the information stored on the server is more diverse than the information commonly found via DNS, since the records are used to describe user and application attributes as well as connection information. In this respect, the ULS is more similar to a white pages directory combined with a session announcement protocol than to DNS. USER LOCATION CLIENTS are programs that connect to user location servers. Clients can create, delete, modify, and query resource records on the server. The USER LOCATION PROTOCOL is the interface between a user location client and a user location server. Expires September 1996 [Page 2] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3. User Location Protocol 3.1 Resource Records Each resource record consists of a record label, a time-to-live (TTL) value, and the data to be stored in the record. The record label consists of a record name, a record type, a property ID and an application ID. The label identifies a record in the database. The record name is usually the user name in DNS format. The record type specifies the nature and format of the information in the record. The following initial record types are proposed. 1 Connection Address Specifies a network type, address type, and transport address. For example, an internet address could be type INTERNET, address type IP4 and transport address x.x.x.x.p 2 E-Mail Address Specifies an e-mail address for the user. 3 URL Specifies a Universal Resource Locator. 4 TXT Record is a text string. 5 Binary Record is binary data. 6 MIME Record is a MIME type. 0 Any Reserved. Used as wild card. The property ID identifies a specific global or application-specific property. Common properties will be assigned numbers. The application ID identifies the application that added the record. Expires September 1996 [Page 3] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3.2. Protocol Overview 3.2.1. Messages The User Location Protocol is the interface between a user location client and a user location server. All communications inside of the protocol are carried in a message format consisting of a header, followed by either a request or a reply. The header section is always present. The header includes fields that specify which of the remaining sections are present, whether the message is a request or a reply, and the type of request. Requests are either record queries, record modifications (addition and deletion), record refresh requests, or directory requests. The request section contains fields that describe the request. These fields are dependent on the type of the request. The reply section contains a possibly empty list of concatenated records or record labels that answer the request 3.2.2. Record Addition For a record addition request, the request contains one or more records. In reply to a record addition, the server will respond with a message containing only a message header to indicate whether the addition was successful. The update must be atomic, i.e. all records in the request must be added successfully or else no update will occur and an error will be returned. If a matching record label already exists when an addition request is received, the server should either fail the request or replace the existing record. The client application should use the TTL field of the record to indicate the maximum amount of time that the server should wait before automatically deleting the record. The client can use the refresh record request to reset the TTL field. The server may reject an addition or refresh request if the TTL value exceeds a maximum determined by the server, in which case the server should respond with a message containing a header with the "Refused" error code set. Expires September 1996 [Page 4] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3.2.3. Record Deletion For a record deletion request, the request contains the record label of the record to be deleted, i.e. a record name, a record type, a property ID, and an application ID. In reply to a deletion request, the server will respond with a message containing a message header to indicate whether the deletion was successful. The update must be atomic. A server should permit the use of the reserved record type "Any" coupled with an empty property ID to allow a client to delete all records belonging to a specific application (i.e. all records with the same record name and application ID) 3.2.4. Record Queries For a record query request, the request contains one or more record labels (usually one). The server will respond with a record query reply containing the records that match the query. 3.2.5. Directory Queries A directory query contains one or more record labels. The server will respond with a directory query reply containing the record labels of any records with a matching record type, application ID, and property ID. The record name field in the query is ignored. 3.2.6 Refresh Requests A refresh request consists of one or more record label and TTL field pairs. The TTL field is written into the matching resource record. If a refresh request is not received before the TTL field specified in a resource record expires, the record will be deleted. A server should permit the use of the reserved record type "Any" coupled with an empty property ID to allow a client to refresh all records belonging to a specific application (i.e. all records with the same record name and application ID). There is no server response to a refresh request unless no records with the matching label exist, in which case the server should respond with a message containing a header with the "No matching records" error code set. Expires September 1996 [Page 5] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3.3. Header Section Format The header contains the following fields: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR|TC| Z | Opcode | Retcode | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of request. This identifier is copied into the corresponding response and can be used by the requester to match up responses to outstanding responses. QR A one bit field that specifies whether this message is a query (0), or a response (1). TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. OPCODE A 4 bit field that specifies kind of request in this message. This value is set by the originator of an action and copied into the response. The values are: 0 record addition 1 record deletion 2 record query 3 directory query 4 refresh request Expires September 1996 [Page 6] INTERNET-DRAFT USER LOCATION SERVICE February 1996 RCODE Reply code - this 4 bit field is set as part of a reply. The values have the following interpretation: 0 No error condition 1 Format error - The server was unable to interpret the query. 2 Server failure - The server was unable to process this query due to a problem with the server. 3 Refused - The server refuses to perform the specified operation for policy reasons. For example, a server may not wish to provide the information to the particular requester, or a server may not wish to perform a particular operation. 4 No Matching Records - No records matching the request were found. Only used if the lack of matching records could indicate a server or client problem requiring the client to recreate its records. 5 Record Exists - A record could not be added to the database because a record with a matching record label already exists. QCOUNT An unsigned 16 bit integer specifying the number of entries in the request section. RCOUNT An unsigned 16 bit integer specifying the number of entries in the reply section. Expires September 1996 [Page 7] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3.3. Record Label Format The Record Label is used for all requests and has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / NAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PROPERTY ID | | | |--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | APPLICATION ID | | | | | | | | | | | | | |--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME A domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root. Note that this field may be an odd number of octets; no padding is used. TYPE A two octet code that specifies the type of the record. PROPERTY ID A 32-bit (four octet) ID used to identify a property associated with a name. APPLICATION ID A 128-bit ID (sixteen octet) used to identify the application that added the record. A null Application ID indicates that the property is not application specific. Expires September 1996 [Page 8] INTERNET-DRAFT USER LOCATION SERVICE February 1996 3.4. User Resource Record Format Each resource record has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / RECORD LABEL / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: RECORD LABEL A record label as specified above in section 3.3 is used. TTL Time-To-Live - A 32 bit unsigned integer that specifies the time interval (in seconds) before the record will expire. RDLENGTH An unsigned 16 bit integer that specifies the length in octets of the RDATA field. RDATA A variable length string of octets that describes the resource. The format of this information varies according to the TYPE of the resource record. 3.5. Size Limits Various objects and parameters in the protocol have size limits. They are listed below. Some could be easily changed, others are more fundamental. labels 63 octets or less names 255 octets or less TTL positive values of a signed 32 bit number. UDP messages 512 octets or less 4. Server Discovery The ULS is only responsible for handling name conflicts amongst the users that are currently registered with a specific server. The ULS intentionally does not provide its own hierarchial namespace solution, since this is already provided via DNS and other directory Expires September 1996 [Page 9] INTERNET-DRAFT USER LOCATION SERVICE February 1996 structures. For example, it is anticipated that ULS servers will be entered into the DNS database according to an agreed-upon type or name. Then, to find a user called "name@user-location-server," a client could locate the appropriate ULS server through DNS, since "user-location-server" would be a fully-qualified DNS name. If the domain for "user-location-server" did not sponsor its own ULS server, DNS could fall back to a default ULS. Upon learning the appropriate ULS server from DNS, the requesting client could query the ULS for the user's dynamic information, such as the user's IP address. 5. Transport Considerations Any ULS transaction may be carried in a UDP datagram, if the request fits, or in a TCP connection (at the discretion of the requester). When TCP is used, the message is prefixed with a two byte length field that gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it. The TCP socket number for ULS is to be determined. Servers should be prepared to receive, and respond to, multiple queries on a TCP connection. The server should only close its side of a TCP connection when it receives a close from the requester. Servers with limited system resources may close their side of a ULS TCP connection when necessary, at which time the requester should close its side and open a new connection when one is needed. If UDP is used, request replies will be sent back to the requester's source UDP port. ULS may also be implemented over protocols other than UDP or TCP. For example an HTTP encapsulation of ULS is possible. 6. Security Considerations To Be Discussed 7. References [RFC-1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC-1034, November 1987. [RFC-1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC-1035, November 1987. Expires September 1996 [Page 10] INTERNET-DRAFT USER LOCATION SERVICE February 1996 [DYNDNS] P. Vixie, S. Thomson, Y.Rekhter, J.Bound, "Dynamic Updates in the Domain Name System", February 1996, . 8. Author's Address Robert J. Williams Microsoft Corporation One Microsoft Way Redmond, WA 98052 +1 206 936 3666