/[suikacvs]/doc/rfc-ja/rfc0799-ja.html
Suika

Contents of /doc/rfc-ja/rfc0799-ja.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download) (as text)
Sun Sep 1 09:18:48 2002 UTC (21 years, 8 months ago) by wakaba
Branch: MAIN
CVS Tags: HEAD
File MIME type: text/html
*** empty log message ***

1 wakaba 1.1 <?xml version="1.0" encoding="iso-2022-jp"?>
2     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3     <html>
4     <head profile="http://suika.fam.cx/~wakaba/lang/rfc/translation/html-profile">
5     <meta http-equiv="Content-Style-Type" content="text/css"/>
6     <title>
7     RFC 799:
8     Internet $BL>A0%I%a%$%s(B (Internet Name Domains)
9     </title>
10     <link rel="stylesheet" href="http://suika.fam.cx/~wakaba/lang/rfc/translation/rfc-ja-style.css" type="text/css"/>
11     <link rel="alternate" href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:799" hreflang="en" title="RFC 799"/>
12     <link rev="made" href="http://www.rfceditor.org/" title="RFC Editor"/>
13     <link rev="translate" href="#rfc-translators-note"/>
14     <meta name="author" content="D. L. Mills, "/>
15     </head>
16     <body>
17     <div id="rfc--table">
18     <ul id="rfc--table-left">
19     <li>Network Working Group</li>
20     <li>Request for Comments: 799</li>
21     </ul>
22     <ul id="rfc--table-right">
23     <li title="D. L. Mills">D. L. Mills</li>
24     <li>COMSAT Laboratories</li>
25     <li>
26     <span class="t-pair">
27     <span xml:lang="en" class="t-l-en"> September 1981</span>
28     </span>
29     </li>
30     <li>
31     <span class="t-pair">
32     <span xml:lang="ja" class="t-l-ja">1981$BG/(B9$B7n(B</span>
33     </span>
34     </li>
35     </ul>
36     </div>
37     <div class="t-pair t-heading" id="rfc-title">
38     <h1 class="rfc-title t-l-en" xml:lang="en">Internet Name Domains</h1>
39     <h1 class="rfc-title t-l-ja" xml:lang="ja">Internet $BL>A0%I%a%$%s(B</h1>
40     </div>
41    
42     <div class="rfc-section" id="rfc.section.1">
43     <div class="t-pair t-heading">
44     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">1. Introduction</h1>
45     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">1.
46     $B$O$8$a$K(B</h1>
47     </div>
48     <div class="rfc-t" id="rfc.section.1.p.1" xmlns="http://www.w3.org/1999/xhtml">
49     <div class="t-pair" xmlns="">
50     <p xml:lang="en" class="t-l-en">
51     In the long run, it will not be practicable for every internet
52     host to include all internet hosts in its name-address tables. Even
53     now, with over four hundred names and nicknames in the combined
54     ARPANET-DCNET tables, this has become awkward. Some sort of
55     hierarchical name-space partitioning can easily be devised to deal
56     with this problem; however, it has been wickedly difficult to find one
57     compatible with the known mail systems throughout the community. The
58     one proposed here is the product of several discussions and meetings
59     and is believed both compatible with existing systems and extensible
60     for future systems involving thousands of hosts.
61     </p>
62     <p xml:lang="ja" class="t-l-ja">
63     $BD9$$L\$G8+$l$P!"A4$F$N(B internet $B%[%9%H$,A4$F$N(B internet
64     $B%[%9%H$rL>A0!>(B address $BI=$K4^$a$k$3$H$O<B9T2DG=$G$O$J$$$G$7$g$&!#8=:_4{$K!"7k9g(B
65     ARPANET-DCNET $BI=$K$O(B400$B0J>e$NL>A0$H0&>N$,$"$k$N$G!"Lq2p$K$J$C$F$$$^$9!#2?$i$+$N7A$G$N3,AXE*$JL>A06u4V$NJ,3d$G!"$3$NLdBj$r=hM}$9$k9)IW$,4JC1$K=PMh$^$9!#$7$+$7!"@$4VCf$N4{CN$N%a%$%k=hM}7O$H8_49@-$rJ]$D$N$OHs>o$KFq$7$$$3$H$G$9!#$3$3$KDs0F$9$k$b$N$O!"?tEY$K$o$?$k5DO@$H2q9g$N@.2L$G$"$j!"4{B8$N=hM}7O$H$N8_49@-$,$"$C$F!">-Mh$N4v@i$b$N%[%9%H$r4^$`=hM}7O$X$N3HD%@-$b$"$k$H?.$8$F$$$^$9!#(B
66     </p>
67     </div>
68     </div>
69     </div>
70    
71     <div class="rfc-section" id="rfc.section.2">
72     <div class="t-pair t-heading">
73     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">2. General Topology</h1>
74     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">2.
75     $B0lHLE*0LAj(B</h1>
76     </div>
77     <div class="rfc-t" id="rfc.section.2.p.1" xmlns="http://www.w3.org/1999/xhtml">
78     <div class="t-pair" xmlns="">
79     <p xml:lang="en" class="t-l-en">
80     We first observe that every internet host is uniquely identified
81     by one or more 32-bit internet addresses and that the entire system is
82     fully connected. For the moment, the issue of protocol compatibility
83     will be ignored, so that all hosts can be assumed MTP-competent. We
84     next impose a topological covering on the space of all internet
85     addresses with a set of so-called name domains. In the natural model,
86     name domains would correspond to institutions such as ARPA, UCL and
87     COMSAT, and would not be necessarily disjoint or complete. While in
88     principle name domains could be hierarchically structured, we will
89     assume in the following only a single-level structure.
90     </p>
91     <p xml:lang="ja" class="t-l-ja">
92     $B$^$:;O$a$K!"A4$F$N(B internet $B%[%9%H$O(B1$B$D0J>e$N(B32$B%S%C%H(B internet address $B$GHfN`$J$/<1JL$5$l!"=hM}7OA4BN$O40A4$K@\B3$5$l$F$$$k$H$7$^$9!#$5$7$"$?$C$F!"%W%m%H%3%k8_49@-LdBj$OL5;k$9$k$N$G!"A4$F$N%[%9%H$,(B
93     MTP $BE,9g$H2>Dj=PMh$^$9!#<!$KA4$F$N(B internet address $B$r$$$o$f$kL>A0%I%a%$%s$N=89g$G0LAjE*$JJ$$$$rHo$;$^$9!#<+A3%b%G%k$G$O!"L>A0%I%a%$%s$O(B
94     ARPA, UCL, COMSAT $B$N$h$&$J;\@_$H0lCW$9$k$G$7$g$&$+$i!"2rBN$dO"7k$OI,MW$J$$$G$7$g$&!#86B'$H$7$FL>A0%I%a%$%s$O3,AXE*$K9=B$2==PMh$k$G$7$g$&$+$i!"0J9_$G$OC10l3,0L9=B$$@$1$r2>Dj$7$^$9!#(B
95     </p>
96     </div>
97     </div>
98     <div class="rfc-t" id="rfc.section.2.p.2" xmlns="http://www.w3.org/1999/xhtml">
99     <div class="t-pair" xmlns="">
100     <p xml:lang="en" class="t-l-en">
101     Every name domain is associated with one or more internet
102     processes called mail forwarders and the name of that domain is the
103     name for any of these processes. Each forwarder process for a
104     particular domain is expected to maintain duplicate name-address
105     tables containing the names of all hosts in its domain and, in
106     addition, the name of at least one forwarder process for every other
107     domain. Forwarder processes may be replicated in the interests of
108     robustness; however, the resulting complexities in addressing and
109     routing will not be discussed further here. A particular internet
110     host may support a number of forwarder processes and their collective
111     names represent nicknames for that host, in addition to any other
112     names that host may have. In the following an internet host
113     supporting one or more forwarder proceses will be called simply a
114     forwarder.
115     </p>
116     <p xml:lang="ja" class="t-l-ja">
117     $B3FL>A0%I%a%$%s$O%a%$%kE>Aw<T$K8F$P$l$k0l$D0J>e$N(B internet $B=hM}$H4XO"IU$1$i$l$F$$$F!"$=$N%I%a%$%s$NL>A0$O$3$l$i$N=hM}$N$$$:$l$b$NL>A0$G$9!#FCDj%I%a%$%s$X$N3FE>Aw<T=hM}$O!"$=$N%I%a%$%sFb$NA4$F$N%[%9%H$NL>A0$K2C$($F:GDc0l$D$NB>$N%I%a%$%s$X$NE>Aw<T=hM}$NL>A0$+$i@.$kJ#@=$NL>A0!>(B address $BI=$G0];}$9$k$3$H$K$J$C$F$$$^$9!#E>Aw<T=hM}$O4h6/@-$N$?$a7+$jJV$7$F$b9=$$$^$;$s!#$7$+$7!"(B address $B;XDj$H7PO)@)8f$N7k2LJ#;(@-$O$3$3$G$O07$$$^$;$s!#$"$k(B internet $B%[%9%H$O!"4v$D$b$NE>Aw<T=hM}$H$=$N%[%9%H$N0&>N$rI=$9=8@.L>(B, $B99$K$=$N%[%9%H$,;}$AF@$kB>$NL>A0$KBP1~$7$F9=$$$^$;$s!#B3$$$F(B1$B$D0J>e$NE>Aw<T=hM}$KBP1~$7$?(B internet $B%[%9%H$,C1$KE>Aw<T$r8F$V$G$7$g$&!#(B
118     </p>
119     </div>
120     </div>
121     <div class="rfc-t" id="rfc.section.2.p.3" xmlns="http://www.w3.org/1999/xhtml">
122     <div class="t-pair" xmlns="">
123     <p xml:lang="en" class="t-l-en">
124     Every host is expected to maintain name-address tables including
125     the names of at least one forwarder for every
126     domain together with additional hosts as convenient. A host may
127     belong to several domains, but it is not necessary that all hosts in
128     any domain, be included in its tables. Following current practice,
129     several nicknames may be associated with the principal name of a host
130     in any domain and these names need not be unique relative to any other
131     domain. Furthermore, hosts can be multi-homed, that is, respond to
132     more than one address. For the purpose of mail forwarding and
133     delivery, we will assume that any of these addresses can be used
134     without prejudice. The use of multi-homing to facilitate source
135     routing is a topic for future study.
136     </p>
137     <p xml:lang="ja" class="t-l-ja">
138     $BA4%[%9%H$O$=$NL>A0$H:GDc0l$D$NE>Aw<T$r$"$k$HET9g$NNI$$DI2C$N%[%9%H$H6&$K4^$a$?L>A0!>(B address $BI=$r0];}$9$k$3$H$K$J$j$^$9!#$"$k%[%9%H$OJ#?t$N%I%a%$%s$K=jB0=PMh$^$9$,!"$9$Y$F$N%[%9%H$,$=$NI=$K4^$^$l$F$$$kI,MW$O$"$j$^$;$s!#8=:_$N47=,$K=>$$!"4v$D$+$N0&>N$r$I$N%I%a%$%s$N%[%9%H$N86B'L>$K4XO"IU$1$F9=$$$^$;$s$7!"$3$NL>A0$,B>$N%I%a%$%s$b4^$a$FFHFC$G$"$kI,MW$O$"$j$^$;$s!#$J$*!"%[%9%H$O(B multi-home $B$G$"$k$3$H$,=PMh$^$9!#$D$^$j!"J#?t$N(B address $B$KH?1~$9$k$3$H$,=PMh$^$9!#%a%$%kE>Aw!&G[AwL\E*$G!"$3$N(B address $B$N$&$A$N$$$:$l$+$,ITMx1WL5$7$KMxMQ2DG=$H2>Dj$7$^$9!#;OE@7PO)@)8fB%?J$N$?$a(B multi-home $B$G;HMQ$9$k$3$H$O>-Mh$N2]Bj$H$7$^$9!#(B
139     </p>
140     </div>
141     </div>
142     </div>
143    
144     <div class="rfc-section" id="rfc.section.3">
145     <div class="t-pair t-heading">
146     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">3. Naming Conventions</h1>
147     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">3.
148     $BL>A06(Dj(B</h1>
149     </div>
150     <div class="rfc-figure">
151     <span class="rfc-figure-id" id="rfc.figure.u.1">&#x00A0;</span>
152     <div class="rfc-preamble">
153     <div class="t-pair">
154     <p xml:lang="en" class="t-l-en">
155     In its most general form, a standard internet mailbox name has
156     the syntax
157     </p>
158     <p xml:lang="ja" class="t-l-ja">
159     $BHs>o$K0lHLE*$J7A$G$O!"I8=`(B internet $B%a%$%kH"L>$O<!$NMM$J9=J8$K$J$j$^$9!#(B
160     </p>
161     </div>
162     </div>
163     <div class="rfc-t-artwork">
164     <var xmlns="http://www.w3.org/1999/xhtml">&lt;user&gt;</var>
165     <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>
166     <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>
167     </div>
168     <div class="rfc-postamble">
169     <div class="t-pair">
170     <p xml:lang="en" class="t-l-en">
171     where <var xmlns="http://www.w3.org/1999/xhtml">&lt;user&gt;</var> is the name of a user known at the host <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> in the
172     name domain <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>. This syntax is intended to suggest a
173     three-level hierarchically structured name (reading from the right)
174     which is unique throughout the internet system. However, hosts within
175     a single domain may agree to adopt another structure, as long as it
176     does not conflict with the above syntax and as long as the forwarders
177     for that domain are prepared to make the requisite transformations.
178     For instance, let the name of a domain including DCNET be COMSAT and
179     the name of one of its hosts be COMSAT-DLM with Mills a user known to
180     that host. From within the COMSAT domain the name Mills@COMSAT-DLM
181     uniquely identifies that mailbox as could, for example, the name
182     Mills.COMSAT-DLM@COMSAT from anywhere in the internet system.
183     However, Mills@COMSAT-DLM is not necessarily meaningful anywhere
184     outside the COMSAT domain (but it could be).
185     </p>
186     <p xml:lang="ja" class="t-l-ja">
187     $B$3$3$G(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;user&gt;</var> $B$OL>A0%I%a%$%s(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> $B$N%[%9%H(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>
188     $B$NMxMQ<T$NL>A0$G$9!#$3$N9=J8$O(B internet $BBN7OFb$GFHFC$G$"$k(B3$BCJ3,3,AX2=9=B$L>(B ($B1&$+$iFI$`(B) $B$rDs>'$9$k$H$$$&$3$H$G$9!#$7$+$7!"C10l%I%a%$%sFb$N%[%9%H$O!">e5-9=J8$H>WFM$7$J$$8B$j!"$^$?I,MW$JJQ7A$r;\$9Ev3:%I%a%$%sMQE>Aw<T$,=`Hw$5$l$k8B$j!"B>$N9=B$$r:NMQ$7$F$b9=$$$^$;$s!#Nc$($P!"(B
189     <samp>DCNET</samp> $B$r4^$`%I%a%$%s$NL>A0$r(B <samp>COMSAT</samp> $B$H$7!"$=$NCf$N%[%9%H$N0l$D$NL>A0$r(B
190     <samp>COMSAT-DLM</samp> $B$H$7!"$=$N%[%9%H$KMxMQ<T(B <samp>Millds</samp> $B$,$$$k$H$7$^$9!#(B
191     <samp>COMSAT</samp> $B%I%a%$%sCf$+$i$O!"L>A0(B <samp>Mills@COMSAT-DLM</samp>
192     $B$O$=$N%a%$%kH"$rM#0l$K<1JL$9$k$3$H$,=PMh!"L>A0(B <samp>Mills.COMSAT-DLM@COMSAT</samp>
193     $B$O(B internet $BBN7O$N$I$3$+$i$G$b=PMh$^$9!#$7$+$7!"(B <samp>Mills@COMSAT-DLM</samp>
194     $B$O(B <samp>COMSAT</samp> $B%I%a%$%s$N30$N$$$:$3$K$*$$$F$b0UL#$r;}$C$F$$$kI,MW$O$"$j$^$;$s(B
195     ($B;}$?$;$k$3$H$O$G$-$^$9(B)$B!#(B
196     </p>
197     </div>
198     </div>
199     </div>
200     <div class="rfc-t" id="rfc.section.3.p.2" xmlns="http://www.w3.org/1999/xhtml">
201     <div class="t-pair" xmlns="">
202     <p xml:lang="en" class="t-l-en">
203     A typical set of name domains covering the current internet
204     system might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,
205     WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST
206     (INTELPOSTNET) and the various public data networks. The ARPA
207     forwarder would use a name-address table constructed from the latest
208     version of the HOSTS.TXT table in the NIC data base. The other
209     forwarders would construct their own, but be expected to deposit a
210     copy in the NIC data base.
211     </p>
212     <p xml:lang="ja" class="t-l-ja">
213     $B8=:_$N(B internet $BBN7O$rJ$$&L>A0%I%a%$%s$NE57?E*=89g$O!"(B
214     ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,
215     WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST
216     (INTELPOSTNET), $B3F<o8xE*%G!<%?LV$r4^$`$N$,NI$$$G$7$g$&!#(B
217     ARPA $BE>Aw<T$O(B
218     NIC $B%G!<%?%Y!<%9$N(B <code xmlns="http://www.w3.org/1999/xhtml">HOSTS.TXT</code>
219     $BI=$N:G?7HG$+$i9=C[$7$?L>A0!>(B address $BI=$r;H$$$^$7$g$&!#(B
220     </p>
221     </div>
222     </div>
223     </div>
224    
225     <div class="rfc-section" id="rfc.section.4">
226     <div class="t-pair t-heading">
227     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">4. Mail Transport Principles</h1>
228     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">4.
229     $B%a%$%kE>Aw4pK\J}?K(B</h1>
230     </div>
231     <div class="rfc-t" id="rfc.section.4.p.1" xmlns="http://www.w3.org/1999/xhtml">
232     <div class="t-pair" xmlns="">
233     <p xml:lang="en" class="t-l-en">
234     In the interests of economy and simplicity, it is expected that
235     the bulk of all mail transport in the internet system will take place
236     directly from originator to recipient
237     host and without intermediate relay. A technique of caching will
238     probably be necessary for many hosts in order to reduce the traffic
239     with forwarders merely to learn the internet address associated with a
240     correspondent host. This naturally encourages naming strategies
241     designed to minimize duplicate names in the various domains; however,
242     such duplicates are not forbidden.
243     </p>
244     <p xml:lang="ja" class="t-l-ja">
245     $B<AAG7pLs$N$?$a$K!"(B internet $BBN7OFb$NA4$F$N%a%$%kE>Aw$N(B bulk $B$OH/?.<T$+$i<u?.%[%9%H$KCf7Q$J$7$KD>@\$7$^$7$g$&!#E>Aw<T$K!"C1$KDL?.%[%9%H$K4XO"IU$1$i$l$?(B internet address $B$r3P$($F$*$/(B cache $B$N5;=Q$,$*$=$i$/!":.;($r8:$i$9$?$a$KB?$/$N%[%9%H$KI,MW$G$7$g$&!#$3$l$OEvA33F%I%a%$%sCf$NL>A0$N=EJ#$r:G>.2=$9$k$h$&$K@_7W$7$?L?L>@oN,$r?d>)$9$k$3$H$K$J$j$^$9!#$7$+$7!"$3$N=EJ#$O6X;_$O$7$^$;$s!#(B
246     </p>
247     </div>
248     </div>
249     <div class="rfc-t" id="rfc.section.4.p.2" xmlns="http://www.w3.org/1999/xhtml">
250     <div class="t-pair" xmlns="">
251     <p xml:lang="en" class="t-l-en">
252     There are several reasons why some messages will have to be
253     staged at an intermediate relay, among them the following:
254     </p>
255     <p xml:lang="ja" class="t-l-ja">
256     $B%a%C%;!<%8$,Cf7Q$r7P$J$1$l$P$J$i$J$$M}M3$,<!$K5s$2$kMM$K$$$/$D$+$"$j$^$9!#(B
257     </p>
258     </div>
259     </div>
260    
261     <ol class="rfc-list-numbers text">
262     <li>
263     <div class="t-pair">
264     <p xml:lang="en" class="t-l-en">
265     It may not be possible or convenient for the originator
266     and recipient hosts to be up on the internet system at
267     the same time for the duration of the transfer.
268     </p>
269     <p xml:lang="ja" class="t-l-ja">
270     $BH/?.!&<u?.%[%9%H$,F1;~9o$K(B internet $BBN7O$GE>Aw$N4V2TF0$7$F$$$J$$$H$$$1$J$$$N$O2DG=$G$J$$$+ITJX$G$"$k!#(B
271     </p>
272     </div>
273     </li>
274     <li>
275     <div class="t-pair">
276     <p xml:lang="en" class="t-l-en">
277     The originator host may not have the resources to
278     perform all name-address translations required.
279     </p>
280     <p xml:lang="ja" class="t-l-ja">
281     $BH/?.%[%9%H$OI,MW$JA4$F$NL>A0!>(B address $BBP1~$r;}$D;q8;$,L5$$$+$b$7$l$J$$!#(B
282     </p>
283     </div>
284     </li>
285     <li>
286     <div class="t-pair">
287     <p xml:lang="en" class="t-l-en">
288     A direct-connection path may not be feasible due to
289     regulatory economic or security constraints.
290     </p>
291     <p xml:lang="ja" class="t-l-ja">
292     $BD>@\@\B37PO)$,7P:Q>e$^$?$O0BA4>e5,@)$5$l$F$$$FMxMQ=PMh$J$$$+$b$7$l$J$$!#(B
293     </p>
294     </div>
295     </li>
296     <li>
297     <div class="t-pair">
298     <p xml:lang="en" class="t-l-en">
299     The originator and recipient hosts may not recognize the
300     same lower-level transport protocol (e.g. TCP and NCP).
301     </p>
302     <p xml:lang="ja" class="t-l-ja">
303     $BH/?.!&<u?.%[%9%H$,F1$8Dc?e=`E>Aw%W%m%H%3%k$rG'CN$7$J$$$+$b$7$l$J$$(B
304     ($BNc$($P(B TCP $B$H(B NCP)$B!#(B
305     </p>
306     </div>
307     </li>
308     </ol>
309    
310     <div class="rfc-t" id="rfc.section.4.p.3" xmlns="http://www.w3.org/1999/xhtml">
311     <div class="t-pair" xmlns="">
312     <p xml:lang="en" class="t-l-en">
313     A mail relay is an internet process equipped to store an MTP
314     message for subsequent transmission. A mail forwarder is a mail
315     relay, but not all relays are forwarders, since they might not include
316     the full name-address capability required of forwarders. In addition,
317     relays may not be competent in all domains. For instance, a MTP/TCP
318     relay may not understand NCP. In other words, the forwarders must be
319     fully connected, but the relays may not.
320     </p>
321     <p xml:lang="ja" class="t-l-ja">
322     $B%a%$%kCf7Q$O!"8eB3E>Aw$N$?$a$N(B MTP $B%a%C%;!<%8$rC_$($kI,MW$N$"$k(B internet $B=hM}$G$9!#%a%$%kE>Aw<T$O%a%$%kCf7Q<T$G$9$,!"(B
323     $BA4$F$NCf7Q<T$,E>Aw<T$G$O$"$j$^$;$s!#E>Aw<T$N40A4L>A0!>(B address $BG=NOMW7o$r4^$s$G$$$J$$$+$i$G$9!#$^$?!"Cf7Q<T$OA4$F$N%I%a%$%s$GM-G=$G$O$J$$$+$b$7$l$^$;$s!#Nc$($P!"(B
324     MTP/TCP $BCf7Q$O(B NCP $B$rM}2r$7$^$;$s!#8@$$49$($l$P!"E>Aw<T$O40A4$K@\B3$5$l$F$$$J$1$l$P$J$j$^$;$s$,!"Cf7Q<T$O$=$&$G$O$"$j$^$;$s!#(B
325     </p>
326     </div>
327     </div>
328     <div class="rfc-t" id="rfc.section.4.p.4" xmlns="http://www.w3.org/1999/xhtml">
329     <div class="t-pair" xmlns="">
330     <p xml:lang="en" class="t-l-en">
331     The particular sequence of relays traversed by a message is
332     determined by the sender by means of the source route specification in
333     the MRCP command. There are several implications to this:
334     </p>
335     <p xml:lang="ja" class="t-l-ja">
336     $B%a%C%;!<%8$,DL$jH4$1$kFCDj$NCf7QNs$O!"Aw?.<T$K$h$j(B MRCP
337     $BL?Na$N;OE@7PO);XDj$G7hDj$5$l$^$9!#$3$l$K$O4v$D$+$N78$o$j9g$$$,$"$j$^$9!#(B
338     </p>
339     </div>
340     </div>
341    
342     <ol class="rfc-list-numbers text">
343     <li>
344     <div class="t-pair">
345     <p xml:lang="en" class="t-l-en">
346     Advisory messages returned to the originator by a relay
347     or recipient host are expected to traverse the route in
348     reverse order.
349     </p>
350     <p xml:lang="ja" class="t-l-ja">
351     $BCf7Q$^$?$O<u?.%[%9%H$+$iH/?.<T$KJV$5$l$k4+9p%a%C%;!<%8$O!"7PO)$r5U=g$GDL$k$3$H$,4|BT$5$l$k!#(B
352     </p>
353     </div>
354     </li>
355     <li>
356     <div class="t-pair">
357     <p xml:lang="en" class="t-l-en">
358     Relay host names follow the same naming convention as
359     all host names relative to their domain. Since it may
360     not be possible (see below) to use internet addresses to
361     dis-ambiguate the domain, the complete standard internet
362     name .<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> is required everywhere.
363     </p>
364     <p xml:lang="ja" class="t-l-ja">
365     $BCf7Q%[%9%HL>$O!"$=$N%I%a%$%s$K4X78$N$"$kA4$F$N%[%9%HL>$HF1$8L?L>5,Ls$K=>$&!#(B internet address $B$r(B dis-ambiguate $B$J%I%a%$%s$K;H$&$N$OIT2DG=(B
366     ($B2<5-;2>H(B) $B$N$G!"40A4$JI8=`(B internet $BL>(B
367     .<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> $B$,A4$F$N>l=j$GI,?\$G$9!#(B
368     </p>
369     </div>
370     </li>
371     <li>
372     <div class="t-pair">
373     <p xml:lang="en" class="t-l-en">
374     There is no current provision for strict/loose route
375     specifications. If, in fact, the "ordinary" host
376     specification @<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> were used, each relay or forwarder
377     would use the rules outlined in the next section for
378     routing. This may result in additional relay hops.
379     </p>
380     <p xml:lang="ja" class="t-l-ja">
381     $B873J(B/$BE,Ev$J7PO);XDj$,8=:_6!5k$5$l$F$$$J$$!#<B:]!"!VIaDL$N!W(B
382     $B%[%9%H;XDj(B @<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> $B$,;H$o$l$F$$$?$J$i!"3FCf7Q<T$dE>Aw<T$O!"<!$N@a$G35@b$9$k5,B'$r;H$C$F$$$^$7$g$&!#$3$l$OCf7Q%[%C%W?t$rA}$d$97k2L$K$J$k$+$b$7$l$^$;$s!#(B
383     </p>
384     </div>
385     </li>
386     </ol>
387     </div>
388    
389     <div class="rfc-section" id="rfc.section.5">
390     <div class="t-pair t-heading">
391     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">5. Forwarder Operations</h1>
392     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">5.
393     $BE>Aw<T$N:n6H(B</h1>
394     </div>
395     <div class="rfc-t" id="rfc.section.5.p.1" xmlns="http://www.w3.org/1999/xhtml">
396     <div class="t-pair" xmlns="">
397     <p xml:lang="en" class="t-l-en">
398     This section describes a likely scenario involving hosts, relays
399     and forwarders and typical internet routes. When a forwarder receives
400     a message for <var xmlns="http://www.w3.org/1999/xhtml">&lt;user&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>, it transforms <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> if
401     necessary and forwards the message to its address found in the
402     name-address table for <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>. Note that a single host can be a
403     forwarder for several independent domains in this model and that these
404     domains can intersect. Thus, the names Mills@USC-ISIE,
405     Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to the
406     same mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably,
407     all be known in the same domain. Such use would be permissable only
408     in case the name USC-ISIE did not conflict with other names in this
409     domain.
410     </p>
411     <p xml:lang="ja" class="t-l-ja">
412     $B$3$N>O$G$O!"%[%9%H(B, $BCf7Q<T(B, $BE>Aw<T(B, $B$=$l$KE57?E*$J(B internet $B7PO)$r4^$a$?(B
413     $BE,Ev$J6Z=q$-$r@bL@$7$^$9!#E>Aw<T$,(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;user&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> $B$X$N(B
414     $B%a%C%;!<%8$r<u?.$7$?;~!"I,MW$J$i(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> $B$rJQ49$7$F!"(B
415     $B%a%C%;!<%8$r(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> $B$NL>A0!>(B address $BI=$K8+$($k(B address $B$KE>Aw$7$^$9!#(B
416     $BC10l$N%[%9%H$,$3$N%b%G%k$G$O4v$D$+$NFHN)$7$?%I%a%$%s$NE>Aw<T$K(B
417     $B$J$jF@$F!"3F%I%a%$%s$O8r:5$7F@$k$3$H$KCm0U$7$F2<$5$$!#(B
418     $B$G$9$+$i!"L>A0(B Mills@USC-ISIE, Mills.USC-ISIE@ARPA, Mills.USC-ISIE@COMSAT
419     $B$OA4$FF1$8%a%$%kH"$r;2>H$7F@$F!"L>A0(B USC-ISIE, ARPA, COMSAT
420     $B$O$*$=$i$/A4$F!"F1$8%I%a%$%sCf$K$"$k$H$7F@$^$9!#$3$&$7$?;HMQ$O!"(B
421     $BL>A0(B USC-ISIE $B$,$3$N%I%a%$%sCf$NB>$NL>A0$H>WFM$7$J$$>l9g$K8B$C$F(B
422     $BG'$a$i$l$^$9!#(B
423     </p>
424     </div>
425     </div>
426     <div class="rfc-t" id="rfc.section.5.p.2" xmlns="http://www.w3.org/1999/xhtml">
427     <div class="t-pair" xmlns="">
428     <p xml:lang="en" class="t-l-en">
429     In order for this scheme to work efficiently, it is desireable
430     that messages transiting forwarders always contain standard internet
431     mailbox names. When this is not feasible, as in the current ARPANET
432     mail system, the forwarder must be able to determine which domain the
433     message came from and edit the names accordingly. This would be
434     necessary in order to compose a reply to the message in any case.
435     </p>
436     <p xml:lang="ja" class="t-l-ja">
437     $B$3$NJ}<0$,G=N(E*$KF0$/$h$&$K!"%a%C%;!<%8$rM"Aw$9$kE>Aw<T$O(B
438     $B>o$KI8=`(B internet $B%a%$%kH"L>$r4^$`$N$,K>$^$7$$$G$9!#(B
439     $B$3$l$,=PMhL5$$>l9g!"8=:_$N(B ARPANET $B%a%$%k=hM}7O$N$h$&$K!"(B
440     $BE>Aw<T$O%a%C%;!<%8$,Mh$?%I%a%$%s$r7hDj$7!"$=$l$K=>$C$F(B
441     $BL>A0$rJT=8=PMh$J$1$l$P$J$j$^$;$s!#$3$l$O%a%C%;!<%8$X$NJV?.$r(B
442     $B9=@.$9$k$?$a$K$O$I$s$J>l9g$G$bI,MW$J$3$H$G$7$g$&!#(B
443     </p>
444     </div>
445     </div>
446     <div class="rfc-t" id="rfc.section.5.p.3" xmlns="http://www.w3.org/1999/xhtml">
447     <div class="t-pair" xmlns="">
448     <p xml:lang="en" class="t-l-en">
449     In the RFC-780 model a message arriving at a forwarder is
450     processed by the MTP server there. The server extracts the first
451     entry in the recipient-route field of an MRCP command. There are two
452     cases, depending on whether this entry specifies a domain name or a
453     host name. If a domain name, as determined by a search of a universal
454     table, it refers to one of the domains the server represents. If not,
455     it must a name or nickname of the server's host relative to ooe of the
456     domains to which the sender belongs. This allows a distinction to be
457     made between the domains COMSAT and INTELPOST on one hand and the
458     COMSAT host COMSAT-PLA on the other, all of which might be represented
459     by the same internet address, and implies that domain names must be
460     unique in all domains.
461     </p>
462     <p xml:lang="ja" class="t-l-ja">
463     RFC 780 $B%b%G%k$G$O!"E>Aw<T$KFO$$$?%a%C%;!<%8$O$=$3$N(B
464     MTP $B%5!<%P!<$G=hM}$7$^$9!#%5!<%C%P!<$O!"(B MRCP $BL?Na$N(B
465     $B<u?.<T7PO)Ms$N:G=i$N9`L\$r<h$j=P$7$^$9!#$3$N9`L\$K%I%a%$%sL>$,(B
466     $B;XDj$5$l$F$$$k$+%[%9%HL>$,;XDj$5$l$F$$$k$+$G!"(B2$B$D$N>l9g$KJ,$1$^$9!#(B
467     $B%I%a%$%sL>$N>l9g!"(B universal $BI=$N8!:w$G7hDj$9$k$N$G!"(B
468     $B$3$l$O%5!<%P!<$,BeI=$9$k%I%a%$%s$N0l$D$r;2>H$7$^$9!#(B
469     $B$=$&$G$J$$>l9g!"$3$l$OAw?.<T$,B0$9$k%I%a%$%s$N0l$D$H4X78$N$"$k%5!<%P!<$N%[%9%H$NL>A0$+0&>N$G$J$1$l$P$J$j$^$;$s!#$3$l$K$h$j!"0lJ}$G%I%a%$%s(B COMSAT $B$H(B INTELPOST
470     $B$N6hJL$,!"B>J}$G$O(B COMSAT $B%[%9%H(B COMSAT-PLA $B$N6hJL$,!"(B
471     $B$3$l$i$NA4$F$,F1$8(B internet address $B$GI=8=$5$l$k$H$7$F$b!"(B
472     $BA4$F$N%I%a%$%s$N%I%a%$%sL>$,FHFC$G$"$k$H2>Dj$7$?;~!"(B
473     $B6hJL$9$k$3$H$,=PMh$^$9!#(B
474     </p>
475     </div>
476     </div>
477     <div class="rfc-figure">
478     <span class="rfc-figure-id" id="rfc.figure.u.2">&#x00A0;</span>
479     <div class="rfc-preamble">
480     <div class="t-pair">
481     <p xml:lang="en" class="t-l-en">
482     The server next extracts the second entry in the recipient-route
483     field of the MRCP command and resolves its address relative to the
484     domain established by the first entry. If the second entry specifies
485     an explicit domain, then that overrides the first entry. If not and
486     the first entry specifies a domain, then that domain is effective.
487     However, if the first entry specifies the server's host, it may not be
488     apparent which domain is intended. For instance, consider the
489     following two MRCP commands:
490     </p>
491     <p xml:lang="ja" class="t-l-ja">
492     $B%5!<%P!<$O<!$K!"(B MRCP $BL?Na$N<u?.<T7PO)Ms$NBh(B2 entry $B$r<h$j=P$7$F!"(B
493     $B:G=i$N9`L\$G3NN)$7$?%I%a%$%s$H$N(B address $B4X78$r2r7h$7$^$9!#(B
494     $BBh(B2$B9`L\$,%I%a%$%s$rL@<($7$F;XDj$5$l$F$$$?>l9g!":G=i$N9`L\$r(B
495     $B>e=q$-$7$^$9!#$=$&$G$J$/$F:G=i$N9`L\$K%I%a%$%s$,;XDj$7$F$"$k>l9g!"(B
496     $B$=$N%I%a%$%s$,M-8z$K$J$j$^$9!#$7$+$7!":G=i$N9`L\$,%5!<%P!<$N%[%9%H$r(B
497     $B;XDj$7$F$$$k>l9g!"$I$N%I%a%$%s$r0U?^$7$F$$$k$N$+L@3N$G$J$$$+$b$7$l$^$;$s!#(B
498     $BNc$($P!"<!$N(B2$B$D$N(B MRCP $BL?Na$r9M$($F$_$^$7$g$&!#(B
499     </p>
500     </div>
501     </div>
502     <div class="rfc-t-artwork">
503     <ul class="ja-list-item-none" ja:list-item="none" xmlns:ja="http://suika.fam.cx/~wakaba/lang/rfc/translation/">
504     <li xmlns="http://www.w3.org/1999/xhtml">MRCP to:&lt;@COMSAT,Mills@HOST&gt;</li>
505     <li xmlns="http://www.w3.org/1999/xhtml">MRCP to:&lt;@INTELPOST,Mills@HOST&gt;</li>
506     </ul>
507     </div>
508    
509     <div class="rfc-postamble">
510     <div class="t-pair">
511     <p xml:lang="en" class="t-l-en">
512     where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct
513     mailboxes on different hosts. A receiving host supporting forwarders
514     for both COMSAT and INTELPOST can then preserve this distinction and
515     forward correctly using the above rules.
516     </p>
517     <p xml:lang="ja" class="t-l-ja">
518     $B$3$3$G!"(B <samp>Mills.HOST@COMSAT</samp> $B$H(B <samp>Mills.HOST@INTELPOST</samp> $B$O0[$J$k%[%9%H$NJL8D$N%a%$%kH"$H$7$^$9!#(B <samp>COMSAT</samp> $B$H(B <samp>INTELPOST</samp> $B$NAPJ}$X$NE>Aw<T$r;}$D<u?.$7$?%[%9%H(B
519     $B$O!">e5-$N5,B'$r;H$C$F@5$7$/$3$N6hJL$rJ];}$7(B, $BE>Aw$9$k$3$H$,=PMh$^$9!#(B
520     </p>
521     </div>
522     </div>
523     </div>
524     <div class="rfc-figure">
525     <span class="rfc-figure-id" id="rfc.figure.u.3">&#x00A0;</span>
526     <div class="rfc-preamble">
527     <div class="t-pair">
528     <p xml:lang="en" class="t-l-en">
529     Now let the forwarder host have the name FORWARDER in both the
530     COMSAT and INTELPOST domains and consider its options when receiving
531     the command
532     </p>
533     <p xml:lang="ja" class="t-l-ja">
534     $B$$$^!"E>Aw<T%[%9%H$,L>A0(B <samp>FORWARDER</samp> $B$r(B <samp>COMSAT</samp> $B$H(B <samp>INTERPOST</samp> $BN>%I%a%$%s$K(B
535     $B;}$C$F$$$F!"<!$NL?Na$r<u?.$7$?;~$r9M$($F$_$^$7$g$&!#(B
536     </p>
537     </div>
538     </div>
539     <div class="rfc-t-artwork">
540     <ul class="ja-list-item-none" ja:list-item="none" xmlns:ja="http://suika.fam.cx/~wakaba/lang/rfc/translation/">
541     <li xmlns="http://www.w3.org/1999/xhtml">MRCP to:&lt;@FORWARDER,Mills@HOST&gt;</li>
542     </ul>
543     </div>
544     <div class="rfc-postamble">
545     <div class="t-pair">
546     <p xml:lang="en" class="t-l-en">
547     The forwarder is being asked simply to relay within the domain of the
548     sender; however, it belongs to more than one domain! The obvious way
549     to resolve this issue would be to forbid the use of implicit domains,
550     as represented by Mills@HOST, and require the full internet mailbox
551     names Mills.HOST@COMSAT or Mills.HOST@INTELPOST. It is also possible
552     to dis-ambiguate the domain by inspecting the first entry of the
553     sender-route field of the MAIL command (see below).
554     </p>
555     <p xml:lang="ja" class="t-l-ja">
556     $BE>Aw<T$OC1$KAw?.<T$N%I%a%$%s$NCf$KCf7Q$9$k$3$H$r5a$a$i$l$F$$$^$9!#(B
557     $B$7$+$7!"$3$$$D$OJ#?t$N%I%a%$%s$KB0$7$F$$$^$9(B!
558     $B$3$NLdBj$r2r7h$9$kL@$i$+$JJ}K!$O!"(B <samp>Mills@HOST</samp>
559     $B$N$h$&$J0EL[%I%a%$%s$N;HMQ$r6X;_$7$F!"(B
560     <samp>Mills.HOST@COMSAT</samp> $B$+(B <samp>Mills.HOST@INTELPOST</samp> $B$N$h$&$K40A4(B internet $B%a%$%kH"$r;HMQ$9$k$3$H$rI,?\$H$9$k$3$H$G$7$g$&!#(B
561     $B$^$?!"(B MAIL $BL?Na$NAw?.<T7PO)Ms$N:G=i$N9`L\(B ($B2<5-;2>H(B)
562     $B$rD4$Y$k$3$H$G(B dis-ambiguate $B$9$k$N$b2DG=$G$7$g$&!#(B
563     </p>
564     </div>
565     </div>
566     </div>
567     </div>
568    
569     <div class="rfc-section" id="rfc.section.6">
570     <div class="t-pair t-heading">
571     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">6. Source and Return Routing</h1>
572     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">6.
573     $B;OE@!&5"E@@)8f(B</h1>
574     </div>
575    
576     <div class="rfc-t" id="rfc.section.6.p.1" xmlns="http://www.w3.org/1999/xhtml">
577     <div class="t-pair" xmlns="">
578     <p xml:lang="en" class="t-l-en">
579     In the RFC-780 model, routes can be specified in the
580     recipient-route field of the MRCP command and in the sender-route
581     field of the MAIL command. In point of fact, neither the
582     recipient-route or sender-route is necessary if the originator
583     specifies standard internet mailbox names. So long as the routes,
584     when used, consist only of domain names, there is no conflict with the
585     current RFC-780 specification. If for some reason forwarding must be
586     done via other hosts, then the use of a complete and unambigous syntax
587     like .<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> is required in order to avoid problems like that
588     described above.
589     </p>
590     <p xml:lang="ja" class="t-l-ja">
591     <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:780" title="RFC 780">RFC 780</a> $B%b%G%k$G$O!"7PO)$O(B MRCP $BL?Na$N<u?.<T7PO)Ms$H(B
592     MAIL $BL?Na$NAw?.<T7PO)Ms$K;XDj$G$-$^$9!#<B:]$O!"(B
593     $B<u?.<T7PO)$bAw?.<T7PO)$b!"H/?.<T$,I8=`(B internet $B%a%$%kH"L?$r(B
594     $B;XDj$7$F$$$l$PI,MW$"$j$^$;$s!#7PO)$,;H$o$l$F$$$k>l9g$K(B
595     $B%I%a%$%sL>$N$_$G@.$C$F$$$k8B$j$K$*$$$F$O!"8=9T$N(B <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:780" title="RFC 780">RFC 780</a>
596     $B;EMM$H$O>WFM$7$^$;$s!#2?$i$+$NM}M3$GE>Aw$,B>$N%[%9%H$r7P$F(B
597     $B9T$o$l$?>l9g$O!"(B <samp>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>
598     </samp> $B$N$h$&$J40A4$G[#Kf$G$J$$9=J8$,!"(B
599     $B>e$G@bL@$7$?$h$&$JLdBj$rHr$1$k$?$a$KI,MW$G$9!#(B
600     </p>
601     </div>
602     </div>
603     <div class="rfc-t" id="rfc.section.6.p.2" xmlns="http://www.w3.org/1999/xhtml">
604     <div class="t-pair" xmlns="">
605     <p xml:lang="en" class="t-l-en">
606     The present RFC-780 specification requires the receiver to
607     construct a name for the sender and insert this at the beginning of
608     the sender-route. Presumably, the only information it has to
609     construct this name is the internet address of the sender. Consider
610     the case, as in the example above, where multiple domains are
611     supported by a single server on a particular host. If hosts receiving
612     a message relayed via that server were to map its address into a name,
613     there would be no way to determine which domain was intended. We
614     conclude that the sending host must update the sender-route as well as
615     the recipient-route. It does this simply by copying the first entry
616     in the recipient-route as received as the new first entry in the
617     sender-route.
618     </p>
619     <p xml:lang="ja" class="t-l-ja">
620     $B8=9T$N(B <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:780" title="RFC 780">RFC 780</a> $B$N;EMM$G$O!"<u?.<T$,Aw?.<T$NL>A0$rAH$_N)$F!"(B
621     $BAw?.<T7PO)$N;O$a$K$3$l$rA^F~$9$kI,MW$,$"$j$^$9!#$*$=$i$/!"(B
622     $B$3$NL>A0$rAH$_N)$F$kM#0l$N>pJs$OAw?.<T$N(B internet address $B$G$7$g$&!#(B
623     $B>e$NNc$N$h$&$K!"J#?t$N%I%a%$%s$,FCDj%[%9%H$NC10l%5!<%P!<$G(B
624     $B;Y$($i$l$F$$$k>l9g$r9M$($F$_$F2<$5$$!#$=$N%5!<%P!<$GCf7Q$5$l$?(B
625     $B%a%C%;!<%8$r<u?.$7$?%[%9%H$,$=$N(B address $B$rL>A0$KBP1~$5$;$k;~$K!"(B
626     $B$I$N%I%a%$%s$r0U?^$7$F$$$?$N$+H=CG$9$kJ}K!$O$J$$$G$7$g$&!#(B
627     $B$G$9$+$i!"Aw?.$9$k%[%9%H$O<u?.<T7PO)F1MM$KAw?.<T7PO)$r$b(B
628     $B99?7$7$J$1$l$P$J$i$J$$$H7kO@IU$1$i$l$^$9!#<u?.<T7PO)$N:G=i$N9`L\$r<u?.$7$?$^$^Aw?.<T7PO)$N:G=i$N9`L\$KJ#<L$9$k$3$H$G4JC1$K=PMh$^$9!#(B
629     </p>
630     </div>
631     </div>
632     </div>
633    
634     <div class="rfc-section" id="rfc.section.7">
635     <div class="t-pair t-heading">
636     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">7. Editing the RFC-733 Header</h1>
637     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">7.
638     RFC 733 $BF,$NJT=8(B</h1>
639     </div>
640     <div class="rfc-t" id="rfc.section.7.p.1" xmlns="http://www.w3.org/1999/xhtml">
641     <div class="t-pair" xmlns="">
642     <p xml:lang="en" class="t-l-en">
643     Every effort should be made to avoid editing the RFC-733 header,
644     since this is an invasive procedure requiring extensive analysis. It
645     is expected that newly developed mail systems will be aware of the
646     standard internet mailbox syntax and ensure its use everywhere in the
647     RFC-733 and RFC-780 fields. On the occasions where this is not
648     possible, such as in many current ARPANET hosts, the necessary editing
649     should be performed upon first entry to the internet mail system from
650     the local mail system. This avoids the problems mentioned above and
651     simplifies reply functions.
652     </p>
653     <p xml:lang="ja" class="t-l-ja">
654     <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:733" title="RFC 733">RFC 733</a>
655     $BF,$rJT=8$9$k$3$H$OHr$1$k$h$&$K:GBg8B$NEXNO$rJ'$&$Y$-$G$7$g$&!#(B
656     $B$J$<$J$i!"$3$l$O9-HO0O$NJ,@O$rMW$9$k?/N,E*=hM}$@$+$i$G$9!#(B
657     $B?7$?$K3+H/$5$l$k%a%$%k=hM}7O$O!"I8=`(B internet $B%a%$%kH"9=J8$K(B
658     $BCm0U$rJ'$$!"(B <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:733" title="RFC 733">RFC 733</a> $B$H(B <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:780" title="RFC 780">RFC 780</a> $B$NMs$N$I$3$K$*$$$F$b(B
659     $B$3$l$r;H$&$3$H$r3N<B$K$9$k$3$H$,4|BT$5$l$^$9!#(B
660     $B$3$l$,2DG=$G$J$$>l9g!"Nc$($PB?$/$N8=:_$N(B ARPANET $B%[%9%H$G$O!"(B
661     $BI,MW$JJT=8$r6ICO%a%$%k=hM}7O$+$i(B internet $B%a%$%k=hM}7O$X(B
662     $B:G=i$N9`L\$K;\$9$Y$-$G$9!#$3$l$K$h$C$F>e$G=R$Y$?LdBj$,Hr$1$i$l!"(B
663     $BJV?.5!G=$,4JC1$K$J$j$^$9!#(B
664     </p>
665     </div>
666     </div>
667     <div class="rfc-t" id="rfc.section.7.p.2" xmlns="http://www.w3.org/1999/xhtml">
668     <div class="t-pair" xmlns="">
669     <p xml:lang="en" class="t-l-en">
670     In the case of ARPANET hosts, the editing operations assume that
671     all names in the form <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>, where <var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> is the name
672     of a domain, are unchanged. Names in the form <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>,
673     where <var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> is the name of a host in the ARPA domain, are transformed
674     to the form <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@ARPA. Anything else is an error.
675     Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder
676     might optionally transform <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@ARPA to <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>
677     in order to reduce the forwarder traffic when local mail systems are
678     available. Similar situations might exist elsewhere.
679     </p>
680     <p xml:lang="ja" class="t-l-ja">
681     ARPANET $B%[%9%H$N>l9g!"JT=8=hM}$O!"(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var>
682     (<var xmlns="http://www.w3.org/1999/xhtml">&lt;domain&gt;</var> $B$O%I%a%$%s$NL>A0!#(B) $B$N7A<0$NA4$F$NL>A0$OJQ99$7$J$$$H$7$^$9!#(B
683     <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> (<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var> $B$O(B ARPA $B%I%a%$%sCf$N%[%9%H$NL>A0!#(B)
684     $B$N7A<0$NL>A0$O(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@ARPA $B$N7A<0$KJQ49$7$^$9!#(B
685     $BB>$N$b$N$O8m$j$G$9!#(B ARPANET NCP mailer $B$K<jEO$9A0$K!"(B
686     ARPA MTP $BE>Aw<T$O(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>.<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>@ARPA $B$+$i(B <var xmlns="http://www.w3.org/1999/xhtml">&lt;anything&gt;</var>@<var xmlns="http://www.w3.org/1999/xhtml">&lt;host&gt;</var>
687     $B$K!"6ICO%a%$%k=hM}7O$,MxMQ2DG=$J;~$KE>Aw<T$N:.;($r8:$i$9$?$a$K!"(B
688     $BG$0U$GJQ49$7$F$b9=$$$^$;$s!#F1MM$N>u67$OB>$N>l=j$G$b$"$k$+$b$7$l$^$;$s!#(B
689     </p>
690     </div>
691     </div>
692     </div>
693    
694     <div class="rfc-section" id="rfc.section.8">
695     <div class="t-pair t-heading">
696     <h1 xml:lang="en" class="t-l-en" xmlns="http://www.w3.org/1999/xhtml">8. Concluding Remarks</h1>
697     <h1 xml:lang="ja" class="t-l-ja" xmlns="http://www.w3.org/1999/xhtml">8.
698     $B$^$H$a(B</h1>
699     </div>
700     <div class="rfc-t" id="rfc.section.8.p.1" xmlns="http://www.w3.org/1999/xhtml">
701     <div class="t-pair" xmlns="">
702     <p xml:lang="en" class="t-l-en">
703     This memorandum is intended to stimulate discussion, not simulate
704     it.
705     </p>
706     <p xml:lang="ja" class="t-l-ja">
707     $B$3$N3P=q$O5DO@$r;I7c$;$s$H$9$k$b$N$G$"$C$F!"$=$l$r5<BV$7$h$&$H$9$k(B
708     $B$b$N$G$O$"$j$^$;$s!#(B
709     </p>
710     </div>
711     </div>
712     </div>
713    
714    
715     <ins id="rfc-translators-note" class="t-note t-l-ja" xml:lang="ja">
716     <div class="rfc-section" id="t-change">
717     <h1>$BK]Lu$NJQ99MzNr(B</h1>
718     <dl>
719     <dt>2002-07-27 <a href="mailto:w@suika.fam.cx" title="$BEE;R%a%$%k(B: &lt;w@suika.fam.cx>">$B$o$+$P(B</a>
720     </dt>
721     <dd>
722     <ul>
723     <li>$BK]Lu40N;!#(B</li>
724     </ul>
725     </dd>
726     <dt>2002-09-01 <a href="mailto:w@suika.fam.cx" title="$BEE;R%a%$%k(B: &lt;w@suika.fam.cx>">$B$o$+$P(B</a>
727     </dt>
728     <dd>
729     <ul>
730     <li>
731     <a href="http://suika.fam.cx/uri-res/N2L?urn:ietf:rfc:2629" title="RFC 2629">RFC 2629</a> $B$G%^!<%/IU$1!#(B</li>
732     </ul>
733     </dd>
734     </dl>
735     </div>
736     <div class="rfc-section" id="rfc-t-copyright">
737     <h1>$BLuJ8$K$D$$$F$NCx:n8"@<L@(B</h1>
738     <ul>
739     <li>Copyright &#x00A9; $B$o$+$P(B (2002)$B!#A48"J]N1!#(B</li>
740     </ul>
741     <p>$B$3$NK]LuJ8$O!"<+M3$KJ#@=!&G[I[!&2~JQ$7$F9=$$$^$;$s!#(B
742     (rfc-copyright-story $B$b;2>H$7$F2<$5$$!#(B)</p>
743     </div>
744     </ins>
745     </body>
746     </html>

admin@suikawiki.org
ViewVC Help
Powered by ViewVC 1.1.24