rfc1288.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：卢伍春（spacelu   [e-mail]）
译文发布时间：2001-6-15
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



网络工作组                                       D. Zimmerman
Request for Comments: 1288           Center for Discrete Mathematics and
废弃: RFCs 1196, 1194, 742             Theoretical Computer Science
December 1991


Finger用户信息协议
(RFC1288 The Finger User Information Protocol)

备忘录状态
	这个备忘录定义了用户信息交换协议.这个RFC详细说明了因特网中的IAB标准追踪协
议,
和讨论要求以及提高的建议.请查阅当前版本的"IAB正式协议标准"来确立协议规定和状态
的标准
化.该备忘录的发行没有限制.


摘要
	这个备忘录描述了Finger用户信息协议.这是一个为远程用户信息程序提供接口的简单
协议. 以前面描述最初Finger协议的RFC742为基础,这个备忘录尽力阐明Finger连接两端
的期望通
讯.它还尽力不使前面许多存在的执行失效或增加对前面最初协议定义的不必要限制.
	这个版本更正和阐明了RFC1196.
目录
   1.      简介  ...........................................   2
     1.1.    目的  ...............................................   2
     1.2.    历史  ..............................................   3
     1.3.    要求  .........................................   3
     1.4.    更新  ..............................................   3
   2.      协议的使用  ....................................   4
     2.1.    事物流  .......................................   4
     2.2.    数据格式  ..........................................   4
     2.3.    查询指定  .................................   4
     2.4.    RUIP {Q2} 表现  ...................................   5
     2.5.    期望 RUIP 反映  ...............................   6
       2.5.1.  {C} 查询  ..........................................   6
       2.5.2.  {U}{C} 查询  .......................................   6
       2.5.3.  {U} 不明确信息 ......................................   7
       2.5.4.  /W  查询表示  .....................................   7

       2.5.5.  自动销售机 ...................................   7
   3.      安全性  ...............................................   7
     3.1.    安全执行  ..............................   7
     3.2.    RUIP 安全  ........................................   8
       3.2.1.  {Q2} 拒绝  .......................................   8
       3.2.2.  {C} 拒绝  ........................................   8
       3.2.3.  原子交换  ...................................   8
       3.2.4.  用户信息文件  .............................   9
       3.2.5.  用户程序执行  .........................   9
       3.2.6.  {U} 不明确信息  ......................................   9
       3.2.7.  审计跟踪  .......................................   9
     3.3.    客户安全  ......................................   9
   4.      例子  ...............................................  10
     4.1.    空命令行例子 ({C})  ...............  10
     4.2.    指定名例子 ({U}{C})  .................  10
     4.3.    不明确名例子 ({U}{C})  .......  11
     4.4.    查询类例子 {Q2} ({U}{H}{H}{C})  ............  11
   5.      确认  ........................................  12
   6.      安全考虑  ................................  12
   7.      作者地址  .......................................  12

1.  介绍

1.1.  目的
	这个备忘录描述了Finger用户信息协议.它是提供远程用户信息程序(RUIP)接
口的简单协议.
	以前面描述最初Finger协议的RFC742为基础,这个备忘录尽力阐明Finger连接
两端的期望通讯.它还尽力不使前面许多存在的执行失效或增加对前面最初协议定义的
不必要限制.
	现在最流行的Finger应用可能是从California,Eerkeley大学BSD UNIX工作室
发展起来的.因此,这个备忘录基于BSD版本内容.
	但是,BSD版本提供很少选项针对特定站点安全政策的详细Finger RUIP,或者
保护用户以免受到危险数据的攻击.而且,它存在许多用户和管理员需要注意的安全隐患,
特别因为协议的目的是返回系统用户信息,最有可能发生问题的部分.因此,这个备忘录
提出了大量的重要安全建议和注释.

1.2.  历史
	最初在Les Enrnest写的Finger程序是ITS命名程序的灵感.MIT的Earl Killian
和SAIL的Brian Harvery参加负责了最初协议的执行.
   Ken Harrenstien是RFC 742的作者."命名/Finger"是这个备忘录最初的状态.

1.3. 要求
	在这个文档里,用来定义每一个重要的特别要求的词都用大写.这些词为:
   * "MUST"
	这个词或形容词"REQUIRED"表示某项是说明书的绝对具备的要求.
   * "SHOULD"
	它或形容词"RECOMMENDED"表示在特殊环境下可能存在一些原因使忽略这
个规则,但是在选择其他规则之前,应该了解完整应用和仔细权衡条件.
   * "MAY"
	它或形容词"OPTIONAL"表示这个规则实际上是可选的.例如,一个买主可能选择
这个规则因为特殊的市场需要它或因为它能增强产品竞争力;但是另外一个买主可能不
用这个规则.
	如果一个应用程序没有满足一个或多个必须(MUST)要求,则是不符合条件.
满足所有必须(MUST)和应该(SHOULD)条件的应用叫做无条件符合的;符合必须(MUST)
但是不符合所有应该(SHOULD)条件的叫做条件符合.
1.4.  修正
	这个备忘录和RFC1196的差异为:
	o  在前面说明书中Finger的可选项/W开关错误的放置在一行的末尾.在这个
