組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：盧伍春（spacelu   wuchun_lu@xanet.edu.cn）
譯文發布時間：2001-6-15
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。



網絡工作組                                       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解釋成用戶信息輸出更
高冗于層,或者忽略掉.