Heading:qjk40(635)\g Miscellaneous Servicesy756qjk40\g Page Numbers: Yes X: 527 Y: 10.5"qjk40\g Copyright Xerox Corporation 1979, 1980z18697l3033y45c(1270)\g Inter-Office Memorandumz18592l4445y762(635)\f5bg To Communication Protocols Date February 8, 1980 z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f1g2f0t2 1t0 23t6 1f1t0 4f0t7 1t0 From Ed Taft Location Palo Alto z18592l4445d2998e25\f1g4f0t2 1t0 7t6 1f1t0 8f0t7 1t0 Subject Miscellaneous Services Organization PARC/CSL (Edition 4)z18592l4445d2998e25\f1g7f0t2 1t0 22t6 1f1t0 12f0t7 1t0 XEROX z18592l508e14(2116)\f2g5f0 Filed on: MiscServices.bravoe30\g z18697l3033e10j(1270)\g A number of hosts, including Maxcs, Gateways, and IFSs, support a collection of simple, miscellaneous services. These services include only those functions that can be completed in a single exchange of Pups.z18697l3033e10j\g It is conceded that the organization of these services and the syntax of requests and responses is somewhat haphazard. This arrangement is due for a thorough overhaul. Most likely these services will be re-implemented on top of the Remote Procedure Call mechanism now under development.z18697l3033e10j\g This memo supercedes most of Pup Servers on Maxc'' of October 16, 1975. The other protocols mentioned therein (Telnet, Gateway Information, FTP, and Echo) are now described in separate documents.z18697l3033e10j\g143f1 3f0 Edition 2: Laurel-style Mail Check Request added.z18697l3033e10j\ig10I Edition 3: Address lookup request added.z18697l3033e10j\ig10I Edition 4: Validate Recipient request added, and Mail Check and Authenticate extended to include optional registry qualification.z18697l3033e10j\ig10I Generalz18697l3033e22jk80\bg7B A user requests one of these services by sending a Pup to socket 4 on a server system. The server performs the requested operation and generates a reply Pup. Since either the request or the reply could be lost, the user process must be prepared to retransmit the request if necessary, and the services provided must be of the sort that do not have incremental effects if requested repeatedly. Generally, these functions are simply requests for information.z18697l3033e10j\g The operation to be performed is determined by the Type field of the incoming Pup. In some cases, the reply is similarly distinguished by the Pup Type. In the following descriptions, the Pup Type assignments are given in octal. The Pup ID of the request may be selected arbitrarily by the user, and the Pup ID of the reply will match it. Users are advised to select Pup IDs in a manner that will enable them to distinguish between the replies to successive requests, if necessary.z18697l3033e10j\g239f1 2f0 69f1 2f0 62f1 2f0 Except where otherwise noted, a string is simply a packed array of bytes carried in the data portion of a Pup. A Pup carrying a string contains no other data.z18697l3033e10j\g32i6I Individual Servicesz18697l3033e22jk80\bg19B Date and Timez18697l3033e22jk80\ig13I The present date and time may be requested in one of four different formats. Not all servers necessarily support all four formats. The one that is universally supported by existing servers is the new GMT-based Alto time standard.z18697l3033e10j\g202f1 3f0 Pup Type: String time request = 200B Pup Contents: None.z18697l4303e10j\ig9I26f1 1f0 1i13I Pup Type: String time reply = 201B Pup Contents: A string consisting of the current date and time in the form 11-SEP-75 15:44:25''.z18697l4303e10j\ig9I24f1 1f0 1i13I68f1 3f0 Pup Type: Tenex time request = 202B Pup Contents: None.z18697l4303e10j\ig9I25f1 1f0 1i13I Pup Type: Tenex time reply = 203B Pup Contents: 6 bytes containing the date and time in Tenex internal format (see Tenex Jsys manual). The leftmost 18 bits (the date) are right-justified in the first 3 bytes (treating it as a 24-bit integer), and the rightmist 18 bits (the time) in the second 3 bytes. This standard is obsolete and should no longer be used.z18697l4303e10j\ig9I23f1 1f0 1i13I258i55I Pup Type: Alto time request (old standard) = 204B Pup Contents: None.z18697l4303e10j\ig9I39f1 1f0 1i13I Pup Type: Alto time response (old standard) = 205B Pup Contents: 4 bytes containing the date and time as a 32-bit number in Alto internal format, which is the number of seconds since midnight, January 1, 1901, local time. This standard is obsolete and is no longer supported.z18697l4303e10j\ig9I40f1 1f0 1i13I159i53I Pup Type: Alto time request (new standard) = 206B Pup Contents: None.z18697l4303e10j\ig9I39f1 1f0 1i13I Pup Type: Alto time response (new standard) = 207B Pup Contents: 10 bytes in all, organized as 5 16-bit words:z18697l4303e10j\ig9I40f1 1f0 1i13I words 0, 1 Present date and time: a 32-bit integer representing number of seconds since midnight, January 1, 1901, Greenwich Mean Time (GMT).z18697l8064d5573e10j(0,8064)(1,65535)(5,65535)(6,65535)\g136f1 3f0 word 2 Local time zone information. Bit 0 is zero if west of Greenwich and one if east. Bits 1-7 are the number of hours east or west of Greenwich. Bits 8-15 are an additional number of minutes. Most time zones are an integer number of hours from Greenwich, so the minutes field will ordinarily be zero.z18697l8064d5573e10j\g197f1 word 3 Day of the year on or before which Daylight Savings Time takes effect locally, where 1 = January 1 and 366 = December 31. (The actual day is the next preceding Sunday.) The correspondence between numbers and days is based on a leap-year.z18697l8064d5573e10j\g178f1 68f0 word 4 Day of the year on or before which Daylight Savings Time ends. If Daylight Savings Time is not observed locally, both the start and end dates should be 366.z18697l8064d5573e10j\g The local time parameters in words 2 through 4 are those in effect at the server's location. It is the user's responsibility to determine whether or not it is appropriate to apply them locally.z18697l4303e10j(1270)\g Mail Checkz18697l3033e22jk80\ig10I This service permits a user to check for the arrival of new mail relatively cheaply. For example, on Maxc the cost is at least an order of magnitude less than that for invoking the Mail Transfer Protocol. However, since the cost is not zero and there are potentially many simultaneous users of this service, programs that generate periodic mail check requests automatically should do so no more frequently than once every 5 minutes.z18697l3033e10j\g The Mail Check protocol has two variants, Msg-style and Laurel-style. The former returns the New mail exists'' reply only if the mailbox file has been written more recently than it was last read, whereas the latter requires only that the mailbox be non-empty.z18697l3033e10j\g42i9I5i12I Pup Type: Mail check request (Msg-style) = 210B Pup Contents: A string specifying the mailbox name.z18697l4303e10j\ig9I37f1 1f0 1i13I Pup Type: Mail check request (Laurel-style) = 214B Pup Contents: A string specifying the mailbox name.z18697l4303e10j\ig9I40f1 1f0 1i13I Pup Type: New mail exists reply = 211B Pup Contents: Optional human-readable text.z18697l4303e10j\ig9I28f1 1f0 1i13I Pup Type: No new mail exists reply = 212B Pup Contents: None.z18697l4303e10j\ig9I31f1 1f0 1i13I Pup Type: No such mailbox reply = 213B Pup Contents: A human-readable explanation.z18697l4303e10j\ig9I28f1 1f0 1i13I The mailbox name in the Mail Check request may optionally be qualified by a registry name, i.e., in the form simpleName.registry. If a registry name is present, the server should verify that it corresponds to a true mail registry (socket 7) on the same machine, and reject the request with a No Such Mailbox reply if the registry is improper.z18697l3033e10j\g109i19I Network Directory Lookupz18697l3033e22jk80\ig24I This service translates between inter-network name expressions and address values. See the memo Naming and Addressing Conventions for Pup'' for further information.z18697l3033e10j\g The data base for this service presently contains only host names (Altos and other machines) and is centrally maintained. This facility will eventually be replaced by a distributed Clearinghouse service that permits storing other types of information.z18697l3033e10j\g Pup Type: Name lookup request = 220B Pup Contents: A string consisting of an inter-network name expression.z18697l4303e10j\ig9I26f1 1f0 1i13I Pup Type: Name lookup response = 221B Pup Contents: One or more 6-byte blocks containing the address(es) corresponding to the name expression. Each block is a Pup Port structure, with the network and host numbers in the first two bytes and the socket number in the last four bytes.z18697l4303e10j\ig9I27f1 1f0 1i13I113i4I Pup Type: Address lookup request = 223B Pup Contents: A Port (6 bytes).z18697l4303e10j\ig9I29f1 1f0 1i13I Pup Type: Address lookup response = 224B Pup Contents: A string consisting of an inter-network name expression that matches the request Port. This service is not provided by all directory lookup servers at the present time.z18697l4303e10j\ig9I30f1 1f0 1i13I89i81I Pup Type: Directory lookup error reply = 222B Pup Contents: A human-readable explanation.z18697l4303e10j\ig9I35f1 1f0 1i13I Where is Userz18697l3033e22jk80\ig13I This is a Maxc-specific service that gives out information about jobs belonging to a particular user. This permits programs such as Chat to determine whether it is appropriate to attach to an existing job or log in a new one. IFS servers also implement a degenerate form of this protocol.z18697l3033e10j\g226f1 Pup Type: Where is user request = 230B Pup Contents: A string specifying the user name.z18697l4303e10j\ig9I28f1 1f0 1i13I Pup Type: Where is user response = 231B Pup Contents: Zero or more pairs of bytes designating jobs in the server machine belonging to the specified user. In each pair, the first byte is a Tenex job number and the second is a Tenex terminal number (377B indicates that the job is detached). By convention, job numbers are represented externally in decimal but terminal numbers in octal.z18697l4303e10j\ig9I29f1 1f0 1i13I199f1 1f0 39f1 Pup Type: Where is user error reply = 232B Pup Contents: A human-readable explanation.z18697l4303e10j\ig9I32f1 1f0 1i13I Network Directory Updatez18697l3033e22jk80\ig24I This service implements part of the Network Directory Update protocol, which is the means by which the centrally-maintained Network Directory data base is distributed to servers. The protocol is described fully in a separate document, Pup Network Directory Update Protocol''. Here we simply list the Miscellaneous Services Pup Types that are used:z18697l3033e10j\g Pup Type: Network directory version information = 240Bz18697l4303e10j\ig9I44f1 1f0 Pup Type: Network directory update request = 241Bz18697l4303e10j\ig9I39f1 1f0 Alto Boot and Boot Updatez18697l3033e22jk80\ig25I The protocols by means of which Altos are boot-loaded over the Ethernet and boot files are kept up-to-date are described in a separate document, Alto Boot Protocol''. Here we simply list the Miscellaneous Services Pup Types that are used:z18697l3033e10j\g Pup Type: Send boot file request = 244Bz18697l4303e10j\ig9I29f1 1f0 Pup Type: Boot directory request = 245Bz18697l4303e10j\ig9I29f1 1f0 Pup Type: Boot directory reply = 246Bz18697l4303e10j\ig9I27f1 1f0 User Authenticationz18697l3033e22jk80\ig19I This is a rudimentary authentication service that simply checks the validity of user name and password combinations on the server machine. It is somewhat specialized to the short-term needs of the Laurel system. It will be replaced eventually by a more secure authentication mechanism based on encryption.z18697l3033e10j\g Pup Type: Authenticate request = 250B Pup Contents: Two Mesa strings (more precisely, StringBodys), packed in such a way that the maxLength of the first string may be used to locate the second string. The first string is a user name and the second a password.z18697l4303e10j\ig9I27f1 1f0 1i13I35i10I34i9I Pup Type: Authenticate positive response = 251B Pup Contents: None. This response indicates that the name/password combination is valid.z18697l4303e10j\ig9I37f1 1f0 1i13I Pup Type: Authenticate negative response = 252B Pup Contents: A human-readable explanation.z18697l4303e10j\ig9I37f1 1f0 1i13I Note that only the Authenticate request contains Mesa strings. This is done because the normal convention for strings does not provide for packing multiple strings in one packet.z18697l3033e10j\g19i20I The user name in the Authenticate request may optionally be qualified by a registry name, i.e., in the form simpleName.registry. If a registry name is present, the server should verify that it corresponds to a true mail registry (socket 7) on the same machine, and reject the request with an Authenticate negative response if the registry is improper.z18697l3033e10j\g108i19I Validate Recipientz18697l3033e22jk80\ig18I This protocol is used to validate a recipient in a manner similar to what a mail server does with a Mailbox property, but using a single packet exchange. This is a temporary protocol, intended to facilitate coexistence of new and old Mail protocols.z18697l3033e10j\g Pup Type: Validate recipient request: 266B Pup Contents: a Mesa string containing a recipient name optionally qualified by .registry''. The registry, if present, is expected to be one actually located at the server.z18697l4303e10j\ig9I32f1 1f0 1i13I Pup Type: Validate recipient Yes reply: 267B Pup Contents: nonez18697l4303e10j\ig9I34f1 1f0 1i13I Pup Type: Validate recipient No reply: 270B Pup Contents: nonez18697l4303e10j\ig9I33f1 1f0 1i13I A Yes response means that the server would be willing to accept mail for that recipient, and a No response means that the server would reject mail for that recipient, or that the specified registry is not located at the server. If the server cannot conveniently determine whether or not it would accept mail for a recipient, it should answer Yes.z18697l3033e10j\g It is permissible for the server occasionally to reply Yes erroneously, but never to reply No erroneously. An erroneous Yes might result in the delivery of messages that would later be rejected and returned to the sender, but an erroneous No would altogether prevent delivery to a valid recipient.z18697l3033e10j\g Note: the principal intended client of this protocol is the new DMS mail server, which maintains a large local cache of validated recipient names. Hence Validate Recipient requests are expected to be dynamically infrequent except when a DMS mail server is restarting after a crash. This is important, since each such request incurs a full per-packet processing cost in addition to the cost of the validation operation itself. This is in contrast to the recipient validation portion of the Mail Transfer Protocol, where an entire recipient list is presented at once (in a single FTP command).z18697l3033e10j\g Implementation Statusz18697l3033e22jk80\bg21B The following table summarizes the services routinely available from server hosts at the present time.z18697l3033e10j\g Service Maxc Nova Alto IFS Gateway Gatewayz18697l4303e22jk50(0,10528)(1,12537)(2,14560)(3,16672)\ig7I Date and Time (String) X Date and Time (Tenex) X X Date and Time (old Alto) X Date and Time (new Alto) X X X X Mail Check X X Directory Name Lookup X X X X Directory Address Lookup X X Where is User X X Network Directory Update X X X X Alto Boot X X X Authenticate X X Validate Recipient X Xz18697l4303e10j\g