有关RFC文档的翻译说明 (转)

最新推荐文章于 2024-02-01 20:56:01 发布
最新推荐文章于 2024-02-01 20:56:01 发布
阅读量226 收藏
点赞数
有关RFC文档的翻译说明 (转)[@more@]这些 rfc是jebbthe和我共同翻译的,有些我们不是很肯定的地方,
就保留了原句.RFC文档是网上 编程的基础,希望我们的翻译能对大家
有所帮助.欢迎加入我们的行列,如果有意见,请写信给我们,谢谢!

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10790690/viewspace-950952/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10790690/viewspace-950952/

circularr9834
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
RFC文档(中文翻译版本)
大明的博客
08-25 3万+
RFC文档目录 RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 RFC16 M.I.T RFC18 IMP-IMP和主机-主机控制联接 RFC19_可用来降低有限交换节点阻塞的两条协议性的建议 RFC20_用于网络交换的 A
rfc文档（中文翻译）目前最全的
03-18
目前最全的rfc中文翻译（但仍没有英文版全，我另外上传了英文版的rfc0001-rfc5503），送给需要的朋友。
RFC中文完整版-china-pub-RFC文档中文翻译计划.zip
11-27
RFC中文完整版-china-pub-RFC文档中文翻译计划.zip
RFC文档中文翻译完整版(RFC1 ~~ RFC3093)
04-26
RFC文档中文翻译完整版 ，包括(RFC1 ~~ RFC3093)中的所有协议
中文RFC文档.zip
04-02
RFC 中文文档资源 RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 RFC16 M.I.T RFC18 IMP-IMP和主机-主机控制联接 RFC19 可用来...
RFC4944文档翻译
12-11
本文献更新了RFC4944，“IEEE802.15.4网络上的Ipv6数据包的传输”。本文献详细说明了在低功率无线个人区域网络（6LoWPANs）中Ipv6数据包发送的Ipv6报头压缩格式。压缩格式依赖于共享上下文来对任意的前缀进行压缩。...
rfc3550中文翻译.docx
06-22
《RFC3550中文翻译》是对实时传输协议（RTP）和实时传输控制协议（RTCP）的详细解析，适合于对网络通信、多媒体传输感兴趣的本科生毕业论文参考。RTP和RTCP是互联网工程任务组（IETF）定义的标准，用于支持实时数据...
RFC中文文档-txt
09-11
RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 ...RFC2629 用XML 写I-Ds 和 RFC文档 RFC2633 S/多用途网际邮件扩充协议(MIME)...
rfc中文文档目录，包含部分翻译
07-22
RFC文档目录 RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 RFC16 M.I.T RFC18 IMP-IMP和主机-主机控制联接 RFC19_可用来...
rfc中文翻译
11-21
包含了1-3093的rfc中文翻译。 组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者： 李超（licc_li licc_li@sina.com） 译文发布时间：2001-5-23 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 Network Working Group S. Casner Request for Comments: 2508 Cisco Systems Category: Standards Track V. Jacobson Cisco Systems February 1999 低速串行链路下IP/UDP/RTP数据包头的压缩 （RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links） 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以 得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度 和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要 本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法，它可以降低在低速串行链路上 的网络开销。多数情况下，三个头可压缩到2-4字节。 请赐教并将您的建议发送到工作组邮件列表rem-conf@es.net或直接给作者。 本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”， “建议”，“或许”，“可选的”在 RFC 2119 中解释。 目录 本备忘录的状态 1 版权声明 1 摘要 1 1. 介绍 2 2. 设想和折中 2 2.1. 单工与全双工 3 2.2. 分片与分层 3 3.压缩算法 3 3.1.基本概念 3 3.2 RTP数据包头压缩 4 3.3协议 5 3.4. RTCP控制包压缩 12 3.5.非RTP UDP包压缩 13 4.与分片的交互 13 5.压缩协商 13 6.致谢 14 7.参考文献 14 8. 安全性考虑 14 9.作者地址 15 10.版权声明 15 1. 介绍 随着实时传输协议(RTP)成为正式的RFC[1]发行，人们对于利用RTP实现不同的网络音视 频应用程序间互操作的兴趣也日益增长。然而，我们也注意到，当使用低速链路如14.4Kb/s 或28.8Kb/s拨号时，12字节的RTP头对于仅有20字节的负载而言开销实在太大。（为了减少 头占用的字节，一些已经在类似环境下存在的应用通常使用自定义的协议，而这样做的代价 就是削减了RTP相关的功能。） 事实上，正如在TCP中已经取得巨大成功，也可通过压缩技术来令IP/UDP/RTP包头变小。 这时，压缩可以针对于RTP头（在端到端应用中），或者IP，UDP，RTP的组合头（在Link-by-Link 应用中）。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果，因为两 种情况下的结果大小均为约2-4字节。同时，由于延迟和丢失率都很低，对Link-by-Link应 用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下 IP/UDP/RTP头进行组合压缩。 本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6 和IPv4下使用，这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP 和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三 类。 2. 设想和折中 本压缩方案的目标是，在不发送UDP校验和的情况下，将大多数包的IP/UDP/RTP头压缩到 2个字节，在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和 28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信， 所以协议利用了这点，尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路 上往返时间(RTT)很低，从而实现性能最高。 为了降低低速链路下的延迟，除了在第四节中确定了分片和压缩中可能使用的一些交互 外，本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方 案配合使用。 应该注意到，实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个 处理器支持多达100个拨号调制解调器的数据压缩。因此，如下的考虑都是比较恰当的，即 在设计阶段为了实现简单而牺牲一些通用性，或者在设计上灵活通用但为了简单性可对设计 进行子集化。通过在压缩和解压器之间用更复杂的模型通信改变头字段还可以达成更好的压 缩效果，但其复杂性却是没必要的。下一节将讨论这里列出的一些折中方案。 2.1. 单工与全双工 在没有其它限制的情况下，单工链路上的压缩方案应成为首选。但为防止错误发生，单 工链路上的操作需要用一个含有压缩状态信息的未压缩包头进行周期性的刷新。如果明显的 错误信号可以返回，则恢复延迟也可以实质性地缩短，无错误情况的开销也会降低。为了实 现这些性能的优化，本规范包括了一个可逆向发送的明显错误指示。 在单工链路中，可以使用周期性刷新来取代。解压器一旦侦测到错误存在于某个特定的 流中，它可以简单地放弃该流中所有的包直到接收到一个未压缩的头为止，然后继续解压。 其致命弱点在于可能要在恢复解压前要放弃大量的包。周期性刷新的方法在[3]的3.3节中进 行描述，它应用于单工链路的IP/UDP/RTP压缩，或者应用于其它非TCP包流的高延迟链路。 2.2. 分片与分层 在低速链路上发送大型数据包所需时间而导致的延迟对于单向音频应用不算什么大问 题，因为接收方可以适应延迟变动。但对于交互式的交谈，最小端到端延迟是非常关键的。 对大的，非实时数据包进行分片以允许小的实时包在分片间隙进行传送可以降低这种延迟。 本规范只处理压缩，并且假定，如果包括分片，也将被处理为一个单独层。将分片和压 缩按这种方式进行集成并不可取，因为一旦如此，在没有必要或不可能进行分片的情况下， 连压缩都不能使用。类似地，应该避免预留协议的任何需求。除了要求链路层提供一些包类 型码，一个包长度指示和良好的错误检测外，该压缩方案可独立于任何其它机制而应用在本 地链路的两端。 相反，单独对IP/UDP和RTP层进行压缩丢失了太多的压缩效率，这些效率可以通过将它们 一起对待而得到。由于相同的函数可以应用于所有层，实现跨越这些协议层边界的方案是恰 当的。 3.压缩算法 本文定义的压缩算法主要利用了RFC 1144[2]描述的TCP/IP头压缩的设计。读者可以参考 该RFC获取更多的关于对包头进行压缩的基本动机和通用原理。
RFC大全--中文翻译
12-11
算是很全的RFC了，比看英文省事多了，希望对你有帮助
twamp rfc 协议描述与报文组织结构
05-25
双向链路检测协议，用来检测链路的时延，通过时延分析此条链路的质量好坏。
rfc3711_srtp.pdf
01-09
srtp为安全加密的rtp传输，增加ssl握手协议
关于rfc的文档组织：中国互动出版网
07-28
组织：中国互动出版网（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 译者：马东辉（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 译者：马东辉（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文档中文翻译计划 ＲＦＣ文档中文翻译计划
网络协议---MPL(2)：RFC 7731文档翻译
abatei的专栏
01-06 1874
7、信息库 7.1  本地接口集 本地接口集记录MPL传送者的本地接口。本地接口集由本地接口多元组组成，每个MPL接口对应一个AddressSet。 AddressSet --- 一系列分配给MPL接口的单播地址。 7.2  域集 域集记录了订阅了每个MPL域地址的MPL接口。域集由MPL域多元组组成。每个MPL域对应一个MPLInterfaceSet。
汇总RFC翻译
最新发布
qq_36174006的博客
02-01 1044
准备慢慢的自己将相关的RFC文档翻译一遍。这是一个汇总的列表，后面还会根据自己的需要不断添加需要翻译的文档，以及修改对每个文档的备注。只是个人的学习，不足和错误还请多指教。
[译] 如何阅读 RFC 文档
weixin_33877092的博客
11-18 935
原文：How to Read an RFC 作者：Mark Nottingham 发表时间：31 July 2018 译者：西楼听雨 发表时间： 2018/11/19 (转载请注明出处) For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. Th...
RFC中文翻译计划
如是我闻
02-03 791
藏锋者: http://www.cangfengzhe.com/cdrfc/list_67_2.html BSD爱好者乐园: http://www.bsdlover.cn/html/5/category-catid-5.html 中国协议分析网  http://www.cnpaf.net/Class/RFC/200411/1054.html
rfc 文档大全 下载
11-01
RFC（Request for Comments）是一系列的技术文档，其中包括了Internet标准、协议以及相关议题的讨论。RFC文档涵盖了计算机网络、通信协议、互联网技术等多个领域。 想要下载RFC文档大全非常简单。首先，你可以直接...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值