Copyright Xerox Corporation 1979, 1980Inter-Office MemorandumToCommunication ProtocolsDateFebruary 8, 1980FromEd TaftLocationPalo AltoSubjectMiscellaneous ServicesOrganizationPARC/CSL(Edition 4)XEROX Filed on: MiscServices.bravoA 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 singleexchange of Pups.It is conceded that the organization of these services and the syntax of requests and responses issomewhat haphazard. This arrangement is due for a thorough overhaul. Most likely these serviceswill be re-implemented on top of the Remote Procedure Call mechanism now under development.This memo supercedes most of Pup Servers on Maxc'' of October 16, 1975. The other protocolsmentioned therein (Telnet, Gateway Information, FTP, and Echo) are now described in separatedocuments.Edition 2: Laurel-style Mail Check Request added.Edition 3: Address lookup request added.Edition 4: Validate Recipient request added, and Mail Check and Authenticate extended to includeoptional registry qualification.GeneralA user requests one of these services by sending a Pup to socket 4 on a server system. The serverperforms the requested operation and generates a reply Pup. Since either the request or the replycould be lost, the user process must be prepared to retransmit the request if necessary, and theservices provided must be of the sort that do not have incremental effects if requested repeatedly.Generally, these functions are simply requests for information.The operation to be performed is determined by the Type field of the incoming Pup. In somecases, the reply is similarly distinguished by the Pup Type. In the following descriptions, the PupType assignments are given in octal. The Pup ID of the request may be selected arbitrarily by theuser, and the Pup ID of the reply will match it. Users are advised to select Pup IDs in a manner thatwill enable them to distinguish between the replies to successive requests, if necessary.Except where otherwise noted, a string is simply a packed array of bytes carried in the data portionof a Pup. A Pup carrying a string contains no other data.npX&]g~qi cr]pX-r7Bp \r]p-r7Bp V!r]p-r 7Bp]T Osp I! C#4 BI42 @ =_ <\F ::! 7U 6orp) 4 2t p' /!t p , 7? RH 22 J.rp rp>rp BY ]tp" :?/d Miscellaneous Services2Individual ServicesDate and TimeThe present date and time may be requested in one of four different formats. Not all serversnecessarily support all four formats. The one that is universally supported by existing servers is thenew GMT-based Alto time standard.Pup Type: String time request = 200BPup Contents: None.Pup Type: String time reply = 201BPup Contents: A string consisting of the current date and time in the form 11-SEP-7515:44:25''.Pup Type: Tenex time request = 202BPup Contents: None.Pup Type: Tenex time reply = 203BPup Contents: 6 bytes containing the date and time in Tenex internal format (see Tenex Jsysmanual). The leftmost 18 bits (the date) are right-justified in the first 3 bytes (treating it asa 24-bit integer), and the rightmist 18 bits (the time) in the second 3 bytes. This standard isobsolete and should no longer be used.Pup Type: Alto time request (old standard) = 204BPup Contents: None.Pup Type: Alto time response (old standard) = 205BPup Contents: 4 bytes containing the date and time as a 32-bit number in Alto internalformat, which is the number of seconds since midnight, January 1, 1901, local time. Thisstandard is obsolete and is no longer supported.Pup Type: Alto time request (new standard) = 206BPup Contents: None.Pup Type: Alto time response (new standard) = 207BPup Contents: 10 bytes in all, organized as 5 16-bit words:words 0, 1Present date and time: a 32-bit integer representing number ofseconds since midnight, January 1, 1901, Greenwich Mean Time(GMT).word 2Local time zone information. Bit 0 is zero if west of Greenwichand one if east. Bits 1-7 are the number of hours east or west ofGreenwich. Bits 8-15 are an additional number of minutes. Mosttime zones are an integer number of hours from Greenwich, so the minutes fieldwill ordinarily be zero.word 3Day of the year on or before which Daylight Savings Time takeseffect locally, where 1 = January 1 and 366 = December 31. (Theactual day is the next preceding Sunday.) The correspondence betweennumbers and days is based on a leap-year.word 4Day of the year on or before which Daylight Savings Time ends. IfDaylight Savings Time is not observed locally, both the start andend dates should be 366.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 fpG bu ]t ZpL Y)B% WrpTtprSBRAuPt ?&= p'r;t p8tp(r7t p; 5 Ht4012p'r/t p,tp(r+Et p.(` &&2 %Xrp"s; ?k /r D p"1r)p0% 2* *V z >/](JMiscellaneous Services3locally.Mail CheckThis service permits a user to check for the arrival of new mail relatively cheaply. For example, onMaxc the cost is at least an order of magnitude less than that for invoking the Mail TransferProtocol. However, since the cost is not zero and there are potentially many simultaneous users ofthis service, programs that generate periodic mail check requests automatically should do so no morefrequently than once every 5 minutes.The Mail Check protocol has two variants, Msg-style and Laurel-style. The former returns the Newmail 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.Pup Type: Mail check request (Msg-style) = 210BPup Contents: A string specifying the mailbox name.Pup Type: Mail check request (Laurel-style) = 214BPup Contents: A string specifying the mailbox name.Pup Type: New mail exists reply = 211BPup Contents: Optional human-readable text.Pup Type: No new mail exists reply = 212BPup Contents: None.Pup Type: No such mailbox reply = 213BPup Contents: A human-readable explanation.The mailbox name in the Mail Check request may optionally be qualified by a registry name, i.e., inthe form simpleName.registry. If a registry name is present, the server should verify that itcorresponds to a true mail registry (socket 7) on the same machine, and reject the request with a NoSuch Mailbox reply if the registry is improper.Network Directory LookupThis service translates between inter-network name expressions and address values. See the memoNaming and Addressing Conventions for Pup'' for further information.The data base for this service presently contains only host names (Altos and other machines) and iscentrally maintained. This facility will eventually be replaced by a distributed Clearinghouse servicethat permits storing other types of information.Pup Type: Name lookup request = 220BPup Contents: A string consisting of an inter-network name expression.Pup Type: Name lookup response = 221BPup Contents: One or more 6-byte blocks containing the address(es) corresponding to thename expression. Each block is a Pup Port structure, with the network and host numbers inthe first two bytes and the socket number in the last four bytes.Pup Type: Address lookup request = 223BPup Contents: A Port (6 bytes).Pup Type: Address lookup response = 224BPup Contents: A string consisting of an inter-network name expression that matches therequest Port. This service is not provided by all directory lookup servers at the present time. fpGb ]t Zpe Y)4) W): V!d T% Q*tpt p P4P N?Ktp%rJGt p&Gbtp(rEt p&BtprAut p>tpr= t p:'tpr8t p 59* 4:tp? 2.6 12/ ,t )pW (=F %X` #g "P0ktprt p9tpr~t pF&tpvAtpr t p)tpr t p@ tQ 2 >/\2Miscellaneous Services4Pup Type: Directory lookup error reply = 222BPup Contents: A human-readable explanation.Where is UserThis 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 existingjob or log in a new one. IFS servers also implement a degenerate form of this protocol.Pup Type: Where is user request = 230BPup Contents: A string specifying the user name.Pup Type: Where is user response = 231BPup Contents: Zero or more pairs of bytes designating jobs in the server machine belongingto the specified user. In each pair, the first byte is a Tenex job number and the second is aTenex terminal number (377B indicates that the job is detached). By convention, job numbers arerepresented externally in decimal but terminal numbers in octal.Pup Type: Where is user error reply = 232BPup Contents: A human-readable explanation.Network Directory UpdateThis service implements part of the Network Directory Update protocol, which is the means bywhich the centrally-maintained Network Directory data base is distributed to servers. The protocolis described fully in a separate document, Pup Network Directory Update Protocol''. Here wesimply list the Miscellaneous Services Pup Types that are used:Pup Type: Network directory version information = 240BPup Type: Network directory update request = 241BAlto Boot and Boot UpdateThe protocols by means of which Altos are boot-loaded over the Ethernet and boot files are keptup-to-date are described in a separate document, Alto Boot Protocol''. Here we simply list theMiscellaneous Services Pup Types that are used:Pup Type: Send boot file request = 244BPup Type: Boot directory request = 245BPup Type: Boot directory reply = 246BUser AuthenticationThis is a rudimentary authentication service that simply checks the validity of user name andpassword combinations on the server machine. It is somewhat specialized to the short-term needs ofthe Laurel system. It will be replaced eventually by a more secure authentication mechanism basedon encryption.Pup Type: Authenticate request = 250BPup Contents: Two Mesa strings (more precisely, StringBodys), packed in such a way thatthe maxLength of the first string may be used to locate the second string. The first string isa user name and the second a password. fpGbtp#r`t p \t Y)p*; WY V!r@S D& ` ?/\ Miscellaneous Services5Pup Type: Authenticate positive response = 251BPup Contents: None. This response indicates that the name/password combination is valid.Pup Type: Authenticate negative response = 252BPup Contents: A human-readable explanation.Note that only the Authenticate request contains Mesa strings. This is done because the normalconvention for strings does not provide for packing multiple strings in one packet.The user name in the Authenticate request may optionally be qualified by a registry name, i.e., inthe form simpleName.registry. If a registry name is present, the server should verify that itcorresponds to a true mail registry (socket 7) on the same machine, and reject the request with anAuthenticate negative response if the registry is improper.Validate RecipientThis protocol is used to validate a recipient in a manner similar to what a mail server does with aMailbox property, but using a single packet exchange. This is a temporary protocol, intended tofacilitate coexistence of new and old Mail protocols.Pup Type: Validate recipient request: 266BPup 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.Pup Type: Validate recipient Yes reply: 267BPup Contents: nonePup Type: Validate recipient No reply: 270BPup Contents: noneA Yes response means that the server would be willing to accept mail for that recipient, and a Noresponse means that the server would reject mail for that recipient, or that the specified registry isnot located at the server. If the server cannot conveniently determine whether or not it wouldaccept mail for a recipient, it should answer Yes.It is permissible for the server occasionally to reply Yes erroneously, but never to reply Noerroneously. An erroneous Yes might result in the delivery of messages that would later be rejectedand returned to the sender, but an erroneous No would altogether prevent delivery to a validrecipient.Note: the principal intended client of this protocol is the new DMS mail server, which maintains alarge local cache of validated recipient names. Hence Validate Recipient requests are expected to bedynamically 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 thevalidation operation itself. This is in contrast to the recipient validation portion of the Mail TransferProtocol, where an entire recipient list is presented at once (in a single FTP command).Implementation StatusThe following table summarizes the services routinely available from server hosts at the present time.ServiceMaxcNovaAltoIFSGatewayGatewayDate and Time (String)XDate and Time (Tenex)XXDate and Time (old Alto)X fpGbtp%r`t pB ]tp%r\1t p YLtp- WS T)9 S_tp? QR PW; Kt HpI Gb+5 E5BtprAut p*'?O= tp"r;t p8tp!r7t p 4:X 2Z 12"= /2 ,6' +ER )\ (= %X4. #e "PQ H Hj X 8u Sp"Dt) p08A 0C8 ^)  ) 0 V0  >/]2Miscellaneous Services6Date and Time (new Alto)XXXXMail CheckXXDirectory Name LookupXXXXDirectory Address LookupXXWhere is UserXXNetwork Directory UpdateXXXXAlto BootXXXAuthenticateXXValidate RecipientXX fpGb) 08A ` ) A _) 08A ]8A \ ) A Z) 08A Y08A W ) A U) A  U1XUg TIMESROMAN  TIMESROMAN  TIMESROMANLOGO TIMESROMAN  TIMESROMAN %'j/*(;MMiscServices.bravoTaftFebruary 8, 1980 1:42 PM