RFC2231翻译:MIME参数值和编码字的扩展

  • 摘要

本文档定义了对RFC2045媒体类型和RFC2183的disposition参数值机制的扩展,以提供:

  1. 在US-ASCII以外的字符集中指定参数值的方法。
  2. 在显示值时指定要使用的语言。
  3. 用于长参数值的机制,以避免header行换行的问题。

此文档还定义了RFC2047中定义的encoded word的扩展。

  • 介绍

MIME定义了一种消息格式,可以用于发送非US-ASCII字符集的文本消息主体,非文本的消息主体,多部分的消息主体,以及非US-ASCII字符集的文本头信息。

MIME现在被广泛部署,并被各种互联网协议使用,当然包括互联网邮件。然而,MIME的成功导致了对原始协议规范中未提供的其他机制的需求。

在content-type和content-disposition后面跟着许多参数,这固有地施加了三个关键的限制:在电子邮件头域中的行被依照RFC822的规则折叠了,这使得长参数值出现了问题;MIME头被限制在7bit US-ASCII的形式,而RFC2047中的encoded-word机制不可用于参数值,这使得在不指定某种私有编码的情况下不可能在US-ASCII以外的字符集中写参数值;字符集信息不足以正确显示某种类型的信息,还需要语言信息。

本文档定义了解决这些限制的扩展,所有这些扩展都是以一种与现有的MIME实现在语法方面完全兼容的方式实现的。此外,这些扩展被设计为对MIME的现有使用产生尽可能小的影响。

重要提示,这些机制最终在实际使用时显得有些冗长。因此,这些机制不应轻而易举地使用,它们应该保留在真正需要它们的情况下。

  • 参数值延续

长参数值与header行包装约定的相合性不好,特别是标准的header行换行取决于LWSP的位置,LWSP可能存在于参数值中,也可能不存在于参数值中,即使存在也可能无法识别,因为执行行包装的代理可能没有参数值格式的特定知识。结果是,长参数行可能会因为错误的换行实现而被截断或损坏。

因此,需要一种机制将参数值分解成更小的单元,这些单元可以进行换行。任何此类机制都必须与现有的mime处理器兼容,这意味着:

  1. 这种机制绝不能改变MIME的type行与disposition行的格式。
  2. 这种机制不能依赖于参数顺序,因为MIME声明参数不区分顺序。注意,虽然MIME确实禁止在传输过程中修改MIME头,但仍然有可能在用户代理级别处理时把参数重排序。

那么,显而易见的解决方案是使用多个参数来包含单个参数值,并使用某种可分辨的名称来指明这里执行了这样的操作。这个解决方案正是这里指定的:后跟十进制数字的星号(*)被用来指示正在使用多个参数来封装单个参数值,数字从0开始每个参数部分加1,数字不允许有前导的0,也不允许有数字被跳过。通过按顺序连接参数的各个部分,可以恢复原始参数值。

For example, the content-type field

 

        Content-Type: message/external-body; access-type=URL;

         URL*0="ftp://";

         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

 

is semantically identical to

 

        Content-Type: message/external-body; access-type=URL;

          URL=ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar

注意,参数值的引号是参数值语法的一部分,它们不是参数值本身的一部分,此外,还明确允许混合使用带引号和不带引号的延续字段。

  • 参数值的字符集与语言信息

某些参数值可能需要使用字符集或语言信息来进行限定,很明显需要一个可分辨的参数名来标识此信息何时出现,以及参数值本身中信息的特定语法。此外,还需要一种轻量级的编码机制来在参数值中容纳8位信息。

星号(*)被用来在参数名中指示语言和字符集信息存在且编码被使用,单引号(‘)用于在参数值开头分割字符集和语言信息,百分号(%)用于编码标志。具体来说,在参数名末尾的星号用于表明字符集和语言信息可能出现在参数值的开头;单引号用于分割参数集字符串中的字符集、语言信息、实际参数值;百分号用于标记十六进制编码的八位字节。

For example:

        Content-Type: application/x-stuff;

         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

请注意,完全允许将字符集或语言信息字段留空,还要注意,即使省略了其中一个字段值,单引号分隔符也必须存在。不能通过省略字符集或语言信息来指示默认字符集或语言——参数字段不能指定默认字符集或语言。

       4.1 字符集、语言信息与参数延续一起使用

字符集、语言信息与参数延续可以一起使用,举个例子:

   Content-Type: application/x-stuff

    title*0*=us-ascii'en'This%20is%20even%20more%20

    title*1*=%2A%2A%2Afun%2A%2A%2A%20

    title*2="isn't it!"

