home *** CD-ROM | disk | FTP | other *** search
/ The Net: Ultimate Internet Guide / WWLCD1.ISO / pc / conf_sdk / conf_sdk.exe / ULSDRAFT.TXT < prev    next >
Encoding:
Text File  |  1996-04-29  |  21.1 KB  |  579 lines
  1. INTERNET-DRAFT                                               R. Williams
  2. draft-uls-1.txt                                           Microsoft Corp
  3.                                                            February 1996
  4.  
  5.                  
  6.                      User Location Service
  7.  
  8.  
  9. Status of this Memo
  10.  
  11. This document is an Internet-Draft.  Internet-Drafts are working doc-
  12. uments of the Internet Engineering Task Force (IETF), its areas, and
  13. its working groups.  Note that other groups may also distribute work-
  14. ing documents as Internet-Drafts.
  15.  
  16. Internet-Drafts are draft documents valid for a maximum of six months
  17. and may be updated, replaced, or obsoleted by other documents at any
  18. time.  It is inappropriate to use Internet-Drafts as reference mate-
  19. rial or to cite them other than as ``work in progress.''
  20.  
  21. To learn the current status of any Internet-Draft, please check the
  22. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  23. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  24. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  25. ftp.isi.edu (US West Coast).
  26.  
  27.  
  28. Table of Contents
  29.  
  30.  1. Introduction
  31.  2. Elements of the User Location Service
  32.  3. User Location Protocol 
  33.  4. Server Discovery
  34.  5. Transport Considerations
  35.  6. Security Considerations
  36.  7. References
  37.  8. Author's Address
  38.  
  39. 1. Introduction
  40.  
  41. This memo describes a proposed protocol for locating and connecting 
  42. users together on an internet.
  43.  
  44. In the last year, there has been an explosion in the number of client 
  45. applications on the Internet that communicate directly with another 
  46. client or clients. These applications include internet "telephones", 
  47. video phones, whiteboards, and other conferencing applications. Each of 
  48. these applications uses a proprietary or ad-hoc solution for providing a 
  49. directory of currently connected users and performing name to address 
  50. mapping. 
  51.  
  52. Expires September 1996                                          [Page 1]
  53.  
  54.  
  55. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  56.  
  57.  
  58. The User Location Service (ULS) provides a well-known location a client 
  59. can use to: 
  60.  
  61.     - Publish connection information, such as the transport address of 
  62.       an application.
  63.  
  64.     - Retrieve a directory of other users who are running compatible 
  65.       applications.
  66.  
  67.     - Connect to other users.
  68.  
  69.  
  70. 2. Elements of the User Location Service
  71.  
  72. USER LOCATION SERVERS are server programs that maintain dynamic 
  73. information about users and the applications they are running. The 
  74. server is similar to a DNS server in that the set of resource 
  75. information associated with a particular user is composed of separate
  76. resource records. 
  77.  
  78. The user location server differs from traditional directory services
  79. such as DNS in that: 
  80.  
  81.     - Resource records are created by client applications rather than 
  82.       administered on the server. Records may change very rapidly as 
  83.       users connect and disconnect from the system. Due to the 
  84.       unreliable nature of the typical client application, records are 
  85.       expunged from the server if the client fails to refresh the 
  86.       message at a regular interval.
  87.    
  88.     - Records are tagged with both a name, application ID, and property 
  89.       ID to facilitate common directory queries. (for example: "find me 
  90.       all users who are running internet phone"). 
  91.       
  92.     - The nature of the information stored on the server is more diverse
  93.       than the information commonly found via DNS, since the records are
  94.       used to describe user and application attributes as well as 
  95.       connection information. In this respect, the ULS is more similar
  96.       to a white pages directory combined with a session announcement
  97.       protocol than to DNS.
  98.  
  99. USER LOCATION CLIENTS are programs that connect to user location 
  100. servers. Clients can create, delete, modify, and query resource records 
  101. on the server.
  102.  
  103. The USER LOCATION PROTOCOL is the interface between a user location 
  104. client and a user location server.
  105.  
  106. Expires September 1996                                          [Page 2]
  107.  
  108.  
  109. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  110.  
  111.  
  112. 3. User Location Protocol 
  113.  
  114. 3.1 Resource Records
  115.  
  116. Each resource record consists of a record label, a time-to-live (TTL) 
  117. value, and the data to be stored in the record. 
  118.  
  119. The record label consists of a record name, a record type, a property
  120. ID and an application ID. The label identifies a record in the database.
  121.  
  122. The record name is usually the user name in DNS format.
  123.  
  124. The record type specifies the nature and format of the information 
  125. in the record.
  126.  
  127. The following initial record types are proposed. 
  128.  
  129.   1     Connection Address  Specifies a network type, address type, and 
  130.                             transport address. For example, an internet 
  131.                             address could be type INTERNET, address type
  132.                             IP4 and transport address x.x.x.x.p
  133.                       
  134.   2     E-Mail Address      Specifies an e-mail address for the user. 
  135.   
  136.   3     URL                 Specifies a Universal Resource Locator.
  137.   
  138.   4     TXT                 Record is a text string.
  139.  
  140.   5     Binary              Record is binary data.
  141.   
  142.   6     MIME                Record is a MIME type. 
  143.  
  144.   0     Any                 Reserved.  Used as wild card.
  145.   
  146. The property ID identifies a specific global or application-specific 
  147. property. Common properties will be assigned numbers.
  148.  
  149. The application ID identifies the application that added the 
  150. record. 
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160. Expires September 1996                                          [Page 3]
  161.  
  162.  
  163. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  164.  
  165.  
  166. 3.2. Protocol Overview
  167.  
  168. 3.2.1. Messages
  169.  
  170. The User Location Protocol is the interface between a user location 
  171. client and a user location server. All communications inside of the 
  172. protocol are carried in a message format consisting of a header, 
  173. followed by either a request or a reply. 
  174.  
  175. The header section is always present.  The header includes fields that
  176. specify which of the remaining sections are present, whether the message
  177. is a request or a reply, and the type of request.  Requests are either
  178. record queries, record modifications (addition and deletion), record 
  179. refresh requests, or directory requests. 
  180.  
  181. The request section contains fields that describe the request.  These
  182. fields are dependent on the type of the request. 
  183.  
  184. The reply section contains a possibly empty list of concatenated 
  185. records or record labels that answer the request
  186.  
  187. 3.2.2. Record Addition
  188.  
  189. For a record addition request, the request contains one or more 
  190. records.
  191.  
  192. In reply to a record addition, the server will respond with a message
  193. containing only a message header to indicate whether the addition was
  194. successful. The update must be atomic, i.e. all records in the request
  195. must be added successfully or else no update will occur and an error 
  196. will be returned.
  197.  
  198. If a matching record label already exists when an addition request is 
  199. received, the server should either fail the request or replace the 
  200. existing record.
  201.  
  202. The client application should use the TTL field of the record to 
  203. indicate the maximum amount of time that the server should wait 
  204. before automatically deleting the record. The client can use the 
  205. refresh record request to reset the TTL field.  The server may 
  206. reject an addition or refresh request if the TTL value exceeds a 
  207. maximum determined by the server, in which case the server should 
  208. respond with a message containing a header with the "Refused" error 
  209. code set.
  210.  
  211.  
  212.  
  213.  
  214. Expires September 1996                                          [Page 4]
  215.  
  216.  
  217. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  218.  
  219.  
  220. 3.2.3. Record Deletion
  221.  
  222. For a record deletion request, the request contains the record label
  223. of the record to be deleted, i.e. a record name, a record type, a 
  224. property ID, and an application ID.
  225.  
  226. In reply to a deletion request, the server will respond with a
  227. message containing a message header to indicate whether the deletion
  228. was successful. The update must be atomic.
  229.  
  230. A server should permit the use of the reserved record type "Any"
  231. coupled with an empty property ID to allow a client to delete all 
  232. records belonging to a specific application (i.e. all records with 
  233. the same record name and application ID)
  234.  
  235. 3.2.4. Record Queries
  236.  
  237. For a record query request, the request contains one or more record 
  238. labels (usually one). The server will respond with a record query 
  239. reply containing the records that match the query. 
  240.  
  241. 3.2.5. Directory Queries
  242.  
  243. A directory query contains one or more record labels. The server will 
  244. respond with a directory query reply containing the record labels of 
  245. any records with a matching record type, application ID, and property 
  246. ID. The record name field in the query is ignored.
  247.  
  248. 3.2.6 Refresh Requests
  249.  
  250. A refresh request consists of one or more record label and TTL field 
  251. pairs. The TTL field is written into the matching resource record. If 
  252. a refresh request is not received before the TTL field specified in a 
  253. resource record expires, the record will be deleted. 
  254.  
  255. A server should permit the use of the reserved record type "Any"
  256. coupled with an empty property ID to allow a client to refresh all 
  257. records belonging to a specific application (i.e. all records with 
  258. the same record name and application ID).
  259.  
  260. There is no server response to a refresh request unless no records 
  261. with the matching label exist, in which case the server should 
  262. respond with a message containing a header with the "No matching 
  263. records" error code set.
  264.  
  265.  
  266.  
  267.  
  268. Expires September 1996                                          [Page 5]
  269.  
  270.  
  271. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  272.  
  273.  
  274. 3.3. Header Section Format
  275.  
  276. The header contains the following fields:
  277.  
  278.                                     1  1  1  1  1  1
  279.       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  280.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  281.     |                      ID                       |
  282.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  283.     |QR|TC|      Z          |  Opcode   | Retcode   |
  284.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  285.     |                    QCOUNT                     |
  286.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  287.     |                    RCOUNT                     |
  288.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  289.  
  290. where:
  291.  
  292. ID              A 16 bit identifier assigned by the program that
  293.                 generates any kind of request.  This identifier is
  294.                 copied into the corresponding response and can be
  295.                 used by the requester to match up responses to
  296.                 outstanding responses.
  297.  
  298. QR              A one bit field that specifies whether this message 
  299.                 is a query (0), or a response (1).
  300.  
  301. TC              TrunCation - specifies that this message was truncated
  302.                 due to length greater than that permitted on the
  303.                 transmission channel.
  304.  
  305. OPCODE          A 4 bit field that specifies kind of request in
  306.                 this message.  This value is set by the originator of 
  307.                 an action and copied into the response.  The values 
  308.                 are:
  309.  
  310.                 0               record addition 
  311.                 
  312.                 1               record deletion 
  313.                 
  314.                 2               record query 
  315.                 
  316.                 3               directory query
  317.                 
  318.                 4               refresh request
  319.                 
  320.  
  321.  
  322. Expires September 1996                                          [Page 6]
  323.  
  324.  
  325. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  326.  
  327.  
  328. RCODE           Reply code - this 4 bit field is set as part of a
  329.                 reply.  The values have the following
  330.                 interpretation:
  331.                 
  332.                 0               No error condition
  333.  
  334.                 1               Format error - The server was
  335.                                 unable to interpret the query.
  336.  
  337.                 2               Server failure - The server was
  338.                                 unable to process this query due to a
  339.                                 problem with the server.
  340.  
  341.                 3               Refused - The server refuses to
  342.                                 perform the specified operation for
  343.                                 policy reasons.  For example, a 
  344.                                 server may not wish to provide the
  345.                                 information to the particular requester,
  346.                                 or a server may not wish to perform
  347.                                 a particular operation.
  348.                                 
  349.                 4               No Matching Records - No records 
  350.                                 matching the request were found. Only 
  351.                                 used if the lack of matching records 
  352.                                 could indicate a server or client 
  353.                                 problem requiring the client to recreate
  354.                                 its records.
  355.                                 
  356.                 5               Record Exists - A record could not be 
  357.                                 added to the database because a record 
  358.                                 with a matching record label already 
  359.                                 exists.                           
  360.                                 
  361. QCOUNT          An unsigned 16 bit integer specifying the number of
  362.                 entries in the request section.
  363.  
  364. RCOUNT          An unsigned 16 bit integer specifying the number of
  365.                 entries in the reply section.
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376. Expires September 1996                                          [Page 7]
  377.  
  378.  
  379. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  380.  
  381.  
  382. 3.3. Record Label Format
  383.  
  384. The Record Label is used for all requests and has the following format:
  385.  
  386.                                     1  1  1  1  1  1
  387.       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  388.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  389.     |                                               |
  390.     /                      NAME                     /
  391.     /                                               /
  392.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  393.     |                      TYPE                     |
  394.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  395.     |                   PROPERTY ID                 |
  396.     |                                               |
  397.     |--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  398.     |                                               |
  399.     |                  APPLICATION ID               |
  400.     |                                               |
  401.     |                                               |
  402.     |                                               |
  403.     |                                               |
  404.     |                                               |
  405.     |                                               |
  406.     |--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  407.                                                     
  408.  
  409. where:
  410.  
  411. NAME            A domain name represented as a sequence of labels, where
  412.                 each label consists of a length octet followed by that
  413.                 number of octets.  The domain name terminates with the
  414.                 zero length octet for the null label of the root.  Note
  415.                 that this field may be an odd number of octets; no
  416.                 padding is used.
  417.                   
  418. TYPE            A two octet code that specifies the type of the
  419.                 record. 
  420.  
  421. PROPERTY ID     A 32-bit (four octet) ID used to identify a property 
  422.                 associated with a name. 
  423.                 
  424. APPLICATION ID  A 128-bit ID (sixteen octet) used to identify the 
  425.                 application that added the record. A null Application ID 
  426.                 indicates that the property is not application specific.
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440. Expires September 1996                                          [Page 8]
  441.  
  442.  
  443. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  444.  
  445.  
  446. 3.4. User Resource Record Format
  447.  
  448. Each resource record has the following format:
  449.  
  450.                                     1  1  1  1  1  1
  451.       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  452.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  453.     |                                               |
  454.     /                                               /
  455.     /                  RECORD LABEL                 /
  456.     |                                               |
  457.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  458.     |                      TTL                      |
  459.     |                                               |
  460.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  461.     |                   RDLENGTH                    |
  462.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
  463.     /                     RDATA                     /
  464.     /                                               /
  465.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  466.  
  467. where:
  468.  
  469. RECORD LABEL    A record label as specified above in section 3.3 
  470.                 is used.
  471.  
  472. TTL             Time-To-Live - A 32 bit unsigned integer that 
  473.                 specifies the time interval (in seconds) before 
  474.                 the record will expire.
  475.  
  476. RDLENGTH        An unsigned 16 bit integer that specifies the length in
  477.                 octets of the RDATA field.
  478.  
  479. RDATA           A variable length string of octets that describes the
  480.                 resource.  The format of this information varies
  481.                 according to the TYPE  of the resource record.
  482.  
  483. 3.5. Size Limits
  484.  
  485. Various objects and parameters in the protocol have size limits.  They 
  486. are listed below.  Some could be easily changed, others are more
  487. fundamental.
  488.  
  489. labels          63 octets or less
  490.  
  491. names           255 octets or less
  492.  
  493. TTL             positive values of a signed 32 bit number.
  494.  
  495. UDP messages    512 octets or less
  496.  
  497.  
  498. 4. Server Discovery 
  499.  
  500. The ULS is only responsible for handling name conflicts amongst the 
  501. users that are currently registered with a specific server. 
  502.  
  503. The ULS intentionally does not provide its own hierarchial namespace 
  504. solution, since this is already provided via DNS and other directory 
  505.  
  506. Expires September 1996                                          [Page 9]
  507.  
  508.  
  509. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  510.  
  511.  
  512. structures. For example, it is anticipated that ULS servers will be 
  513. entered into the DNS database according to an agreed-upon type or 
  514. name. Then, to find a user called "name@user-location-server," a
  515. client could locate the appropriate ULS server through DNS, since 
  516. "user-location-server" would be a fully-qualified DNS name.  If 
  517. the domain for "user-location-server" did not sponsor its own ULS 
  518. server, DNS could fall back to a default ULS.  Upon learning the 
  519. appropriate ULS server from DNS, the requesting client could query 
  520. the ULS for the user's dynamic information, such as the user's IP 
  521. address.
  522.  
  523.  
  524. 5. Transport Considerations
  525.  
  526. Any ULS transaction may be carried in a UDP datagram, if the request
  527. fits, or in a TCP connection (at the discretion of the requester). 
  528. When TCP is used, the message is prefixed with a two byte length field 
  529. that gives the message length, excluding the two byte length field.  
  530. This length field allows the low-level processing to assemble a 
  531. complete message before beginning to parse it. The TCP socket number for 
  532. ULS is to be determined.
  533.  
  534. Servers should be prepared to receive, and respond to, multiple queries 
  535. on a TCP connection.  The server should only close its side of a TCP 
  536. connection when it receives a close from the requester.  Servers with 
  537. limited system resources may close their side of a ULS TCP connection 
  538. when necessary, at which time the requester should close its side and 
  539. open a new connection when one is needed.
  540.  
  541. If UDP is used, request replies will be sent back to the requester's 
  542. source UDP port.
  543.  
  544. ULS may also be implemented over protocols other than UDP or TCP. For 
  545. example an HTTP encapsulation of ULS is possible. 
  546.  
  547. 6. Security Considerations
  548.  
  549. To Be Discussed
  550.  
  551.  
  552. 7. References
  553.  
  554. [RFC-1034]      P. Mockapetris, "Domain Names - Concepts and 
  555.                 Facilities", RFC-1034, November 1987.
  556.  
  557. [RFC-1035]      P. Mockapetris, "Domain Names - Implementation and 
  558.                 Specification", RFC-1035, November 1987.
  559.   
  560. Expires September 1996                                         [Page 10]
  561.  
  562.  
  563. INTERNET-DRAFT                  USER LOCATION SERVICE      February 1996  
  564.  
  565.  
  566. [DYNDNS]        P. Vixie, S. Thomson, Y.Rekhter, J.Bound, "Dynamic 
  567.                 Updates in the Domain Name System", February 1996,
  568.                 <draft-ietf-dnsind-dynDNS-06.txt>.
  569.  
  570.  
  571. 8. Author's Address
  572.  
  573.        Robert J. Williams
  574.        Microsoft Corporation
  575.        One Microsoft Way
  576.        Redmond, WA 98052
  577.        +1 206 936 3666 
  578.        <robwi@microsoft.com>
  579.