备忘录中,4.2BSD Finger指定它应该在前面.
	o 在Finger查询指定中的RNF处理空格不是很清楚.这个备忘录通过包括清楚
的代号使之更加严格.
	o 现在Finger连接中的事物流在Finger的紧密连接方面更好的定义.
2.协议的使用
2.1.  事物流
	Finger基于传输控制协议(TCP),用TCP端口79.本地主机打开一个和远程
主机在Finger端口的连接.在连接远端主机的RUIP变成有效来处理请求.本地主机
发送给RUIP一行基于Finger查询说明的请求,然后等待RUIP反应.RUIP接收处理这个
请求,返回答案,然后发起连接关闭.本地主机接收到答案和关闭信号,然后执行本地端
的关闭.
2.2.  数据格式
	任何传输的数据必须是ASCII格式,不用奇偶方式和CRLF结束行.这样排除了
其他字符格式如EBCDIC,等等.这同时也表明任何在ASCII128到255的字符都真正是国际
数据,这个不是7位ASCII码加上奇偶校验.

2.3.  请求说明
	RUIP必须接收完整的Finger请求说明.
	Finger请求说明定义为:
        {Q1}    ::= [{W}|{W}{S}{U}]{C}

        {Q2}    ::= [{W}{S}][{U}]{H}{C}

        {U}     ::= 用户名

        {H}     ::= @主机名 | @主机名{H}

        {W}     ::= /W

        {S}     ::= <SP> | <SP>{S}

        {C}     ::= <CRLF>
	递归的{H}表示查询中@主机名字表示的数量不会有特别的限制.在例子{Q2}请求
说明中,@hostname表示的数量限制为2.
	注意{Q1}和{Q2}不是参考从操作系统命令的用户类型"finger 用户@主机".它指
出RUIP确切收到的数据.所以,如果一个用户敲下"finger user@host<CRLF>",远程主机的
RUIP收到和{Q1}对应的"user<CRLF>".
	和IP协议组的任何部分一样,"对接收的信息不限制".

2.4.  RUIP {Q2} 表现
	{Q2}请求信息是发送到另外一个RUIP的请求.RUIP必须或者提供或动态拒绝这个
向前服务(看3.2.1).如某个RUIP提供这个服务,它必须符合下列要求:
	如下:
	主机<H1>打开Finger连接<F1-2>到主机<H2>上的RUIP.
	<H1>给<H2>RUIP一个(Q2}类型的查询<Q1-2>.
	(e.g., FOO@HOST1@HOST2).
它源自:
	主机<H3>是在<Q1-2>最右边的主机(如主机2)
	查询<Q2-3>是<Q1-2>在移去查询中最右端"@HOSTNAME"标志后的剩余.(如FOO@HOST1).
和:
	<H2>RUIP必须自己用<Q2-3>打开一个到<H3>的Finger连接<F2-3>.
	<H2>RUIP必须返回通过<F1-2>从<F2-3>收到的任何信息.
	除了<H3>RUIP关掉<F2-3>连接外,<H2>RUIP必须关掉正常情况下的<F1-2>.
2.5. 期望的RUIP反应:
	大部分情况下,RUIP的结果不是遵循严格的规范,因为它是设计成人看的而
不是机器.它主要是致力于提供信息.任何查询的输出服从安全问题的讨论.
2.5.1   {C}查询
	{C}查询是对所有在线用户的请求.RUIP必须或者回答或者动态拒绝(看3.2.2).
如果RUIP应答,然后它必须至少提供用户的全名.系统管理员应该允许包括其它有用的信
息,例如:
--终端位置
--办公室位置
--办公室电话号码
--工作名称
--空闲时间(自从最后一次输入的分钟数 或自从最后工作起)
2.5.2.  {U}{C} 查询
	{U}{C}查询是针对一个特定用户{U}的深入状态查询.如果确实要拒绝这个服务,
你可能不要在第一位置运行Finger.
	 应答必须至少包括用户全名.如果用户登陆,因为用户必须由{U}{C}返回,所以
至少相同数量的信息返回.
	因为这个是对特定用户的信息查询,系统管理员应该允许返回附加的有用信息(
如3.2.3),例如:
  	- 办公室地址
	- 办公室电话号码
	- 家庭电话号码
	- 登陆状态( 没有登陆成功,注销时间等)
	- 用户信息文件
	用户信息文件是用户在Finger请求应答中留下的短信息特性.(这有时称为"计划"
文件.)这使很容易在用户本地目录或一些公共区域寻找一些特殊命名文本文件;确切的方
式是执行的左边.系统管理员应该允许特定的关掉或打开这个特性.看3.2.4的注意事项.
	用户可能运行程序适应Finger查询.如果这个特性存在,系统管理员应该允许特别
指定打开或关闭它.看3.2.5注意事项.

2.5.3.  {U} 不明确
	在命令行中允许的"名字"必须包括系统定义的"用户名"或"登陆名".如果名字含混
不清,系统管理员应该允许选择是否所有可能的出处按照某种方式返回.(看3.2.6)

2.5.4.  /W 查询记号
	在{Q1}或{Q2}查询类型中的记号/W应该最多在最后一个RUIP解释成用户信息输出更
高冗于层,或者忽略掉.