![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc819.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 42BSD / usr.lib / sendmail / doc|
Return to rfc819.lpr CVS log | Up to [CSRG BSD Unix] / 42BSD / usr.lib / sendmail / doc |
1.1 root 1:
2:
3: Network Working Group Zaw-Sing Su (SRI)
4: Request for Comments: 819 Jon Postel (ISI)
5: August 1982
6:
7:
8:
9: The Domain Naming Convention for Internet User Applications
10:
11:
12:
13:
14: 1. Introduction
15:
16: For many years, the naming convention "<user>@<host>" has served the
17: ARPANET user community for its mail system, and the substring
18: "<host>" has been used for other applications such as file transfer
19: (FTP) and terminal access (Telnet). With the advent of network
20: interconnection, this naming convention needs to be generalized to
21: accommodate internetworking. A decision has recently been reached to
22: replace the simple name field, "<host>", by a composite name field,
23: "<domain>" [2]. This note is an attempt to clarify this generalized
24: naming convention, the Internet Naming Convention, and to explore the
25: implications of its adoption for Internet name service and user
26: applications.
27:
28: The following example illustrates the changes in naming convention:
29:
30: ARPANET Convention: Fred@ISIF
31: Internet Convention: [email protected]
32:
33: The intent is that the Internet names be used to form a
34: tree-structured administrative dependent, rather than a strictly
35: topology dependent, hierarchy. The left-to-right string of name
36: components proceeds from the most specific to the most general, that
37: is, the root of the tree, the administrative universe, is on the
38: right.
39:
40: The name service for realizing the Internet naming convention is
41: assumed to be application independent. It is not a part of any
42: particular application, but rather an independent name service serves
43: different user applications.
44:
45: 2. The Structural Model
46:
47: The Internet naming convention is based on the domain concept. The
48: name of a domain consists of a concatenation of one or more <simple
49: names>. A domain can be considered as a region of jurisdiction for
50: name assignment and of responsibility for name-to-address
51: translation. The set of domains forms a hierarchy.
52:
53: Using a graph theory representation, this hierarchy may be modeled as
54: a directed graph. A directed graph consists of a set of nodes and a
55:
56:
57: Su & Postel [Page 1]
58:
59:
60:
61: RFC 819 August 1982;
62:
63:
64: collection of arcs, where arcs are identified by ordered pairs of
65: distinct nodes [1]. Each node of the graph represents a domain. An
66: ordered pair (B, A), an arc from B to A, indicates that B is a
67: subdomain of domain A, and B is a simple name unique within A. We
68: will refer to B as a child of A, and A a parent of B. The directed
69: graph that best describes the naming hierarchy is called an
70: "in-tree", which is a rooted tree with all arcs directed towards the
71: root (Figure 1). The root of the tree represents the naming universe,
72: ancestor of all domains. Endpoints (or leaves) of the tree are the
73: lowest-level domains.
74:
75: U
76: / | \
77: / | \ U -- Naming Universe
78: ^ ^ ^ I -- Intermediate Domain
79: | | | E -- Endpoint Domain
80: I E I
81: / \ |
82: ^ ^ ^
83: | | |
84: E E I
85: / | \
86: ^ ^ ^
87: | | |
88: E E E
89:
90: Figure 1
91: The In-Tree Model for Domain Hierarchy
92:
93: The simple name of a child in this model is necessarily unique within
94: its parent domain. Since the simple name of the child's parent is
95: unique within the child's grandparent domain, the child can be
96: uniquely named in its grandparent domain by the concatenation of its
97: simple name followed by its parent's simple name.
98:
99: For example, if the simple name of a child is "C1" then no other
100: child of the same parent may be named "C1". Further, if the
101: parent of this child is named "P1", then "P1" is a unique simple
102: name in the child's grandparent domain. Thus, the concatenation
103: C1.P1 is unique in C1's grandparent domain.
104:
105: Similarly, each element of the hierarchy is uniquely named in the
106: universe by its complete name, the concatenation of its simple name
107: and those for the domains along the trail leading to the naming
108: universe.
109:
110: The hierarchical structure of the Internet naming convention supports
111: decentralization of naming authority and distribution of name service
112: capability. We assume a naming authority and a name server
113:
114:
115: Su & Postel [Page 2]
116:
117:
118:
119: RFC 819 August 1982;
120:
121:
122: associated with each domain. In Sections 5 and 6 respectively the
123: name service and the naming authority are discussed.
124:
125: Within an endpoint domain, unique names are assigned to <user>
126: representing user mailboxes. User mailboxes may be viewed as
127: children of their respective domains.
128:
129: In reality, anomalies may exist violating the in-tree model of naming
130: hierarchy. Overlapping domains imply multiple parentage, i.e., an
131: entity of the naming hierarchy being a child of more than one domain.
132: It is conceivable that ISI can be a member of the ARPA domain as well
133: as a member of the USC domain (Figure 2). Such a relation
134: constitutes an anomaly to the rule of one-connectivity between any
135: two points of a tree. The common child and the sub-tree below it
136: become descendants of both parent domains.
137:
138: U
139: / | \
140: / . \
141: . . ARPA
142: . . | \
143: USC | \
144: \ | .
145: \ | .
146: ISI
147:
148: Figure 2
149: Anomaly in the In-Tree Model
150:
151: Some issues resulting from multiple parentage are addressed in
152: Appendix B. The general implications of multiple parentage are a
153: subject for further investigation.
154:
155: 3. Advantage of Absolute Naming
156:
157: Absolute naming implies that the (complete) names are assigned with
158: respect to a universal reference point. The advantage of absolute
159: naming is that a name thus assigned can be universally interpreted
160: with respect to the universal reference point. The Internet naming
161: convention provides absolute naming with the naming universe as its
162: universal reference point.
163:
164: For relative naming, an entity is named depending upon the position
165: of the naming entity relative to that of the named entity. A set of
166: hosts running the "unix" operating system exchange mail using a
167: method called "uucp". The naming convention employed by uucp is an
168: example of relative naming. The mail recipient is typically named by
169: a source route identifying a chain of locally known hosts linking the
170:
171:
172:
173: Su & Postel [Page 3]
174:
175:
176:
177: RFC 819 August 1982;
178:
179:
180: sender's host to the recipient's. A destination name can be, for
181: example,
182:
183: "alpha!beta!gamma!john",
184:
185: where "alpha" is presumably known to the originating host, "beta" is
186: known to "alpha", and so on.
187:
188: The uucp mail system has demonstrated many of the problems inherent
189: to relative naming. When the host names are only locally
190: interpretable, routing optimization becomes impossible. A reply
191: message may have to traverse the reverse route to the original sender
192: in order to be forwarded to other parties.
193:
194: Furthermore, if a message is forwarded by one of the original
195: recipients or passed on as the text of another message, the frame of
196: reference of the relative source route can be completely lost. Such
197: relative naming schemes have severe problems for many of the uses
198: that we depend upon in the ARPA Internet community.
199:
200: 4. Interoperability
201:
202: To allow interoperation with a different naming convention, the names
203: assigned by a foreign naming convention need to be accommodated.
204: Given the autonomous nature of domains, a foreign naming environment
205: may be incorporated as a domain anywhere in the hierarchy. Within
206: the naming universe, the name service for a domain is provided within
207: that domain. Thus, a foreign naming convention can be independent of
208: the Internet naming convention. What is implied here is that no
209: standard convention for naming needs to be imposed to allow
210: interoperations among heterogeneous naming environments.
211:
212: For example:
213:
214: There might be a naming convention, say, in the FOO world,
215: something like "<user>%<host>%<area>". Communications with an
216: entity in that environment can be achieved from the Internet
217: community by simply appending ".FOO" on the end of the name in
218: that foreign convention.
219:
220: John%ISI-Tops20-7%California.FOO
221:
222: Another example:
223:
224: One way of accommodating the "uucp world" described in the last
225: section is to declare it as a foreign system. Thus, a uucp
226: name
227:
228: "alpha!beta!gamma!john"
229:
230:
231: Su & Postel [Page 4]
232:
233:
234:
235: RFC 819 August 1982;
236:
237:
238: might be known in the Internet community as
239:
240: "alpha!beta!gamma!john.UUCP".
241:
242: Communicating with a complex subdomain is another case which can
243: be treated as interoperation. A complex subdomain is a domain
244: with complex internal naming structure presumably unknown to the
245: outside world (or the outside world does not care to be concerned
246: with its complexity).
247:
248: For the mail system application, the names embedded in the message
249: text are often used by the destination for such purpose as to reply
250: to the original message. Thus, the embedded names may need to be
251: converted for the benefit of the name server in the destination
252: environment.
253:
254: Conversion of names on the boundary between heterogeneous naming
255: environments is a complex subject. The following example illustrates
256: some of the involved issues.
257:
258: For example:
259:
260: A message is sent from the Internet community to the FOO
261: environment. It may bear the "From" and "To" fields as:
262:
263: From: [email protected]
264: To: John%ISI-Tops20-7%California.FOO
265:
266: where "FOO" is a domain independent of the Internet naming
267: environment. The interface on the boundary of the two
268: environments may be represented by a software module. We may
269: assume this interface to be an entity of the Internet community
270: as well as an entity of the FOO community. For the benefit of
271: the FOO environment, the "From" and "To" fields need to be
272: modified upon the message's arrival at the boundary. One may
273: view naming as a separate layer of protocol, and treat
274: conversion as a protocol translation. The matter is
275: complicated when the message is sent to more than one
276: destination within different naming environments; or the
277: message is destined within an environment not sharing boundary
278: with the originating naming environment.
279:
280: While the general subject concerning conversion is beyond the scope
281: of this note, a few questions are raised in Appendix D.
282:
283:
284:
285:
286:
287:
288:
289: Su & Postel [Page 5]
290:
291:
292:
293: RFC 819 August 1982;
294:
295:
296: 5. Name Service
297:
298: Name service is a network service providing name-to-address
299: translation. Such service may be achieved in a number of ways. For
300: a simple networking environment, it can be accomplished with a single
301: central database containing name-to-address correspondence for all
302: the pertinent network entities, such as hosts.
303:
304: In the case of the old ARPANET host names, a central database is
305: duplicated in each individual host. The originating module of an
306: application process would query the local name service (e.g., make a
307: system call) to obtain network address for the destination host. With
308: the proliferation of networks and an accelerating increase in the
309: number of hosts participating in networking, the ever growing size,
310: update frequency, and the dissemination of the central database makes
311: this approach unmanageable.
312:
313: The hierarchical structure of the Internet naming convention supports
314: decentralization of naming authority and distribution of name service
315: capability. It readily accommodates growth of the naming universe.
316: It allows an arbitrary number of hierarchical layers. The addition
317: of a new domain adds little complexity to an existing Internet
318: system.
319:
320: The name service at each domain is assumed to be provided by one or
321: more name servers. There are two models for how a name server
322: completes its work, these might be called "iterative" and
323: "recursive".
324:
325: For an iterative name server there may be two kinds of responses.
326: The first kind of response is a destination address. The second
327: kind of response is the address of another name server. If the
328: response is a destination address, then the query is satisfied. If
329: the response is the address of another name server, then the query
330: must be repeated using that name server, and so on until a
331: destination address is obtained.
332:
333: For a recursive name server there is only one kind of response --
334: a destination address. This puts an obligation on the name server
335: to actually make the call on another name server if it can't
336: answer the query itself.
337:
338: It is noted that looping can be avoided since the names presented for
339: translation can only be of finite concatenation. However, care
340: should be taken in employing mechanisms such as a pointer to the next
341: simple name for resolution.
342:
343: We believe that some name servers will be recursive, but we don't
344: believe that all will be. This means that the caller must be
345:
346:
347: Su & Postel [Page 6]
348:
349:
350:
351: RFC 819 August 1982;
352:
353:
354: prepared for either type of server. Further discussion and examples
355: of name service is given in Appendix C.
356:
357: The basic name service at each domain is the translation of simple
358: names to addresses for all of its children. However, if only this
359: basic name service is provided, the use of complete (or fully
360: qualified) names would be required. Such requirement can be
361: unreasonable in practice. Thus, we propose the use of partial names
362: in the context in which their uniqueness is preserved. By
363: construction, naming uniqueness is preserved within the domain of a
364: common ancestry. Thus, a partially qualified name is constructed by
365: omitting from the complete name ancestors common to the communicating
366: parties. When a partially qualified name leaves its context of
367: uniqueness it must be additionally qualified.
368:
369: The use of partially qualified names places a requirement on the
370: Internet name service. To satisfy this requirement, the name service
371: at each domain must be capable of, in addition to the basic service,
372: resolving simple names for all of its ancestors (including itself)
373: and their children. In Appendix B, the required distinction among
374: simple names for such resolution is addressed.
375:
376: 6. Naming Authority
377:
378: Associated with each domain there must be a naming authority to
379: assign simple names and ensure proper distinction among simple names.
380:
381: Note that if the use of partially qualified names is allowed in a
382: sub-domain, the uniqueness of simple names inside that sub-domain is
383: insufficient to avoid ambiguity with names outside the subdomain.
384: Appendix B discusses simple name assignment in a sub-domain that
385: would allow the use of partially qualified names without ambiguity.
386:
387: Administratively, associated with each domain there is a single
388: person (or office) called the registrar. The registrar of the naming
389: universe specifies the top-level set of domains and designates a
390: registrar for each of these domains. The registrar for any given
391: domain maintains the naming authority for that domain.
392:
393: 7. Network-Oriented Applications
394:
395: For user applications such as file transfer and terminal access, the
396: remote host needs to be named. To be compatible with ARPANET naming
397: convention, a host can be treated as an endpoint domain.
398:
399: Many operating systems or programming language run-time environments
400: provide functions or calls (JSYSs, SVCs, UUOs, SYSs, etc.) for
401: standard services (e.g., time-of-day, account-of-logged-in-user,
402: convert-number-to-string). It is likely to be very helpful if such a
403:
404:
405: Su & Postel [Page 7]
406:
407:
408:
409: RFC 819 August 1982;
410:
411:
412: function or call is developed for translating a host name to an
413: address. Indeed, several systems on the ARPANET already have such
414: facilities for translating an ARPANET host name into an ARPANET
415: address based on internal tables.
416:
417: We recommend that this provision of a standard function or call for
418: translating names to addresses be extended to accept names of
419: Internet convention. This will promote a consistent interface to the
420: users of programs involving internetwork activities. The standard
421: facility for translating Internet names to Internet addresses should
422: include all the mechanisms available on the host, such as checking a
423: local table or cache of recently checked names, or consulting a name
424: server via the Internet.
425:
426: 8. Mail Relaying
427:
428: Relaying is a feature adopted by more and more mail systems.
429: Relaying facilitates, among other things, interoperations between
430: heterogeneous mail systems. The term "relay" is used to describe the
431: situation where a message is routed via one or more intermediate
432: points between the sender and the recipient. The mail relays are
433: normally specified explicitly as relay points in the instructions for
434: message delivery. Usually, each of the intermediate relays assume
435: responsibility for the relayed message [3].
436:
437: A point should be made on the basic difference between mail
438: relaying and the uucp naming system. The difference is that
439: although mail relaying with absolute naming can also be considered
440: as a form of source routing, the names of each intermediate points
441: and that of the destination are universally interpretable, while
442: the host names along a source route of the uucp convention is
443: relative and thus only locally interpretable.
444:
445: The Internet naming convention explicitly allows interoperations
446: among heterogeneous systems. This implies that the originator of a
447: communication may name a destination which resides in a foreign
448: system. The probability is that the destination network address may
449: not be comprehensible to the transport system of the originator.
450: Thus, an implicit relaying mechanism is called for at the boundary
451: between the domains. The function of this implicit relay is the same
452: as the explicit relay.
453:
454:
455:
456:
457:
458:
459:
460:
461:
462:
463: Su & Postel [Page 8]
464:
465:
466:
467: RFC 819 August 1982;
468:
469:
470: 9. Implementation
471:
472: The Actual Domains
473:
474: The initial set of top-level names include:
475:
476: ARPA
477:
478: This represents the set of organizations involved in the
479: Internet system through the authority of the U.S. Defense
480: Advanced Research Projects Agency. This includes all the
481: research and development hosts on the ARPANET and hosts on
482: many other nets as well. But note very carefully that the
483: top-level domain "ARPA" does not map one-to-one with the
484: ARPANET -- domains are administrative, not topological.
485:
486: Transition
487:
488: In the transition from the ARPANET naming convention to the
489: Internet naming convention, a host name may be used as a simple
490: name for an endpoint domain. Thus, if "USC-ISIF" is an ARPANET
491: host name, then "USC-ISIF.ARPA" is the name of an Internet domain.
492:
493: 10. Summary
494:
495: A hierarchical naming convention based on the domain concept has been
496: adopted by the Internet community. It is an absolute naming
497: convention defined along administrative rather than topological
498: boundaries. This naming convention is adaptive for interoperations
499: with other naming conventions. Thus, no standard convention needs to
500: be imposed for interoperations among heterogeneous naming
501: environments.
502:
503: This Internet naming convention allows distributed name service and
504: naming authority functions at each domain. We have specified these
505: functions required at each domain. Also discussed are implications
506: on network-oriented applications, mail systems, and administrative
507: aspects of this convention.
508:
509:
510:
511:
512:
513:
514:
515:
516:
517:
518:
519:
520:
521: Su & Postel [Page 9]
522:
523:
524:
525: RFC 819 August 1982;
526:
527:
528: APPENDIX A
529:
530: The BNF Specification
531:
532: We present here a rather detailed "BNF" definition of the allowed
533: form for a computer mail "mailbox" composed of a "local-part" and a
534: "domain" (separated by an at sign). Clearly, the domain can be used
535: separately in other network-oriented applications.
536:
537: <mailbox> ::= <local-part> "@" <domain>
538:
539: <local-part> ::= <string> | <quoted-string>
540:
541: <string> ::= <char> | <char> <string>
542:
543: <quoted-string> ::= """ <qtext> """
544:
545: <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
546:
547: <char> ::= <c> | "\" <x>
548:
549: <domain> ::= <naming-domain> | <naming-domain> "." <domain>
550:
551: <naming-domain> ::= <simple-name> | <address>
552:
553: <simple-name> ::= <a> <ldh-str> <let-dig>
554:
555: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
556:
557: <let-dig> ::= <a> | <d>
558:
559: <let-dig-hyp> ::= <a> | <d> | "-"
560:
561: <address> :: = "#" <number> | "[" <dotnum> "]"
562:
563: <number> ::= <d> | <d> <number>
564:
565: <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
566:
567: <snum> ::= one, two, or three digits representing a decimal integer
568: value in the range 0 through 255
569:
570: <a> ::= any one of the 52 alphabetic characters A through Z in upper
571: case and a through z in lower case
572:
573: <c> ::= any one of the 128 ASCII characters except <s> or <SP>
574:
575: <d> ::= any one of the ten digits 0 through 9
576:
577:
578:
579: Su & Postel [Page 10]
580:
581:
582:
583: RFC 819 August 1982;
584:
585:
586: <q> ::= any one of the 128 ASCII characters except CR, LF, quote ("),
587: or backslash (\)
588:
589: <x> ::= any one of the 128 ASCII characters (no exceptions)
590:
591: <s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@",
592: """, and the control characters (ASCII codes 0 through 31 inclusive
593: and 127)
594:
595: Note that the backslash, "\", is a quote character, which is used to
596: indicate that the next character is to be used literally (instead of
597: its normal interpretation). For example, "Joe\,Smith" could be used
598: to indicate a single nine character user field with comma being the
599: fourth character of the field.
600:
601: The simple names that make up a domain may contain both upper and
602: lower case letters (as well as digits and hyphen), but these names
603: are not case sensitive.
604:
605: Hosts are generally known by names. Sometimes a host is not known to
606: the translation function and communication is blocked. To bypass
607: this barrier two forms of addresses are also allowed for host
608: "names". One form is a decimal integer prefixed by a pound sign, "#".
609: Another form, called "dotted decimal", is four small decimal integers
610: separated by dots and enclosed by brackets, e.g., "[123.255.37.2]",
611: which indicates a 32-bit ARPA Internet Address in four 8-bit fields.
612: (Of course, these numeric address forms are specific to the Internet,
613: other forms may have to be provided if this problem arises in other
614: transport systems.)
615:
616:
617:
618:
619:
620:
621:
622:
623:
624:
625:
626:
627:
628:
629:
630:
631:
632:
633:
634:
635:
636:
637: Su & Postel [Page 11]
638:
639:
640:
641: RFC 819 August 1982;
642:
643:
644: APPENDIX B
645:
646: An Aside on the Assignment of Simple Names
647:
648: In the following example, there are two naming hierarchies joining at
649: the naming universe 'U'. One consists of domains (S, R, N, J, P, Q,
650: B, A); and the other (L, E, F, G, H, D, C, K, B, A). Domain B is
651: assumed to have multiple parentage as shown.
652:
653: U
654: / \
655: / \
656: J L
657: / \
658: N E
659: / \ / \
660: R P D F
661: / \ | \ \
662: S Q C (X) G
663: \ / \ \
664: B K H
665: /
666: A
667:
668: Figure 3
669: Illustration of Requirements for the Distinction of Simple Names
670:
671: Suppose someone at A tries to initiate communication with destination
672: H. The fully qualified destination name would be
673:
674: H.G.F.E.L.U
675:
676: Omitting common ancestors, the partially qualified name for the
677: destination would be
678:
679: H.G.F
680:
681: To permit the case of partially qualified names, name server at A
682: needs to resolve the simple name F, i.e., F needs to be distinct from
683: all the other simple names in its database.
684:
685: To enable the name server of a domain to resolve simple names, a
686: simple name for a child needs to be assigned distinct from those of
687: all of its ancestors and their immediate children. However, such
688: distinction would not be sufficient to allow simple name resolution
689: at lower-level domains because lower-level domains could have
690: multiple parentage below the level of this domain.
691:
692: In the example above, let us assume that a name is to be assigned
693:
694:
695: Su & Postel [Page 12]
696:
697:
698:
699: RFC 819 August 1982;
700:
701:
702: to a new domain X by D. To allow name server at D to resolve
703: simple names, the name for X must be distinct from L, E, D, C, F,
704: and J. However, allowing A to resolve simple names, X needs to be
705: also distinct from A, B, K, as well as from Q, P, N, and R.
706:
707: The following observations can be made.
708:
709: Simple names along parallel trails (distinct trails leading from
710: one domain to the naming universe) must be distinct, e.g., N must
711: be distinct from E for B or A to properly resolve simple names.
712:
713: No universal uniqueness of simple names is called for, e.g., the
714: simple name S does not have to be distinct from that of E, F, G,
715: H, D, C, K, Q, B, or A.
716:
717: The lower the level at which a domain occurs, the more immune it
718: is to the requirement of naming uniqueness.
719:
720: To satisfy the required distinction of simple names for proper
721: resolution at all levels, a naming authority needs to ensure the
722: simple name to be assigned distinct from those in the name server
723: databases at the endpoint naming domains within its domain. As an
724: example, for D to assign a simple name for X, it would need to
725: consult databases at A and K. It is, however, acceptable to have
726: simple names under domain A identical with those under K. Failure of
727: such distinct assignment of simple names by naming authority of one
728: domain would jeopardize the capability of simple name resolution for
729: entities within the subtree under that domain.
730:
731:
732:
733:
734:
735:
736:
737:
738:
739:
740:
741:
742:
743:
744:
745:
746:
747:
748:
749:
750:
751:
752:
753: Su & Postel [Page 13]
754:
755:
756:
757: RFC 819 August 1982;
758:
759:
760: APPENDIX C
761:
762: Further Discussion of Name Service and Name Servers
763:
764: The name service on a system should appear to the programmer of an
765: application program simply as a system call or library subroutine.
766: Within that call or subroutine there may be several types of methods
767: for resolving the name string into an address.
768:
769: First, a local table may be consulted. This table may be a
770: complete table and may be updated frequently, or it may simply be
771: a cache of the few latest name to address mappings recently
772: determined.
773:
774: Second, a call may be made to a name server to resolve the string
775: into a destination address.
776:
777: Third, a call may be made to a name server to resolve the string
778: into a relay address.
779:
780: Whenever a name server is called it may be a recursive server or an
781: interactive server.
782:
783: If the server is recursive, the caller won't be able to tell if
784: the server itself had the information to resolve the query or
785: called another server recursively (except perhaps for the time it
786: takes).
787:
788: If the server is iterative, the caller must be prepared for either
789: the answer to its query, or a response indicating that it should
790: call on a different server.
791:
792: It should be noted that the main name service discussed in this memo
793: is simply a name string to address service. For some applications
794: there may be other services needed.
795:
796: For example, even within the Internet there are several procedures
797: or protocols for actually transferring mail. One need is to
798: determine which mail procedures a destination host can use.
799: Another need is to determine the name of a relay host if the
800: source and destination hosts do not have a common mail procedure.
801: These more specialized services must be specific to each
802: application since the answers may be application dependent, but
803: the basic name to address translation is application independent.
804:
805:
806:
807:
808:
809:
810:
811: Su & Postel [Page 14]
812:
813:
814:
815: RFC 819 August 1982;
816:
817:
818: APPENDIX D
819:
820: Further Discussion of Interoperability and Protocol Translations
821:
822: The translation of protocols from one system to another is often
823: quite difficult. Following are some questions that stem from
824: considering the translations of addresses between mail systems:
825:
826: What is the impact of different addressing environments (i.e.,
827: environments of different address formats)?
828:
829: It is noted that the boundary of naming environment may or may not
830: coincide with the boundary of different mail systems. Should the
831: conversion of naming be independent of the application system?
832:
833: The boundary between different addressing environments may or may
834: not coincide with that of different naming environments or
835: application systems. Some generic approach appears to be
836: necessary.
837:
838: If the conversion of naming is to be independent of the
839: application system, some form of interaction appears necessary
840: between the interface module of naming conversion with some
841: application level functions, such as the parsing and modification
842: of message text.
843:
844: To accommodate encryption, conversion may not be desirable at all.
845: What then can be an alternative to conversion?
846:
847:
848:
849:
850:
851:
852:
853:
854:
855:
856:
857:
858:
859:
860:
861:
862:
863:
864:
865:
866:
867:
868:
869: Su & Postel [Page 15]
870:
871:
872:
873: RFC 819 August 1982;
874:
875:
876: GLOSSARY
877:
878: address
879:
880: An address is a numerical identifier for the topological location
881: of the named entity.
882:
883: name
884:
885: A name is an alphanumeric identifier associated with the named
886: entity. For unique identification, a name needs to be unique in
887: the context in which the name is used. A name can be mapped to an
888: address.
889:
890: complete (fully qualified) name
891:
892: A complete name is a concatenation of simple names representing
893: the hierarchical relation of the named with respect to the naming
894: universe, that is it is the concatenation of the simple names of
895: the domain structure tree nodes starting with its own name and
896: ending with the top level node name. It is a unique name in the
897: naming universe.
898:
899: partially qualified name
900:
901: A partially qualified name is an abbreviation of the complete name
902: omitting simple names of the common ancestors of the communicating
903: parties.
904:
905: simple name
906:
907: A simple name is an alphanumeric identifier unique only within its
908: parent domain.
909:
910: domain
911:
912: A domain defines a region of jurisdiction for name assignment and
913: of responsibility for name-to-address translation.
914:
915: naming universe
916:
917: Naming universe is the ancestor of all network entities.
918:
919: naming environment
920:
921: A networking environment employing a specific naming convention.
922:
923:
924:
925:
926:
927: Su & Postel [Page 16]
928:
929:
930:
931: RFC 819 August 1982;
932:
933:
934: name service
935:
936: Name service is a network service for name-to-address mapping.
937:
938: name server
939:
940: A name server is a network mechanism (e.g., a process) realizing
941: the function of name service.
942:
943: naming authority
944:
945: Naming authority is an administrative entity having the authority
946: for assigning simple names and responsibility for resolving naming
947: conflict.
948:
949: parallel relations
950:
951: A network entity may have one or more hierarchical relations with
952: respect to the naming universe. Such multiple relations are
953: parallel relations to each other.
954:
955: multiple parentage
956:
957: A network entity has multiple parentage when it is assigned a
958: simple name by more than one naming domain.
959:
960:
961:
962:
963:
964:
965:
966:
967:
968:
969:
970:
971:
972:
973:
974:
975:
976:
977:
978:
979:
980:
981:
982:
983:
984:
985: Su & Postel [Page 17]
986:
987:
988:
989: RFC 819 August 1982;
990:
991:
992: REFERENCES
993:
994: [1] F. Harary, "Graph Theory", Addison-Wesley, Reading,
995: Massachusetts, 1969.
996:
997: [2] J. Postel, "Computer Mail Meeting Notes", RFC-805,
998: USC/Information Sciences Institute, 8 February 1982.
999:
1000: [3] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
1001: USC/Information Sciences Institute, August 1982.
1002:
1003: [4] D. Crocker, "Standard for the Format of ARPA Internet Text
1004: Messages", RFC-822, Department of Electrical Engineering, University
1005: of Delaware, August 1982.
1006:
1007:
1008:
1009:
1010:
1011:
1012:
1013:
1014:
1015:
1016:
1017:
1018:
1019:
1020:
1021:
1022:
1023:
1024:
1025:
1026:
1027:
1028:
1029:
1030:
1031:
1032:
1033:
1034:
1035:
1036:
1037:
1038:
1039:
1040:
1041:
1042:
1043: Su & Postel [Page 18]
1044:
1045:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.