组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：lou_goodman（lou_goodman&nbsp;&nbsp;lou_oxygen@163.com）<br />
译文发布时间：2001-6-8<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike&nbsp;Padlipsky<br />
Request&nbsp;for&nbsp;Comments:&nbsp;949&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mitre<br />
Semisupersedes&nbsp;RFC&nbsp;505&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;July&nbsp;1985<br />
<br />
<br />
FTP&nbsp;未公开的独特命令<br />
(RFC949&nbsp;Mike&nbsp;Padlipsky)<br />
<br />
STATUS&nbsp;OF&nbsp;THIS&nbsp;MEMO<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;RFC&nbsp;proposes&nbsp;an&nbsp;extension&nbsp;to&nbsp;the&nbsp;File&nbsp;Transfer&nbsp;Protocol&nbsp;for&nbsp;the<br />
&nbsp;&nbsp;&nbsp;ARPA-Internet&nbsp;community,&nbsp;and&nbsp;requests&nbsp;discussion&nbsp;and&nbsp;suggestions&nbsp;for<br />
&nbsp;&nbsp;&nbsp;improvements.&nbsp;&nbsp;Distribution&nbsp;of&nbsp;this&nbsp;memo&nbsp;is&nbsp;unlimited.<br />
<br />
摘要:<br />
这篇文档提出了FTP协议的扩展,并进行了讨论,给出了进一步发展的建议.你可以自由<br />
的传播这篇文档.<br />
<br />
讨论:<br />
由许多文章都讨论了具有当前STOR&nbsp;作用的FTP命令.但是他们都要求发送者提供一个<br />
文件名,从而是目的文件有一个唯一的名字和当前的目录相对应.这种方法对于各种类型的存<br />
储池型目录时非常有用的.这种目录类型和容易使我们想起打印队列,传真和打孔机队列,尽<br />
管打印队列简单到只需要一个命令足以解决问题,和我们要讨论的问题还有相当大的不同.<br />
如果我们接受这样的FTP扩展,那么就不需要在管什么"X"命令啦.关键的问题是怎样才<br />
能较好的管理它.也许最自然的办法是给STOR的语法树加上控制参数.既然有那么多的<br />
UNIXtm以至与我们对Multics&nbsp;trick不再陌生,并且FTP不考虑和命令单失配的命令,只是我<br />
们相信附加命令是我们要走的方向.<br />
命令的名字需要一点考虑.STORe的名字(STUN)太笨啦;UNIQue&nbsp;来自于广告甚至商标(让你感<br />
到迷惑);&nbsp;Stor&nbsp;Uniquely&nbsp;NaMed&nbsp;(SUNM)也有一点广告的味道;&nbsp;Uniquely&nbsp;Named&nbsp;STore&nbsp;(UNST)&nbsp;<br />
看起来有点像DELEte,虽然她没那么坏;&nbsp;SToRe&nbsp;Uniquely&nbsp;named&nbsp;(STRU)&nbsp;被采用,的确是这<br />
样;最好的选择好像是&nbsp;STOU.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;实际中的问题是发送者是否需要通知唯一的名字是什么.直觉上,问题就是这个,有时<br />
他又不是.是他人一的确需要太多的工作.因此我们为什么不把它包括在一个适合的回应文<br />
本里(除非由他多的评论繁多这一点)?<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;顺便说一下,我们并没有忽略访问控制,认证和统计管理这些用户在旧的STOR和新的<br />
STOU中遇到的东西,相反通过账号和密码,我们能做的和RFC&nbsp;505中的一样好.<br />
<br />
评论:<br />
&nbsp;&nbsp;&nbsp;&nbsp;作为一个新的命令---STOU,这个东西像STOR一样,除了它的目的文件是创建在当前的<br />
目录下,它有一个和目录一样唯一的名字.250回应应该包括文件名(我所拿的FTP文当时如<br />
此的旧,也许250不再正确了).<br />
<br />
<br />
RFC949&nbsp;Mike&nbsp;Padlipsky&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FTP&nbsp;未公开的独特命令<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />