POP3协议RFC1939中文文档

组织: 中国互动出版网( http://www.china-pub.com/

RFC 文档中文翻译计划( http://www.china-pub.com/compters/emook/aboutemook.htm

E-mail ouyang@china-pub.com

译者: 顾国飞( ggfei  ggfei@263.net

译文发布时间: 2001-4-10

版权: 本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

 

 

Network Working Group                                           J. Myers

Request for Comments: 1939                               Carnegie Mellon

STD: 53                                                           M. Rose

Obsoletes: 1725                             Dover Beach Consulting, Inc.

Category: Standards Track                                       May 1996

 

 

RFC1939-POP3 协议

RFC1939  Post Office Protocol - Version 3

 

本备忘录状态

   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.

 

 

目录

1. 简介 ........................................................................................................................ 2

2. 简单说明 ................................................................................................................ 2

3. 基本操作 ................................................................................................................ 3

4. " 确认" 状态 ........................................................................................................... 3

5. " 操作" 状态 ........................................................................................................... 5

6." 更新" 状态 ............................................................................................................. 5

7. 可选的POP3 命令 .................................................................................................. 5

8. POP3 命令总结 ..................................................................................................... 7

9. POP3 会话实例 ..................................................................................................... 8

10. 消息格式 ............................................................................................................. 9

11. 安全性考虑 ......................................................................................................... 9

12. 参考资料 ............................................................................................................. 9

14. 致谢 ...................................................................................................................... 9

15. 作者地址 ........................................................................................................... 10

Appendix A. Differences from RFC 1725 .................................................. 10

Appendix B. Command Index ............................................................................. 11

 

 

1. 简介

  对于在网络上的比较小的结点,支持消息传输系统( MTS )是不实际的。例如,一台工作站可能不具有充足的资源允许 SMTP 服务器和相当的本地邮件传送系统保持序驻留,并持续运行。同样的,将一台个人计算机长时间连接在 IP 类型网络上的费用也是可观的(结点缺少的资源被称为 " 联络性 " )。

  虽然如此,在这样的小结点上允许管理邮件是十分有用的,并且这些结点经常支持一个用户代理来管理邮件。为解决这一问题,能够支持 MTS 的结点就为这些不能支持的结点提供了邮件存储功能。邮局协议 - 版本 3 就是使这样的工作站可以用一种比较实用的方法来访问存储于服务器上的储存邮件。通常,这意味着工作站可以从服务器上取得邮件,而服务器为它暂时保存邮件。

  在下文中,客户主机指的是利用 POP3 服务的主机,而服务器主机指的是提供 POP3 服务的主机。

2. 简单说明

  在此文档中不指明客户主机如何将邮件送入到传送系统中去。但这里有一个说明:当用户代理需要将信息送到传送系统时,它在接力主机上建立 SMTP 连接(这些接力主机可以是 POP3 主机,也可以不是)。

3. 基本操作

  初始时,服务器通过侦听 TCP 端口 110 开始 POP3 服务。当客户主机需要使用服务时,它将与服务器主机建立 TCP 连接。当连接建立后, POP3 发送确认消息。客户和 POP3 服务器相互(分别)交换命令和响应,这一过程一直要持续到连接终止。

   POP3 命令由一个命令和一些参数组成。所有命令以一个 CRLF 对结束。命令和参数由可打印的 ASCII 字符组成,它们之间由空格间隔。命令一般是三到四个字母,每个参数却可达 40 个字符长。

   POP3 响应由一个状态码和一个可能跟有附加信息的命令组成。所有响应也是由 CRLF 对结束。现在有两种状态码, " 确定 " ("+OK") " 失败 " ("-ERR")

  对于特定命令的响应是由许多字符组成的。在这些情况中,下面一一表述:在发送第一行响应和一个 CRLF 之后,任何的附加信息行发送,他们也由 CRLF 对结束。当所有信息发送结束时,发送最后一行,包括一个结束字符(十进制码 46 ,也就是 "." )和一个 CRLF 对。如果信息中的任何一行以结束字符开始,此行就是通过在那一行预先装入结束而进行字符填充的。因此,多行响应由五个 CRLF.CRLF 结束。当检测多行响应时,客户检测以确认此行是否以结束字符开始。如果是的,而且其后的字符不是 CRLF ,此行的第一个字符(结束字符)将被抛弃;如果其后紧跟 CRLF ,从 POP 服务器来的响应终止,包括 .CRLF 的行也不被认为是多行响应的一部分了。

  在生命周期中, POP3 会话有几个不同的状态。一旦 TCP 连接被打开,而且 POP3 服务器发送了确认信息,此过程就进入了 " 确认 " 状态。在此状态中,客户必须向 POP3 服务器确认自己是其的客户。一旦确认成功,服务器就获取与客户邮件相关的资源,此时这一过程进入了 " 操作 " 状态。在此状态中,客户提出服务,当客户发出 QUIT 命令时,此过程进入了 " 更新 " 状态。在此状态中, POP3 服务器释放在 " 操作 " 状态中取得的资源,并发送消息,终止连接。

   POP3 服务器可以拥有一个自动退出登录的记时器。此记时器必须至少可以记录 10 分钟。这样从客户发送的消息才可能刷新此记时器。当记时器失效时, POP3 会话并不进入 " 更新 " 状态,而是关闭 TCP 连接,而且不删除任何消息,不向客户发送任何响应。

4. " 确认" 状态

  一时 TCP 连接由 POP3 客户打开, POP3 服务器发送一个单行的确认。这个消息可以是由 CRLF 结束的任何字符。例如,它可以是:

     S: +OK POP3 server ready

  注意:这个消息是一个 POP3 应答。 POP3 服务器应该给出一个 " 确定 " 响应作为确认。

  此时 POP3 会话就进入了 " 确认 " 状态。此时,客户必须向服务器证明它的身份。在文档中介绍两种可能的处理机制,一种是 USER PASS 命令,另一种是在后面要介绍的 APOP 命令。

  用 USER PASS 命令进行确认过程,客户必须首先发送 USER 命令,如果 POP3 服务器以 " 确认 " 状态码响应,客户就可以发送 PASS 命令以完成确认,或者发送 QUIT 命令终止 POP3 会话。如果 POP3 服务器返回 " 失败 " 状态码,客户可以再发送确认命令,或者发送 QUIT 命令。

  当客户发送了 PASS 命令后,服务器根据 USER PASS 命令的附加信息决定是否允许访问相应的存储邮件。

  一旦服务器通过这些数据决定允许客户访问储存邮件,服务器会在邮件上加上排它锁,以防止在进入 " 更新 " 状态前对邮件的改变。如果成功获得了排它锁,服务器返回一个 " 确认 " 状态码。会话进入 " 操作状态 " ,同时没有任何邮件被标记为删除。如果邮件因为某种原因不能打开(例如,排它锁不能获得,客户不能访问相应的邮件或者邮件不能进行语法分析),服务器将返回 " 失败 " 状态码。在返回 " 失败 " 状态码后,服务器会关闭连接。如果服务器没有关闭连接,客户可以重新发送确认命令,重新开始,或者发送 QUIT 命令。

  在服务器打开邮件后,它为每个消息指定一个消息号,并以八进制表示每个消息的长度。第一个消息被指定为 1 ,第二个消息被指定为 2 ,以此类推,第 N 个消息被指定为 N 。在 POP3 命令和响应中,所以的消息号和长度以十进制表示。

  下面是对上述三条命令的总结:

 



5. " 操作" 状态

  一旦客户向服务器成功地确认了自己的身份,服务器将锁住并打开相应的邮件,这时 POP3 会话进入 " 操作 " 状态。现在客户可以重复下面的 POP3 命令,对于每个命令服务器都会返回应答。最后,客户发送 QUIT 命令,会话进入 " 更新 " 状态。

下面是在 " 操作 " 状态中可用的命令:

6." 更新" 状态

  当客户在 " 操作 " 状态下发送 QUIT 命令后,会话进入 " 更新 " 状态。(注意:如果客户在 " 确认 " 状态下发送 QUIT 后,会话并不进入 " 更新 " 状态。)

  如果会话因为 QUIT 命令以外的原因中断,会话并不进入 " 更新 " 状态,也不从服务器中删除任何信件。

7. 可选的POP3 命令

  以上讨论的命令是对 POP3 服务的最小实现。以下说明的可选命令允许客户更方便地处理信件,这是一个比较一般的 POP3 服务实现。

  · TOP msg n

  【参数】一个是未被标记为删除的信件数,另一个是非负数(必须提供)

  【限制】仅在 " 操作 " 状态下使用。

  【说明】

  如果服务器返回 " 确认 " ,响应是多行的。在初始的 +OK 后,服务器发送信件头,一个空行将信件头和信件体分开,对于多行响应要注意字节填充终止符。

  注意:如果客户要求的行数比信件体中的行数大,服务器会发送整个信件。

  【响应】 +OK :其后有信件头;

   -ERR :其后无类似消息。

  【例子】

   C: TOP 1 10

   S: +OK

   S: < 服务器发送消息头,一个空行和信件的头 10 >

   S: .

   ...

   C: TOP 100 3

   S: -ERR no such message

 

  · UIDL [msg]

  【参数】信件数(可选)。如果给出信件数,不包括被标记为删除的信件。

  【限制】仅在 " 操作 " 状态下使用。

  【说明】

  如果给出了参数,且 POP3 服务器返回包括上述信息的 " 确认 " ,此行称为信息的 " 独立 -ID "

  如果没有参数,服务器返回 " 确认 " 响应,此响应便以多行给出。在初的 +OK 后,对于每个信件,服务器均给出相应的响应。此行叫做信件的 " 独立 -ID "

  为简化语法分析,所有服务器要求使用独立 -ID 表的特定格式。它包括空格和信件的独立 -ID

  信件的独立 -ID 0x21 0x7E 字符组成,这个符号在给定的存储邮件中不会重复。

  注意:信件不包括被标记为删除的信件。

  【响应】 +OK :其后是独立 -ID 表;

   -ERR :其后无类似信件。

  【例子】

   C: UIDL

   S: +OK

   S: 1 whqtswO00WBw418f9t5JxYwZ

   S: 2 QhdPYR:00WBw1Ph7x7

   S: .

   ...

   C: UIDL 2

   S: +OK 2 QhdPYR:00WBw1Ph7x7

   ...

   C: UIDL 3

   S: -ERR no such message, only 2 messages in maildrop

 

  · APOP name digest

  【参数】指定邮箱的字串和 MD5 摘要串。

  【限制】仅在 POP3 确认后的 " 确认 " 状态中使用。

  【说明】通常,每个 POP3 会话均以 USER/PASS 互换开始。这导致了用户名和口令在网络上的显式传送,这不会造成什么危险。但是,许多客户经常连接到服务检查信件。通常间隔时间比较短,这就加大了泄密的可能性。

另一种提供 " 确认 " 过程的方法是使用 APOP 命令。

  实现 APOP 命令的服务器包括一个标记确认的时间戳。例如:在 UNIX 上使用 APOP 命令的语法为: process-ID.clock@hostname ,其中进程 -ID 是进程的十进制的数,时钟是系统时钟的十进制表示,主机名与 POP3 服务器名一致。

  客户记录下此时间戳,然后以送 APOP 命令。 name 语法和 USER 命令一致。 Digest 是采用 MD5 算法产生的包括时间戳和共享密钥的字串。此密钥是客户和服务器共知的,应该注意保护此密钥,如果泄密,任何人都能够以用户身份进入服务器。

  如果服务器接到 APOP 命令,它验证 digest ,如果正确,服务器返回 " 确认 " ,进入 " 操作 " 状态;否则,给出 " 失败 " 并停留在 " 确认 " 状态。

  注意:共享密钥的长度增加,解读它的难度也相应增加,这个密钥应该是长字符串。

  【响应】 +OK :邮件锁住并准备好;

   -ERR :拒绝请求。

  【例子】

   S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>

   C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

   S: +OK maildrop has 1 message (369 octets)

  在此例子中,共享密钥 <1896.697170952@dbc.mtview.ca.us>tanstaaf MD5 算法生成,它产生了 digest 值, c4c9334bac560ecc979e58001b3e22fb

8. POP3 命令总结

基础的 POP3 命令:

USER name " 确认 " 状态有效

PASS string

QUIT

 

STAT " 操作 " 状态有效

LIST [msg]

RETR msg

DELE msg

NOOP

RSET

 

QUIT " 更新 " 状态有效

 

可选的 POP3 命令:

APOP name digest " 确认 " 状态有效

TOP msg n " 操作 " 状态有效

UIDL [msg]

 

POP3 响应:

+OK

-ERR

 

注意:除了 STAT LIST UIDL 的响应外,其它命令的响应均为 "+OK" "-ERR" 。响应后的所有文本将被客户略去。

9. POP3 会话实例

S: < 等待连接到 TCP 端口 110>

C: < 打开连接 >

S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: +OK mrose's maildrop has 2 messages (320 octets)

C: STAT

S: +OK 2 320

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: RETR 1

S: +OK 120 octets

S: < 服务器发送信件 1>

S: .

C: DELE 1

S: +OK message 1 deleted

C: RETR 2

S: +OK 200 octets

S: < 服务器发送信件 2>

S: .

C: DELE 2

S: +OK message 2 deleted

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

C: < 关闭连接 >

S: < 等待下一次连接 >

10. 消息格式

  在会话过程中的消息格式都假定与 Internet 文本消息格式标准一致。应该注意的是,由于各个服务器对于换行符的处理不同,因此计数不一定相同。通常,在 " 确认 " 状态中,服务器能够以八进制计算信件的大小。例如,如果在打开储存邮件时服务器内部认定换行符代表一个字符,一般服务器在计算它时作为两个字符计。注意,以终止符开始的消息行不被计数两次,因为客户将在接收到多行响应后删除所有字节填充。

11. 安全性考虑

  可以推测,使用 APOP 命令可以提供会话期间的保护。相应的,同时实现 PASS APOP 命令的服务器只允许用户以一种方式访问;也就是说要么使用 USER/PASS 组合,要么使用 APOP 命令,不能同时使用两个。

而且,注意随着共享密钥长度的增加,解读的难度也就上升了。服务器要提供用户名时不给出任何响应,不给出任何暗示此用户名是否正确。而口令却在网络上显式传送;使用 RETR TOP 命令在网络上显式传送信件。

12. 参考资料

   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

       821, USC/Information Sciences Institute, August 1982.

 

   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text

       Messages", STD 11, RFC 822, University of Delaware, August 1982.

 

   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,

       MIT Laboratory for Computer Science, April 1992.

 

   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version

        4", RFC 1730, University of Washington, December 1994.

 

   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,

       Carnegie Mellon, December 1994.

 

14. 致谢

   The POP family has a long and checkered history.  Although primarily

   a minor revision to RFC 1460, POP3 is based on the ideas presented in

   RFCs 918, 937, and 1081.

 

   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff

   provided significant comments on the APOP command.

15. 作者地址

   John G. Myers

   Carnegie-Mellon University

   5000 Forbes Ave

   Pittsburgh, PA 15213

 

   EMail: jgm+@cmu.edu

 

   Marshall T. Rose

   Dover Beach Consulting, Inc.

   420 Whisman Court

   Mountain View, CA  94043-2186

 

   EMail: mrose@dbc.mtview.ca.us

Appendix A. Differences from RFC 1725

   This memo is a revision to RFC 1725, a Draft Standard.  It makes the

   following changes from that document:

 

      - clarifies that command keywords are case insensitive.

 

      - specifies that servers must send "+OK" and "-ERR" in

        upper case.

 

      - specifies that the initial greeting is a positive response,

        instead of any string which should be a positive response.

 

      - clarifies behavior for unimplemented commands.

 

      - makes the USER and PASS commands optional.

 

       - clarified the set of possible responses to the USER command.

 

      - reverses the order of the examples in the USER and PASS

        commands, to reduce confusion.

 

      - clarifies that the PASS command may only be given immediately

        after a successful USER command.

 

      - clarified the persistence requirements of UIDs and added some

        implementation notes.

 

      - specifies a UID length limitation of one to 70 octets.

 

      - specifies a status indicator length limitation

        of 512 octets, including the CRLF.

 

      - clarifies that LIST with no arguments on an empty mailbox

        returns success.

 

      - adds a reference from the LIST command to the Message Format

        section

 

      - clarifies the behavior of QUIT upon failure

 

      - clarifies the security section to not imply the use of the

        USER command with the APOP command.

 

      - adds references to RFCs 1730 and 1734

 

      - clarifies the method by which a UA may enter mail into the

        transport system.

 

      - clarifies that the second argument to the TOP command is a

        number of lines.

 

      - changes the suggestion in the Security Considerations section

        for a server to not accept both PASS and APOP for a given user

        from a "must" to a "should".

 

      - adds a section on scaling and operational considerations

 

Appendix B. Command Index

       APOP .......................................................   15

       DELE .......................................................     8

       LIST .......................................................    6

       NOOP .......................................................    9

       PASS .......................................................   14

       QUIT .......................................................    5

       QUIT .......................................................   10

       RETR .......................................................    8

       RSET .......................................................    9

       STAT .......................................................    6

       TOP ........................................................   11

       UIDL .......................................................   12

       USER .......................................................   13

 

 

 

组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1 RFC文档中文翻译计划组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1 RFC文档中文翻译计划组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:马东辉(eaststone ) 译文发布时间:2001-4-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。 Network Working Group D. Waitzman Request For Comments: 1073 BBN STC October 1988 RFC1073 Telnet窗口尺寸选项 (RFC1073 Telnet Window Size Option) 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 目录 1.命令名称和选项代码 2 2. 命令含义 2 3. 默认的规范 3 4. 动机 3 5.描述和实现的注释 4 6.例子 4 7. 致谢 5 1.命令名称和选项代码   名称= NAWS (Negotiate About Window Size)协商窗口的尺寸   代码=31 2. 命令含义   IAC WILL NAWS   由Telnet客户端发送来建议使用NAWS.   IAC WON'T NAWS   由Telnet客户端发送来拒绝使用NAWS.   IAC DO NAWS   由Telnet服务器端发送来建议使用NAWS.   IAC DON'T NAWS   由Telnet服务器端发送来拒绝使用NAWS.   IAC SB NAWS <16-bit value> <16-bit value> IAC SE   由Telnet客户端发送,通知Telnet服务器端这个窗口的宽度和高度。窗口尺寸信息从Telnet客户端到Telnet服务器端通过这个选项来传递。此信息是参考性的。服务器可能接受这个选项,但是并不使用传递的信息。   客户端和服务器端使用标准的Telnet WILL/DO/DON'T/WON'T机制来协商发送窗口尺寸信息。如果客户端和服务器端都同意,客户端可以发送一个子协商用来传递窗口的尺寸。如果以后客户端的窗口尺寸改变了(例如,窗口尺寸被用户改变),客户端可能再次发送这个子协商。因为在某些操作系统上,服务器正在执行的时候可能不允许更新窗口尺寸信息,所以服务器可能在接受最初的窗口尺寸后发送一个DON'T NAWS给客户端以阻止更多的子协商。一个协商循环将不会形成下面这些规则。   子协商包含两个值,用字符表示的窗口的宽度值和高度值。这两个值中的每一个值都是以两个字节为一组以标准的Internet字节和比特顺序发送的。这就允许窗口的宽度或高度的最大值是65535个字符。对于宽度或高度来说,接受一个等于零的值就意味着没有字符宽度或高度被发送。既然如此,Telnet服务器将假定宽度或高度是与操作系统相关的(它将有可能是基于终端类型信息的,这个终端类型信息是使用TERMINAL TYPE的Telnet选项来发送的)。   子协商的语法是   IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE   象Telnet协议所要求的那样,在子协商中任何出现255的地方都必须显示两次。为了和IAC(它有一个255的值)字符区别。 3. 默认的规范   WON'T NAWS   DON'T NAWS   这个选项不假定任何默认的窗口尺寸信息。通常由TERMINAL TYPE Telnet选项传递的终端类型可能暗示着一个窗口尺寸,但是对于这个选项,那是不必要的。 4. 动机   随着窗口系统的日益流行,Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标,需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸,更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。 Telnet选项:协商输出行宽(NAOL)和协商输出页尺寸(NAOP)在语义上并不是很恰当,他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的(也就是说服务器可以控制客户端的行宽或者页尺寸),在每一轴中限制253个字符。   这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸,只是简单地告诉服务器当前的窗口是多大。而且,253个字符的高度和宽度的限制非常低,所以,新的选项具有65535字符的限制。最后,这个选项同时发送窗口的高度和宽度,因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。 5.描述和实现的注释   这个选项的典型用户可能是运行在X Window下的Telnet客户端。在用户调整了客户端窗口的尺寸后,一定会和Telnet客户端通信。在4.3BSD Unix中,信号SIGWINCH(窗口改变)可能被Telnet客户端捕获并且一个新的NAWS子协商会被发送到服务器端。在接收到NAWS子协商后,服务器可能作出适当地ioctl来处理这个新的消息,然后发出SIGWINCH信号给它的子进程,可能是一个shell。 6.例子   在下列的例子中,数据流中的所有数字都是十进制。 1). 服务器建议,客户端同意使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WILL NAWS   (客户端发送)IAC SB NAWS 0 80 0 24 IAC SE   [窗口80字符宽,24字符高]   [某个时刻用户改变了窗口尺寸]   (客户端发送)IAC SB NAWS 0 80 0 64 IAC SE   [窗口80字符宽,64字符高]   所有的数字形式   (服务器发送)255 253 31   (客户端发送)255 253 31   (客户端发送)255 250 31 0 80 0 24 255 240   (客户端发送)255 250 31 0 80 0 64 255 240 2).客户端建议,服务器同意使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC SB NAWS 1 44 0 24 IAC SE   [窗口300字符宽,24字符高] 3). 客户端建议,服务器拒绝使用NAWS   (客户端发送)IAC WILL NAWS   (服务器发送)IAC DON'T NAWS 4). 服务器建议,客户端拒绝使用NAWS   (服务器发送)IAC DO NAWS   (客户端发送)IAC WON'T NAWS 7. 致谢   一个基于X window系统的这个选项的更加详细的版本已经由Glenn Marcy和作者本人在Carnegie-Mellon大学实现。它在Carnegie-Mellon大学的计算机系被广泛地使用。Marcy先生帮助撰写了此备忘录的早期版本,记录了更多的选项。 RFC1073 Telnet Window Size Option RFC1073 Telnet窗口尺寸选项 1 1组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者:王翌(mcsewang mcsewang@21cn.com) 译文发布时间:2001-6-10 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须 保留本文档的翻译及版权信息。 Network Working Group S. Crocker RFC-10 UCLA 21 July 1969 文档规范 (RFC10 ── DOCUMENTATION CONVENTIONS) 此规范是NWG/RFC # 3 的修订版。 网络工作组(Network Working Group)包括来自尤他洲的Steve Carr,SRI 的 Elmer Shapiro 和 Bill English,UCLA的Steve Crocker,RAND 的 John Haefner,林肯实验室的 Paul Rovner 和 Jim Curry,成员资格没有限制。 网络工作组(Network Working Group:NWG)关注主机软件、网络使用策略及网络应 用中的初始经验。 NWG工作文档通过类似于本文的笔记形式纪录。这种文档可以由任何站点的任何人发 布并包括在这个系列中。 内容 NWG文件记录的可以是任何想法、建议等与主机软件或网络的其他特征相关的内容。 文件不一定要文辞精美,但应尽量保证内容的时效性和及时性。以下几种内容的文档也可以, 如:纯粹的立场观点的表述,而没有举出实例和其他一些细节;提出特别的建议或执行技巧 而没有给出相关的背景解释;只是明白的提出一个问题而没有给出任何解答。一份文档要求 不少于一句话。 这些标准是基于下面两个原因制定的:第一,人们倾向于将文件记录当成事实上的权 威,我们希望推动交流和讨论而不是听信权威性的结论。第二,人们通常不愿发表一些未认 真雕琢过的文章,我们希望消除这种顾虑。 格式 每篇NWG 文档都应该包括下列信息: 1. “ Network Working Group ” “ Request for Comnments : X”( X下划线 ) 其中X是一个序号,它由UCLA的Steve Crocker 给出 2. 作者及合作人 3. 日期 4. 题目 标题不要求唯一 发布 笔记的一份拷贝由作者的站点发至下列成员: 1. Steve Crocker, UCLA 2. Ron Stoughton, UCSB 3. Elmer Shapiro, SRI 4. Steve Carr, Utah 5. John Haefner, RAND 6. Paul Rovner, LL 7. Bob Kahn, BB&N 8. Larry Roberts, ARPA 9. Jerry Cole, SDC 若有需要,副本可以在本地自行处理。 地址 以下是最新的地址,必要时请更正: Steve Crocker UCLA 3732 Boelter Hall (213) 825-4864 UCLA 825-2543 Sec'y Los Angeles, California 90024 Ron Stoughton UCSB Computer Research Lab. (805) 961-3221 UCSB Santa Barbara, California 93106 Elmer Shapiro SRI Stanford Research Institute (415)326-6200 333 Ravenswood Menlo Park, California 94025  Steve Carr Utah Computer Science Dept. (801) 322-8224 University of Utah Salt Lake City, Utah 84ll2 John Haefner RAND The Rand Corp. (213) 393-0411 1700 Main Street Santa Monica, California 90406 Paul D. Rovner LL Mass. Inst. of Tech. (617) 662-5500 Lincoln Laboratory B-115 X7211 P.O. Box 73 Lexington, Mass. 02173 Robert Kahn BBN Bolt, Beranek and Newman (617) 491-1850 50 Moulton St. 49l-1868 Cambridge, Mass. 02138 Larry Roberts ARPA ODS/ARPA (202) OX 7-8663 3D167 Pentagon OX 7-8654 Washington, D.C. 2030l Jerry Cole SDC 7842 Croyden 2500 Colorado L.A., California 90045 Santa Monica, California 90406 (213) 393-9411 X438 X6019 Sec'y RFC10 DOCUMENTATION CONVENTIONS 文档规范 1 RFC文档中文翻译计划 RFC文档中文翻译计划
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值