关于rfc的文档组织：中国互动出版网

【文件属性】：

文件名称：关于rfc的文档组织：中国互动出版网

文件大小：1.86MB

文件格式：RAR

更新时间：2014-08-17 11:27:53

rfc

组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：[e-mail] 译者：马东辉（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：[e-mail] 译者：马东辉（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：[e-mail] 译者：马东辉（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：[e-mail] 译者：王翌（mcsewang [e-mail]） 译文发布时间：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 [phone] UCLA 825-2543 Sec'y Los Angeles, California 90024 Ron Stoughton UCSB Computer Research Lab. [phone] UCSB Santa Barbara, California 93106 Elmer Shapiro SRI Stanford Research Institute [phone] 333 Ravenswood Menlo Park, California 94025  Steve Carr Utah Computer Science Dept. [phone] University of Utah Salt Lake City, Utah 84ll2 John Haefner RAND The Rand Corp. [phone] 1700 Main Street Santa Monica, California 90406 Paul D. Rovner LL Mass. Inst. of Tech. [phone] Lincoln Laboratory B-115 X7211 P.O. Box 73 Lexington, Mass. 02173 Robert Kahn BBN Bolt, Beranek and Newman [phone] 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 [phone] X438 X6019 Sec'y RFC10 DOCUMENTATION CONVENTIONS 文档规范 1 RFC文档中文翻译计划 ＲＦＣ文档中文翻译计划