INTERNET-DRAFT                                    Dusseault, Microsoft
      Expires Sept 1998                                      Mohr, Activerse
                        Addressing and Location for RVP
       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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).
         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]:
         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:
         Examples of general-purpose node URLs:
      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
         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
         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
         The following two URLs MUST NOT be assumed to represent the same
         Similarly, the following two URLs MUST NOT be assumed to represent
         the same identity, even if the current DNS resolution of
         "" is "":
      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://" might result in a
         301 reply, with the new "Location" as "rvp://".
      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
      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".
      Dusseault & Mohr                                              [Page 4]

      INTERNET-DRAFT              RVP Addressing                  March 1998
         FN:Joe User
         ORG:Microsoft Corporation
         ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
         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
         "", the domain name would be "".
         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 "". 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 "".
         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
         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
      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
         "". 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
         "".  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:
         However, SLP may not be useful on the internet and this bears more
      Dusseault & Mohr                                              [Page 6]

      INTERNET-DRAFT              RVP Addressing                  March 1998
      Authors' Addresses
         Lisa Dusseault
         Microsoft Corporation
         One Microsoft Way
         Redmond, WA 98052
         Fax: (425) 936-7329
         Gordon Mohr
         Activerse, Inc.
         1301 W. 25th St
         Suite 500
         Austin, TX 78705
         [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,
            <>, 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.
         [5] Network Applications Consortium 'Lightweight Internet Person
            Schema', April 1997, <URL:>
         [6] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource
            Locators (URL)", RFC 1738, Dec 1994. <URL:
      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]