Internet DRAFT - draft-dusseault-rvp-addr
draft-dusseault-rvp-addr
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://<host>:<port>/<path>
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 <draft-ietf-asid-mime-vcard-04.txt>,
May 1998
[2] Gulbrandsen A. and Vixie P., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052,
<ftp://ds.internic.net/rfc/rfc2052.txt>, October 1996.
[3] Leach P., ‘Locating Native Internet LDAP Servers’,
INTERNET DRAFT <draft-leach-asid-ldap-locating-00.txt>,
March 1997
[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
<URL:ftp://ds.internic.net/rfc/rfc1035.txt>
[5] Network Applications Consortium 'Lightweight Internet Person
Schema', April 1997, <URL:http://www.netapps.org>
[6] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource
Locators (URL)", RFC 1738, Dec 1994. <URL:ftp://ftp.isi.edu/in-
notes/rfc1738.txt>
Dusseault & Mohr [Page 7]
INTERNET-DRAFT RVP Addressing March 1998
[7] Calsyn M. and Dusseault L., "RVP: A Presence Information
Protocol", INTERNET-DRAFT <draft-calsyn-rvp-01.txt>, March 1998.
[8] Day M, Veizades J., Perkins C. and Guttman E. "Service Location
Protocol", INTERNET-DRAFT <draft-ietf-svrloc-protocol-v2-03.txt>,
March 1998
Dusseault & Mohr [Page 8]
