Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
RFC 757 A Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPAnet Message Systems Debra P. Deutsch 10 September 1979 Bolt Beranek and Newman 50 Moulton Street Cambridge, Massachusetts 02138 (617) 491-1850
Preface Page 1 Preface Unlike many RFCs, this is not a specification of asoon-to-be-implemented protocol. Instead this is a true requestfor comments on the concepts and suggestions found within thisdocument, written with the hope that its content, and anydiscussion which it spurs, will contribute towards the design ofthe next generation of computer-based message creation anddelivery systems. A number of people have made contributions to the form andcontent of this document. In particular, I would like to thankJerry Burchfiel for his general and technical advice andencouragement, Bob Thomas for his wisdom about the TIP Logindatabase and design of a netmail database, Ted Myer for playingdevil's advocate, and Charlotte Mooers for her excellenteditorial assistance. Debbie DeutschRFC 757 September 1979
Introduction Page 21. Introduction The current ARPAnet message handling scheme has evolved fromrather informal, decentralized beginnings. Early developers tookadvantage of pre-existing tools -- TECO, FTP -- in order toimplement their first systems. Later, protocols were developedto codify the conventions already in use. While theseconventions have been able to support an amazing variety andamount of service, they have a number of shortcomings. One difficulty is the naming/addressing problem, which dealswith the need both to identify the recipient and to indicatecorrectly a delivery point for the message. The current paradigmis deficient in that it lacks a sharp distinction between therecipient's name and the recipient's address, which is thedelivery point on the net. The naming/addressing scheme does not allow users to addresstheir messages using human names, but instead forces them toemploy designations better designed for machine parsing thanhuman identification. Another source of limitations lies in the delivery system,which is simply an extension of the File Transfer Protocol. Thedelivery system is fairly limited in its operation, handling onlysimple transactions involving the transfer of a single message toa single user on the destination host. The ability to bundlemessages and the ability to fan-out messages at the foreign hostwould improve the efficiency and usefulness of the system. An additional drawback to the delivery system is caused, tosome extent, by the addressing scheme. A change in address, orincorrect address usually causes the delivery system to handlethe message incorrectly. While some hosts support some varietyof a mail forwarding database (MFDB), this solution is at bestinadequate and spotty for providing reliable service to thenetwork as a whole. Because the same username may belong todifferent people at different hosts, ambiguities which may cropup when messages are incorrectly addressed keep even the bestMFDBs from always being able to do their job. This proposal envisions a system in which the identity andaddress of the recipient are treated as two separate items. Anetwork database supports a directory service which suppliescorrect address information for all recipients. Additionally,the scheme allows mail delivery to be restricted to authorizedusers of the network, should that be a desirable feature.RFC 757 September 1979
Names and Addresses Page 32. Names and Addresses Today's ARPAnet naming and addressing scheme (as specified inRFC 733[3]) does not discriminate between the identity of a user 1and his address . Both are expressed the same way:USERNAME@HOST. While this should always result in a uniquehandle for that user, it has proved to be inadequate in practice.Users who change the location of their mailboxes, because ofeither a change in affiliation or a simple shift in host usage,also get their names changed. If their old host employs an MFDBthe problem is not too bad. Mail is simply forwarded on to thenew address, slightly delayed. Other less fortunate users whocannot rely upon an MFDB must notify all their correspondents ofthe change in address/name. Any mail addressed to the oldaddress becomes undeliverable. (An excellent discussion of thedifferences between naming, addressing, and routing is found in apaper by John Shoch [1].) The desire to use "real" names in the address fields ofmessages is also thwarted by the current system. An elaboratesystem for using human-compatible vs. machine-interpretable 2information has been evolved for use in message headers . Themost recent developments indicate that many users would feelhappiest if the real human name could appear;machine-interpretable information should not intrude too heavilyinto the writer's work- and thought-space. The solution proposed here calls for a total break between theway a recipient is named or identified and the way in which hislocation is specified. Since the ARPAnet is a regulatedenvironment, a unique (and not necessarily human-readable) IDcould be assigned to each authorized recipient of network mail.This ID would stay with the user throughout his lifetime on thenetwork, through changes in address and affiliation. A network database (which could be derived from the samedatabase that has been proposed to support TIP login) wouldassociate each ID with one or more addresses indicating where themail for that ID may be delivered. If more than one address were_______________ 1 See, for example,RFC 733's discussion of the semantics ofaddress fields, in which it is specified that the To: field"contains the identity of the primary recipients of the message". 2 See the "Syntax of General Addressee Items" section of RFC733.RFC 757 September 1979
Names and Addresses Page 4associated with an ID, that would indicate an ordered preferencein delivery points. The delivery system would attempt deliveryto the first addressee, and, if that failed, try the second, and 3so on . Most IDs would probably have only one address. Alsoassociated with each ID would be some information about the ID'sowner: name, postal address, affiliation, phone number, etc. Rather than being forced to type some awkward character stringin order to name his correspondent, the writer would have tosupply only enough information to allow some process to determinethe unique identity of the recipient. This information might bethe recipient's name or anything else found in the database. The access to this data would also free the writer from anyneed to know the location of the recipient. Once the unique IDwere known, the correct location for delivery would be only alook-up away.2.1 A distributed database approach It is clear that if the network database had only oneinstantiation there would be a tremendous contention problem.All message traffic would be forced to query that one database.This is extremely undesirable, both in terms of reliability andspeed. It is also clear that requiring each host to maintain acomplete local copy of the entire network database is anundesirable and unnecessary burden on the hosts. A better approach would be to build some sophistication intothe local delivery system, and use local mini-databases which arebased upon the contents of a distributed network database. (Itmay be redundant and/or partitioned, etc., but is probably notresident on the local host.) When a local host queries thenetwork database about an ID (or, in a more costly operation,asked to supply an ID given enough identification such as name,etc.) the database may be asked to return all its information onthat ID. At this point the local host can enter all or some ofthat information into a locally maintained database of its own.It will always refer to that database first when looking for aname or address, only calling the network database if it cannotfind a local entry. Depending upon the desired level ofsophistication of the local message handling programs, additionalinformation may be added to that database, including, for_______________ 3 Multiple addresses might also be used to indicate thatmultiple deliveries are desired.RFC 757 September 1979
Names and Addresses Page 5example, nicknames. The database might be shared by a cluster of hosts (such asexist at BBN or ISI), or it might be used by only one. Hostswhich originate small amounts of message traffic might rely uponthe network database entirely. The structure and maintenance of the local databases is leftsolely to the local hosts. They may or may not store addresses.It may be desirable either to garbage collect them, or to letthem grow. The local databases might be linked to smaller, morespecialized databases which are owned by individual users orgroups. These individual databases would be the equivalent ofaddress books in which users might note special things aboutindividuals: interests, last time seen, names of associates,etc. The existence and scope of these databases are not mandatedby this scheme, but it does allow for them. The same individual databases may be used by message creationprograms in order to determine the recipient's ID fromuser-supplied input. For example, a user may address a messageto someone named Nick. The message creation program mayassociate "Nick" with an ID, and hand that ID off to the deliverysystem, totally removing the matter of address or formal ID fromthe user's world.2.2 Delivery The delivery operation consists of three parts: 1. Determining the address to which the message must be sent, 2. Sending the message, 3. Processing by foreign host. The first step usually means looking up, in either a local orthe network database, the correct address(es) for messagedelivery, given the recipient's ID. Should the ID not be knownat the time the message is submitted for delivery, any operationnecessary to determine that ID (such as a call to either thelocal or network database) is also performed as part of thisstep. The second step is not too different from what happens today.The local host establishes a connection to the foreign host. Itis then able to send one or messages to one or more people. Theoptions are: - Bulk mail. Several recipients all get the same message.RFC 757 September 1979
Names and Addresses Page 6 - Bundled mail. Several messages get sent to the same recipient. - A combination of the above - One recipient gets one message. The foreign host should be able to accept mail for each ID. The rejection of mail for a given ID by the foreign host wouldusually indicate an inconsistency between the sender's localdatabase and the network database. In this case, the local hostupdates its local database from the network database, andattempts delivery at the "new" host. (This is mail forwarding.)If a host taken from the network database is found to beincorrect, there is a problem in the network database, andappropriate authorities are notified. Thus, address changespropagate out from the network database only as the out-of-dateinformation is referenced. This reduces the magnitude of thelocal database update problem. Once the foreign host recognizes the ID(s), the message(s) maybe transmitted to the foreign host. Upon successfultransmission, the job of the local host is done. The third step requires the foreign host to process themessage(s). This is analogous to what may occur in a mail room.A foreign host may have to sort the bundled or bulk mail itreceives. In addition, the foreign host might perform internalor external fan-out functions or other special functions, at theoption of the ID owner. The implemention and design of possible functions which may beperformed in the mail rooms are neither mandated nor restrictedby this delivery scheme. Since they are too numerous to alloweven a small portion of them to be described here, only a fewexamples will be mentioned. Fan-out functions might include placing messages in multiplefiles, sending copies to one or more other users, orrebroadcasting the messages onto the network. (In that lastcase, the foreign host might evaluate an ID list, in much thesame way that the ITS mail repeater broadcasts messages addressedto certain mailboxes.) Special functions might include automatichard-copy creation or reply generation, processing by variousdaemons, or any other service found desirable by the host's userpopulation and administration. The implementation of fan-outfunctions is up to the local host, as are any additionalfunctions which the user population might wish of its local "mailroom". Whatever services are available, the mail room willdistribute the mail to the correct location for each ID.RFC 757 September 1979
Names and Addresses Page 72.2.1 Additional delivery options It may be desirable to allow mail rooms to accept a username inplace of an ID. Use of a username is a less reliable method ofaddressing than use of an ID. - A username may not be sufficiently unambiguous for getting an ID and host from the network database. - Since a recipient's username may change from time to time, there is a chance that the username supplied by 4 the sender will be incorrect , or that the host may not recognize it. Because a recipient's ID does not change with time, errors such as those caused by username changes cannot occur if IDs are used. Similarities or ambiguities can be discovered before delivery occurs, and the sender can be prompted for additional identifying information about his intended recipient. - In an even worse case, a correct username can still result in an incorrect delivery when it is paired with an incorrect host or acted upon by a mail forwarding 5 database . Because unique IDs are unambiguous, the possibility of such a situation is eliminated by the use of unique IDs._______________ 4 A particularly insidious source of addressing errors stemsfrom the inconsistent use of (human) names and initials togenerate usernames. The sender can easily guess hisrecipient's username incorrectly by using, or failing to usea combination of initials and last name. (For example, auser wishing to address Jim Miller at BBNA and using theaddress "Miller@BBNA" will have his message successfullydelivered to Duncan Miller at the same site.) 5 The author has observed a mail forwarding databaseredirect messages correctly addressed to one JWalker todifferent JWalker at another host.RFC 757 September 1979
Names and Addresses Page 82.2.2 Failures The case in which the network database is found to be incorrecthas already been discussed. It may make sense to mark the entryas "possibly in error" and to notify both the network database 6and the ID owner when such a situation occurs. In this case maildelivery to the ID's owner will not occur, but this is not toobad, considering that that is what happens today when a host doesnot recognize a username. One additional failure mode, the loss of the network databasefrom the net, must be considered, even though a well-designeddistributed network database should be robust enough to almostrule out this possibility. If such a failure should occur, the local databases should beable to handle most of the traffic. What would be lost is theability to add new IDs to the network database, the ability tochange hosts for an ID, the ability to update local databases,and the ability to query the network database. In essence, therewould be a regression to the state we are in today. A well-administered network database should be backed upfrequently. Should a catastrophic series of hardware failuresremove one or more of the network database's hosts from the net,the database could be moved elsewhere. Such a change wouldentail notification of all hosts on which mail originates.Software which queries the database should be designed to be ableto easily handle such a move._______________ 6 Such notification would presumably be by hardcopy mail ortelephone.RFC 757 September 1979
Relationship to TIP Login database Page 93. Relationship to TIP Login database A number of references to the TIP Login problem and a databasewhich has been proposed as part of its solution have been made inthis note. A series of working papers [5] written by Bob Thomas,Paul Santos, and Jack Haverty describe an approach to TIP Login.In brief, the method is to build and maintain a distributed TIPLogin database, containing information necessary to allow a newentity called a "login-host" to decide whether or not to grant auser access to a given TIP, and whether or not to allow the userto make various modifications to the database itself. The TIP login database is derived from a "network user database", which contains information above and beyond that necessaryto support TIP login. This comprehensive database is designed tosupport applications other than TIP Login, either directly or bymeans of databases derived from it. Contained in the TIP Login database are each user's loginstring, a list of TIPs the user is authorized to access, theuser's unique ID, his password, and any other "permissions" (inaddition to which TIPs may be accessed). These permissions mayindicate that the user may create, delete, or modify entries inthe database, to assume other user's roles, and to what extent hemay do so. The notion of permissions as developed by SteveWarshall is discussed in an NSW memo [2]. It seems entirely reasonable to derive a netmail database fromthe same comprehensive database that is designed to support TIPLogin. The concept of a unique ID is supported by that database.Much of the required information for a netmail database isalready included, and the maintenance tools necessary to modifyit seem well-suited for the purpose. The concept of permissionsextends well to the needs of netmail. Permissions specific tonetwork mail might include, for example, the ability to modifythe delivery host list associated with a given user. The mechanisms necessary for the maintenance of thecomprehensive network database and its derived databases give usa netmail database very inexpensively. This proposal takesadvantage of that situation.RFC 757 September 1979
Relationship toRFC 753 Page 104. Relationship toRFC 753 RFC 753 [4] describes an internetwork message delivery system.Very briefly, the approach is to locate one or more "messageprocessing modules" (or MPMs) on each network. These MPMs passmessages across network boundaries, and are also capable ofmaking deliveries to users on the local network. The documentalso details a proposed message format, along the envelope andletter paradigm. An external "envelope", read by the deliverysystem, allows the (unread) message to be correctly routed anddelivered to the proper recipient. Groups of messages passedbetween a pair of MPMs are sent together in a "mail bag". This proposal differs fromRFC 753 in that it is primarilyintended to operate within a network or a concatenation ofnetworks using a common host-host protocol, e.g. TCP. Where RFC753 addresses the problems of internetwork communication(differing message formats, complex routing, and correctidentification of the proper recipient), this note concentratesprimarily on what can be done within a single protocol. The twoare not incompatible. While a general internetwork protocol mustprovide general methods which can be compatible with differenthost-host protocols in different networks, a proposal such asthis one can capitalize on the capabilities, resources, andpolicies of a given catenet (catenated network) such as theARPAnet/PRnet/SATNET etc.4.1 Compatibility The delivery system described inRFC 753 is compatible with thesystem outlined here. Let's examine this for each of the threebasic delivery options performed by the MPM. (In the discussionthat follows, "local networks" means a concatenation of networksusing a common host-host protocol, e.g. TCP. "Foreign network"means some network which uses a different host-host protocol,e.g. X.25. (See Figure 4-1.)4.1.1 Outgoing message4.1.1.1RFC 753 The sender's process hands a message to the local network MPM.The message may be destined to an address on the local network oron a foreign network. In the former case, the MPM performs thelocal delivery function (see "Incoming message"). In the lattercase, the MPM passes the message along to another MPM which is"closer" to the end user.RFC 757 September 1979
Relationship toRFC 753 Page 11 +---------+ +----------+ | | | | | RCC-NET | | WIDEBAND | ....... | | | NET | . . +---------+ | | . MPM . * * +----------+ .......+---------+ * * * * ....... || | +---------+ . . +---------+| BBN-NET |***| |__. MPM . ..... | || | | ARPANET | ....... . .xxxx| TELENET |+---------+***| |***********. G . | | +---------+*** ..... +---------+ * * * * ** ....... +--------+ +-------+ ***..... +-------------+ . . | | | | . . | |--. MPM . | SATNET | | PRNET | . G .oooo| DIAL-UP NET | ....... | | | | ..... | | +--------+ +-------+ +-------------+ "Local Nets", TCP based | "Foreign Nets", other (direct addressing using IP) | host-host protocols*** = TCP xxx = X.25 ooo = other communications protocol G = gateway Figure 4-1: The Internet Environment4.1.1.2 This proposal The sender's process determines the proper host for deliverygiven the recipient's unique ID. If the message is destined tothe local network, delivery takes place as described earlier inthis proposal. If the recipient is not local, the message may bepassed to an MPM for foreign delivery. (A discussion of internetdelivery which does not presuppose RFC 753 implementation isfound later in this note.) The environment in which the MPM operates does not assume anyknowledge on the part of the local networks about addressees onforeign networks. Thus there are two possibilities which arise:RFC 757 September 1979
Relationship toRFC 753 Page 12 - The recipient has an ID known to the local networks. In this case, the local networks supply theRFC 753 "address". This can take place in the local networks' MPM or the user's sending or mail creation process. - The recipient is unknown to the local networks. Here the sender must supply "mailbox" information himself, either explicitly or with help of his local host's database. Thus, outgoing mail as described in this memo is compatiblewithRFC 753, with the benefit of reducing the burden on the MPMby handling mail deliveries that are local to local networks.4.1.2 Messages in transit Traffic between two MPMs is not affected by this proposal.4.1.3 Incoming mail The MPM on the networks local to the recipient will have accessto the netmail database, allowing it to translate "mailboxes" to"addresses". It can determine the unique ID of the recipient (ifnot known), and initiate delivery to that recipient. Here RFC753 and this proposal complement each other very well.RFC 757 September 1979
Implications of an internetwork message environment Page 135. Implications of an internetwork message environment The scheme described above is based upon the assumption that aunique identifier can be assigned to each registered recipient ofmail. Whether or not this uniqueness can be guaranteed in afairly unregulated internetwork environment is questionable. Itis technically feasible, certainly. The difficulties are morepolitical, because it is necessary to gain the cooperation of theadministrators and user populations of foreign networks. Let'sassume cooperation, however, and see what might happen in aninternet environment.5.1 Birthplaces Each set of local networks would have its own database, forease in access. It does not seem practical to register each IDin every database, however. That would be unnecessary, and wouldcreate access and storage problems at the network databases.Here the concept of a "birthplace", or ID origin, may be of use. While an ID does not imply where the user is now, it can saysomething about who issued it. A simple system for determiningthe address for any ID can be maintained by having the issuingnetwork keep a pointer for each ID it issues. One doubleindirection would yield the desired address, even if the ID werenot issued on the local nets. A message originating on the localnets with an ID which is unknown to its database can be handledby determining the birthplace of the ID. An inquiry to thebirthplace database would return a list of one or more networkson which the ID is registered. An inquiry to any of those wouldget the requisite information. All that is necessary to supportthis is for the birthplace record (small enough!) to be kept,and for the act of registration at a given net to automaticallycause that net to notify the birthplace of the registration.(Conversely, a de-registration would cause a similar notificationof the birthplace.)5.1.1 ID resolution The handling of ID resolution when the ID is not known to thelocal net does not seem to have a solution simpler than queryingforeign nets until some success is achieved.5.1.2 Hosts in an internet environment The substitution of internet host names for simple host namesshould not cause any difficulty.RFC 757 September 1979
Implications of an internetwork message environment Page 145.1.3 Orphans Should a birthplace cease to exist (usually because its networkis dismantled), it would be necessary for a second birthplace to"adopt" the first birthplace's records. Notification of thischange could be propagated throughout the internet environment inmuch the same way as the addition of a new birthplace would betreated.RFC 757 September 1979
Conclusions Page 156. Conclusions While ARPAnet message systems have been amazingly successful,there is much room for improvement in the quality and quantity ofthe services offered. Current protocols are limiting thedevelopment of new message systems. This paper has discussed ameans of providing the underlying support necessary for buildinga new generation of message systems which can be betterhuman-engineered in addition to providing more services andgreater reliability. Critics may argue that the proposal is too radical, too much ofa departure from current practice. After all, today's messageservice is extremely straightforward in design, and therefore hascomparatively few failure modes. The protocols in use havedescended, with relatively few changes, from the first filetransfer and message format protocols implemented on the ARPAnet.This makes them well understood; people are aware of both theirshortcomings and usage. Finally, there are people who will notfeel comfortable about requiring a network database, distrustingthe reliability and questioning the possible cost of such ascheme. On the other hand, it is undeniably true that very little morecan be done to improve message services while staying withintoday's practices. New message systems which will be able totransmit facsimile, voice, and other media along with textrequire us to rethink message formats and do away with deliveryprotocols which are predicated upon the characteristics of ASCIItext. The inception of internetwork message delivery causes usto re-evaluate how we handle messages locally. Finally, theUSERNAME@HOST naming scheme has proved to be inadequate, whilethe divorce of recipients' identities from their locations seemsa promising possibility as a replacement. The ARPAnet will soon have a distributed database forsupporting TIP Login. Only small, incremental costs would beassociated with building and maintaining a netmail database atthe same time. It can be argued that TIP Login requires at leastthe level of reliability required by a message delivery system.If the TIP Login database is successful, a netmail database canwork, too. It is clear that we will be implementing a new set of messageformat and delivery protocols in the near future, in order toallow for multi-media messages, internetwork message traffic, andthe like. New message composition and delivery systems will bebuilt to meet those specifications and take advantage of theavenues of development which they will open. If there will everbe an advantageous time to re-evaluate and re-design how messagesare addressed and delivered, it is now, when we are about toenter upon an entirely new cycle of message composition andRFC 757 September 1979
Conclusions Page 16delivery program implementation.RFC 757 September 1979
References Page 17 REFERENCES[1] John F. Shoch. Inter-Network Naming, Addressing, and Routing. In Proceedings, COMPCON. IEEE Computer Society, Fall, 1979.[2] Stephen Warshall. On Names and Permissions. Mass. Computer Associates. 1979.[3] David H. Crocker, John J. Vittal, Kenneth T. Pogran, D. Austin Henderson, Jr. STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES.RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc, Massachussets Institute of Technology, Bolt Beranek and Newman Inc., November, 1977.[4] Jonathan B. Postel. INTERNET MESSAGE PROTOCOL.RFC 753, Information Sciences Institute, March, 1979.[5] Robert H. Thomas, Paul J. Santos, and John F. Haverty. TIP Login Notes. Bolt Beranek and Newman. 1979.RFC 757 September 1979
Table of Contents Page i Table of Contents1. Introduction 22. Names and Addresses 32.1 A distributed database approach 42.2 Delivery 5 2.2.1 Additional delivery options 7 2.2.2 Failures 83. Relationship to TIP Login database 94. Relationship toRFC 753 104.1 Compatibility 10 4.1.1 Outgoing message 10 4.1.1.1RFC 753 10 4.1.1.2 This proposal 11 4.1.2 Messages in transit 12 4.1.3 Incoming mail 125. Implications of an internetwork message environment 135.1 Birthplaces 13 5.1.1 ID resolution 13 5.1.2 Hosts in an internet environment 13 5.1.3 Orphans 146. Conclusions 15RFC 757 September 1979
List of Figures Page ii List of FiguresFigure 4-1: The Internet Environment 10RFC 757 September 1979
[8]ページ先頭