Commit | Line | Data |
---|---|---|
15637ed4 RG |
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: Fred@F.ISI.ARPA | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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: Fred@F.ISI.ARPA | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f |