One document matched: draft-williams-uls-00.txt
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,
<draft-ietf-dnsind-dynDNS-06.txt>.
8. Author's Address
Robert J. Williams
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
+1 206 936 3666
<robwi@microsoft.com>
| PAFTECH AB 2003-2026 | 2026-04-23 05:33:38 |