注意:

  1. 语言和字符集信息只出现在参数值的开头。
  2. 参数延续不提供在同一参数值中使用多个字符集或语言的功能。
  • Encoded Words中的语言信息

       鉴于使用encoded words的字段是用于显示的,有时需要将语言信息与编码的单词以及字符集关联起来。本规范扩展了encoded words的定义,以允许包含此类信息,这只需在字符集规范后加上星号和语言标记即可完成。例如:

From: =?US-ASCII*EN?Q?Keith_Moore?= moore@cs.utk.edu

  • IMAP4处理参数值

IMAP4服务器生成BODY与BODYSTRUCTURE的fetch响应时应该对参数值延续解码。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
RFC文档目录 RFC1 主机软件 RFC2 主机软件 RFC3 文档规范 RFC4 网络时间表 RFC6 与 Bob Kahn 会话 RFC10 文档规范 RFC13 零文本长度的EOF信息 RFC16 M.I.T RFC18 IMP-IMP和主机-主机控制联接 RFC19_可用来降低有限交换节点阻塞的两条协议性的建议 RFC20_用于网络交换的 ASCII 格式 RFC21 网络会议 RFC22 主机-主机控制信息格式 RFC23_多重传送的调节信息 RFC24 文档规范 RFC25 不使用高的连接号 RFC27 文档规范 RFC28 时间标准 RFC29 响应 RFC 28 RFC30 文档规范 RFC32 关于SRI所提议的实时时钟的一些想法 RFC34 关于ARC时钟的一些初步记录摘要 RFC35 网络会议 RFC36 协议注解 RFC37 网络会议结尾等 RFC38 NWG/RFC #36 网络协议的注解 RFC40 关于未来协议的更多注解 RFC41 IMP-IMP 通讯信息 RFC42 信息数据类型 RFC43 被提议的会议 RFC45 关于未来协议的更多注解 RFC53 官方协议机构 RFC58 逻辑信息同步 RFC60 简单的 NCP 协议 RFC63 迟来的网络会议报告 RFC66 NIC - 第三级别的想法和其它噪音 RFC69 提议改变 主机/IMP 规范来消除标记 RFC71 输入错误后的再分配 RFC72 建议改变网络协议延期执行 RFC73 响应 NWG/RFC 67 RFC75 网络会议 RFC78 NCP状态报告:UCSB/RAND RFC79 圆木协议错误 RFC81 涉及信息的请求 RFC84 NWG/RFC的1-80列表 RFC85 网络工作组会议 RFC90 CCN 作为一种网络服务中心 RFC99 网络会议 RFC101 对1971年2月17日伊利诺斯州的Urbana的网络工作组会议的注释 RFC102 主机-主机 协议故障清除委员会的说明 RFC103 中断键的执行 RFC104 连接 191 RFC105 通过 UCSB 进行远程登录和远程输出返回的网络说明书 RFC106 用户/服务器 站点协议的网络主机问卷 RFC107 主机-主机 协议故障清除委员会的说明 RFC108 1971年2月17-19日在 Urbana 举行的 NWG 会议的人员列表 RFC124 在 RFC 107 中有印刷错误 RFC132 RFC 107 的排版错误 RFC148 RFC 123 的注释 RFC149 最好的铺设计划 RFC154 风格显示 RFC156 伊利诺斯州站点的状态: 响应 RFC 116 RFC179 连接的数分配 RFC185 NIC 分发手册 RFC188 数据管理会议公告 RFC198 站点证明-林肯实验室 360/67 RFC204_利用报路 RFC218 改变 IMP 状态报告设备 RFC228 澄清 RFC232 网络图形会议延缓 RFC245 预定网络工作组会议 RFC246 网络图形会议 RFC256 IMPSYS 变更通知 RFC276 NIC过程 RFC285 网络图形 RFC324 RJE 协议会议 RFC335 新界面 - IMP/360 RFC348_放弃过程 RFC404 文件迁移协议的注释 RFC405 给 TIP 用户的第二封信 RFC456 UCSB 的数据重置服务 RFC457_FTP 的服务器与服务器交互 RFC496 IMP/TIP 内存更新时间表(修订版 2) RFC516 丢失消息的检测 RFC591 在 NVT ASCII UCSB和在线系统之间的实验输入映象 RFC621 “注意圣诞节的时候要把长袜挂在烟囱下面” RFC628 更深的数据语言的设计观念 RFC634 最近的网络图 RFC637 SU-DSL网络地址的更改 RFC677 双重数据库的维护 RFC692 对于IMP/HOST 协议的改动的注释 (RFCS 687 AND 690) RFC697_FTP的CWD命令 RFC698_Telnet扩展ASCII选项 RFC763 角色邮箱 RFC775_面向目录的 FTP 命令 RFC779_Telnet发送-位置选项 RFC792_Internet 控制信息协议 RFC797 位图文件格式 RFC821_简单邮件传输协议 RFC826_以太网地址转换协议或转换网络协议地址 RFC827_Exterior 网关 协议 (EGP) RFC854_Telnet协议说明书 RF
### 回答1: RFC1305是一项与互联网时间协议(NTP)相关的规范。该协议描述了一种用于同步计算机时钟的方法,以确保计算机在网络中具有准确的时间。这个协议的中文翻译是RFC1305同步网络时间协议。 RFC1305是由David Mills在1988年提出的,并且在之后的几个版本中进行了更新和改进。该协议的主要目的是确保计算机时钟与其他计算机和服务器之间的网络时间保持同步。它使用一组算法和机制来纠正计算机时钟的漂移,并校准到网络上的准确时间源。 RFC1305描述了一个分层的时间同步体系结构,其中有几个不同级别的时间服务器。最顶层的服务器使用具有高精度的原子钟来提供准确的时间。较低级别的服务器通过与更高级别的时间服务器同步,来提供较低精度但仍然准确的时间。而最底层的计算机则可以从更高级别的时间服务器中获取时间。 在RFC1305中,时间同步是通过将计算机时钟漂移与网络时间源进行比较,然后对时钟进行微调来实现的。这个微调过程基于时间校正包(time correction packet),它包含了从时间源到计算机时钟的延迟和漂移信息,以及其他必要的校准参数。 总之,RFC1305是一项关于网络时间同步的规范,旨在确保计算机具有准确的时间。它定义了一种算法和机制,通过与高精度时间服务器同步,来校正计算机时钟的漂移。这个协议对于需要精确时间的应用程序和系统非常重要,如金融交易、科学实验和通信网络。 ### 回答2: RFC 1305是一个名为“网络时间协议(NTP)的时间同步协议”的国际互联网标准。它描述了一种用于将计算机时钟同步的机制,使得计算机能够以准确的时间进行运行。 RFC 1305提供了有效的时间同步算法,其核心是使用分布式算法通过互联网向计算机提供精密的时间信息。这种算法允许计算机通过接收来自其他计算机的时间标准信息,并使用这些信息进行时间校准,从而保持时钟的准确性。 该协议的主要特点是高度灵活和可调节,并且在全球范围内具有广泛的应用。它能够在不同的计算机操作系统和硬件平台上运行,以满足各种需求。 RFC 1305不仅提供了时间同步机制,还定义了一种用于描述和传输时间的标准格式。该标准格式包括计算机的本地时间、与标准时间的偏差以及时间误差等信息。这种标准化的格式使得不同计算机之间可以方便地进行时间同步,并且能够识别和解决时间不一致的问题。 总之,RFC 1305是一项重要的国际标准,旨在通过使用NTP协议来实现计算机时钟的准确同步。它的使用范围广泛,可以应用于各种计算机系统和网络环境中,确保各种计算机都能够以准确的时间运行。 ### 回答3: RFC1305是一份由Internet Engineering Task Force(IETF)发布的文件,也称为Network Time Protocol(NTP)版本3。它是描述了实现网络时间同步的协议。 RFC1305将NTP的工作原理和实施细节进行了详细说明,并定义了一种分层的时间同步体系结构。它提出了一种层次化的时钟服务器系统,其中公共时钟源与普通计算机连接,通过网络和其他时钟服务器进行同步。 该协议使用了一种称为NTP时间戳的方法来同步时钟。时间戳是一个32位无符号整数,用来表示发送和接收数据包的时间戳。通过对时间戳的比较和计算延迟时间,可以校准时钟并同步设备之间的时间。 RFC1305还提供了一些关于时钟源和时钟维护的准则和建议。它描述了如何选择和配置好的时钟源,以及如何处理时钟源的故障和异常情况。 此外,RFC1305还介绍了一些安全问题,例如如何防止网络攻击者篡改时间信息。它建议使用加密和身份验证机制来确保时间同步的安全性和准确性。 总的来说,RFC1305是一个重要的文件,为网络时间同步提供了一个标准化的方法。它定义了NTP协议的基本原理和细节,并提供了一些关于实施和安全性的建议。通过实施RFC1305,网络中的设备和服务可以准确同步时间,并保持正确的时间状态。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值