AMF3协议中文版
[实用参考]RFC3920(XMPP协议)中文版
![[实用参考]RFC3920(XMPP协议)中文版](https://img.taocdn.com/s3/m/ce6896094b35eefdc8d333e0.png)
RFC3920可扩展的消息和出席信息协议(GMPP):核心协议关于本文的说明本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。
请参照“互联网官方协议标准”的最新版本（STD1）获得这个协议的标准化进程和状态。
本文可以不受限制的分发。
版权声明本文版权属于互联网社区(C)TheInternetSocietP(20GG).摘要本文定义了可扩展消息和出席信息协议（GMPP）的核心功能，这个协议采用GML流实现在任意两个网络终端接近实时的交换结构化信息。
GMPP提供一个通用的可扩展的框架来交换GML数据，它主要用来建立即时消息和出席信息应用以实现RFC2779的需求。
目录1.绪论2.通用的架构3.地址空间4.GML流5.TLS的使用6.SASL的使用7.资源绑定8.服务器回拨9.GML节10.服务器处理GML节的规则11.GMPP中的GML用法12.核心的兼容性要求13.国际化事项14.安全性事项15.IANA事项16.参考1.绪论1.1.概览GMPP是一个开放式的GML协议，设计用于准实时消息和出席信息以及请求-响应服务。
其基本的语法和语义最初主要是由Jabber开放源代码社区于1999年开发的。
20GG年，GMPP工作组被授权接手开发和改编Jabber协议以适应IETF的消息和出席信息技术。
作为GMPP工作组的成果，本文定义了GMPP1.0的核心功能；在RFC2779[IMP-REQS]中指定的提供即时消息和出席信息功能的扩展，定义在GMPP-IM协议[theEGtensibleMessagingandPresenceProtocol(GMPP):InstantMessaging andPresence]中。
1.2.术语本文中大写的关键字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SH OULDNOT","RECOMMENDED","MAP",和"OPTIONAL"的确切含义符合BCP14,RFC2119[TERMS].2.通用的架构2.1.概览尽管GMPP没有结合任何特定的网络结构，通常认为它是客户-服务器架构的一种实现，在这里客户端用GMPP的方式访问服务器采用的是TCP连接，服务器之间的通信也是TCP连接。
AMF25中文说明书(全)
操作介面------------------------------------------------------------------------------------50
按钮和LEDs----------------------------------------------------------------------------------50
双稳定位置ATS (设定点MCB逻辑=“通-合”)--------------------------------------------------1０
三稳定位置ATS (设定点MCB逻辑=“断-合”)--------------------------------------------------1１开始准备-----------------------------------------------------------------------------------1２
一般的描述---------------------------------------------------------------------------------6
控制器系统的描述(与所有的选择)-------------------------------------------------------------6
3GPP协议TS-24008中文版
1. 简述 该文档描述了第三代移动通信系统和数字小区通信系统内用在无线接口的核心网协议流程。 主要描述了无线接口上的流程(参考接口Um或Uu，参考跑3GPP 24.002或3GPP 23.002)比如呼叫控制CC, 移动性管理MM，和会话管理SM。 文中每当提及"further study"或"FS"或"FFS"的地方表示本文不会对相应的内容作标准阐述。 这些流程都是按照无线接口的控制信道上交换的信令定义的。控制信道在3GPP 44.003和3GPP 25.301中描述。 该协议的功能性描述和流程，以及其他层和实体间的交互将在3GPP 24.007中描述。 1.3 层3流程的结构 可以用“积木”法来描述层3的流程。 基础的积木是三个子层的协议控制实体提供的“基本流程”，这些子层是无线资源管理RRM，移动性管理MM和连接管理CM。 1.5 在A/Gb模式下逻辑信道的使用 逻辑信道在3GPP 45.002中定义。下述的这些控制信道都是承载信令信息或指定类型的用户分组数据： 1) 广播控制信道BCCH：下行，用来广播小区独有信息 2) 同步信道SCH：下行，用来广播同步信息和BSS标识信息 3) 寻呼信道PCH：下行，用来发送寻呼给MS 4) 随机接入信道RACH：上行，用来请求一条专用控制信道DCCH 5) 接入允许信道AGCH：下行，用来分配一条专用控制信道DCCH 6) 独立专用控制信道SDCCH：双向 7) 快速辅助控制信道FACCH：双向，和一条业务信道TCH关联 8) 慢速辅助控制信道SACCH：双向，和一条SDCCH或者TCH关联 9) 小区广播信道CBCH：下行，用作非点对点短消息传输 10) 指示信道NCH：下行，用来通知用户VBS呼叫或VGCS呼叫 信令层2定义了两个服务接入点，以SAPI划分(详见3GPP 44.006) 1) SAPI0：支持包括用户消息的信令信息的传输 2) SAPI3：支持用户短消息的传输 层3根据每条消息进行SAP的选择，以及逻辑控制信道的选择，L2操作模式(确认模式AM，非确认模式UM或随机接入)的选择。 1.6 控制流程概览 1.6.1 流程列表 以下是本文涵盖的流程列表： a) 第四章描述的移动性管理基础流程 移动性管理公共流程(4.3节)： 移动性管理专有流程(4.4节)： - 通用的位置更新流程(4.4) 连接控制子层提供的服务： - 移动性管理连接建立(4.5.1) GPRS专有移动性管理流程(4.7) GPRS公共移动性管理流程(4.7节) b) 第五章描述了电路交换域呼叫控制包含的以下几处流程： 活动状态中的信令流程(5.3) 多发流程： d) 第六章描述了会话管理的基本流程： GPRS会话管理流程(6.1)节 这些基本流程可以联合起来形成综合流程，这样的例子放在第七章描述。本文的这个部分只是提供实际操作的指导。 第八章描述了各种出错情况下的动作和为保证以后协议升级的兼容性提供规则。 1.7 实际操作的应用 文中这些流程在终端上的应用取决于终端支持的服务和功能。 1.7.1 VGCS和VBS VGCS和VBS只用在GSM only模式。 对于支持VGCS和VBS的终端，文中会通过判断语句对支持该服务的终端进行专门描述，如果必要，也会给出不支持该服务的终端的行为进行描述。 对于VGCS和VBS，可能存在以下的终端操作： - 支持VBS接听 - 支持VBS的发起 - 支持VGCS的接听 - 支持VGCS的通话(包括了VGCS接听) - 支持VGCS呼叫的发起(包括了VGCS通话) 除了专门提到的联合流程，本文还支持所有可能的联合。 1.7.2 GPRS 对于支持GPRS的终端，通篇在描述某个只适用于GPRS的流程时会有专门的标示，如有必要也会描述不支持的终端将有何行为。 一个支持GPRS的MS可以属于以下三种操作模式的一种： - MS操作模式A (MS已附着到PS和CS域，且支持同时操作CS和PS业务) - MS操作模式B (MS已附着到PS和CS域，但同时只能操作一种CS/PS业务) - MS操作模式C (MS已只附着到PS域) MS的操作模式取决于MS附着的服务，是只有GPRS服务呢还是GPRS，非GPRS服务都有，以及MS是否可以同时操作GPRS和其他GSM服务。可以操作GPRS服务的MS称为GPRS MS。 请注意对于GPRS MS，本文中描述的GMM流程可能不支持于VGCS，VBS和GPRS的联合。可能的交互尚未研究。 附着到PS域的MS可以在以下一种MS操作模式下工作： - PS/CS操作模式 - PS操作模式 本文中这两种操作模式并没有任何不同。使用的是MS操作模式A和MS操作模式C来代替。 在网络操作模式I和II(详见3GPP 23.060)中，工作在PS/CS操作模式的MS和处于操作模式A的GPRS MS使用相同的流程，除非明确指出了是GSM only或者UMTS only。 在网络操作模式I和II中，工作在PS模式的MS和操作模式C的MS使用相同的流程，除非明确指出了GSM only或UMTS only。 2. 参考文献 以下文档提供了本文中使用到的引用文字和段落。 2.1 定义和缩略语 对于本文，缩略语可参考文档3GPP 231.905. 2.1.1 随机值 文中很多地方提到了某些值采用“随机”值，当然在一直指定范围，或者更通用的是一些统计分部值中进行选择。这样的情况只用在MS端。 对于处在相同环境下(包括相同厂家生产的相同型号的终端)是两个MS是有很低概率会选择相同值的，这会被考虑到。甚至，如果发生了这样的低概率事件，也会考虑到这两个终端下一个动作怎样辨别，就像它们前面的选择也不一样。 2.2.2 术语简述 文中涉及到的术语简述如下： GSM security context GSM安全上下文 是在GSM鉴权成功执行后建立的并存储在MS和网络侧。它包含了GSM加密密钥和加密密钥序列号。 UMTS security context UMTS安全上下文 是在UMTS鉴权成功执行后建立并存储在MS和网络侧。包含了UMTS加密密钥，UMTS完整性键，GSM加密密钥和加密蜜月序列号。 idle mode 空闲模式 在此模式下，MS没有分配任何专用信道，监听CCCH和BCCH group receive mode 组接收模式 (只适用于支持VGCS接听或VBS接听的MS)在此模式下，MS未分配专用信道，监听分配到小区的下行语音广播信道或语音组呼信道。偶尔，MS还必须监听服务小区的BCCH。 dedicated mode 专用模式 此模式下，MS至少分配了两条专用信道，只有一条是SACCH group transmit mode 组传输模式 (只适用于支持VGCS通话的MS)在此模式下，语音组呼的MS被分配2条专用信道，其中一条是SACCH。这些信道可以在一个时间分配给一个MS而在语音组呼中分配给不同的MS。 packet idle mode 分组空闲模式 (只适用于支持GPRS的终端)此模式下，MS没有分配分组数据物理信道的无线资源，它监听PBCCH和PCCCH或者如果这些信道网络未提供的话，监听BCCH和CCCH。 packet tranfer mode 分组传输模式 (只适用于支持GPRS的终端)此模式下，MS被分配了一条或多条分组数据物理信道上的无线资源用来传输LLC PDU main DCCH 主DCCH 在专用模式和组传输模式，只有两条信道用作DCCH，其一是SACCH，另一个是SDCCH或FACCH。这个SDCCH活FACCH被称作主DCCH。 信道被激活，是说它可以用作传输，尤其是对信令，至少有UI帧。在SACCH上，无论何时被激活，必须保证L2帧的连续流传输。 TCH已连接，是当CS用户数据可以传输。TCH在未激活时不可能已连接。一个激活但未连接的TCH只用在信令传输，如DCCH。 主DCCH上的SAPI0数据链路称为主信令链路。任何指定在该主信令链路上发送的消息都以确认模式发送，除非专门指出。 词组要建立一条链路是在数据链路上要建立多帧模式的缩略。即使数据链路没有在相关信道激活后立刻建立，在其上发送UI帧也是可能的。除非专门指出，一个数据链路层在没有信息域时建立完成。 信道集用来表示承载关联用户信息流的TCH，比如用来支持CS连接的多时隙配置，最后需要一起处理。 临时块流TBF是一个屋里连接，两个RR对等实体用来支持分组数据物理信道上LLC PDU单向传输。 RLC/MAC块：一个RLC/MAC块是RLC/MAC实体间交互的数据单元，详见3GPP 44.060. GMM上下文：当GPRS附着流程成功完成后建立 网络操作模式 有三种网络操作模式I,II和III，详见3GPP 23.060 网络操作模式会当做系统信息指出。在正常的运营中，网络操作模式在一个路由区内的所有小区应该是相同的。 GPRS MS操作模式 有三种GPRS MS操作模式A，B和C，详见3GPP 23.060 RR连接：一条RR连接是两个RR或RRC对等实体用来支持上层信息流交换的专用CS域连接。 PS信令连接，是一个MS和CN分组域节点间对等的UMTS连接。 异系统变更，是在不同的无线接入技术之间变换，比如GSM和UMTS GPRS：GSM和UMTS系统的分组业务 标签GSM only表明该章节或段落的展示只针对GSM系统。对于多系统情况，取决于当前服务的无线接入网络。 标签UMTS only表明该段落或章节的展示只针对UMTS系统。对于多系统情况，取决于当前服务的无线接入网络。 SIM，用户标识模块 USIM,通用用户标识模块 MS，移动设备，本文中的MS不区分MS和UE。 小区通知，是小区更新流程中的一个优化变量。小区更新流程用LLC NULL帧作为小区变更指示，这样不会重启动READY时钟。
AMBA_3_APB协议规范
AMBA 3 APB 协议规范关于该规范该规范使用于AMBA 3 APB 协议，引用自AMBA 3 (不适用AMBA 2 或更早版本)使用范围该规范用来帮助硬件或软件工程师设计使用APB协议的系统或模块使用该规范该规范按照以下章节进行组织:Chapter 1 简介Chapter 2 传输Chapter 3 操作状态Chapter 4 信号描述目录第一章简介 (2)1.1 关于AMBA 3 APB (2)1.2 AMBA 3 APB 协议规范v1.0修改 (2)第二章传输 (3)2.1 写传输 (3)2.1.1 无等待状态 (3)2.1.2 有等待状态 (3)2.2 读传输 (4)2.2.1 无等待状态 (4)2.2.2 有等待状态 (4)2.3 错误响应 (5)2.3.1 写传输 (5)2.3.2 写传输 (6)2.3.3 PSLVERR映射 (6)第三章操作状态 (7)3.1 操作状态 (7)第四章信号描述 (8)4.1 AMBA 3 APB 信号 (8)1.1 关于AMBA 3 APBAPB属于AMBA 3 协议系列，它提供了一个低功耗的接口，并降低了接口的复杂性。
APB接口用在低带宽和不需要高性能总线的外围设备上。
APB是非流水线结构，所有的信号仅与时钟上升沿相关，这样就可以简化APB 外围设备的设计流程，每个传输至少耗用两个周期。
APB可以与AMBA高级高性能总线(AHB-Lite) 和AMBA 高级可扩展接口(AXI)连接。
1.2 AMBA 3 APB 协议规范v1.0修改该版本包括：• 一个准备好信号PREADY, 来扩展APB传输• 一个错误信号PSLVERR, 来指示传输失败2.1 写传输写传输包括两种类型：• 无等待状态• 有等待状态2.1.1 无等待状态图2-1 显示了一个基本的无等待状态的写传输。
图2-1 无等待的写传输地址、写入数据、写入信号和选择信号都在时钟上升沿后改变。
使用 Synopsys的DesignWareIP 实现基于AMBA3 AXITM 协议的快速设计
使用Synopsys的DesignWareIP 实现基于AMBA3 AXITM协议的快速设计为了在最短时间内成功开发基于AMBA 3 AXI协议的设计,不仅仅需要精通简单设计和单个IP元件,更需要一套广泛的综合实现IP、验证IP以及集成整个SoC子系统的自动化方法。
AMBA 3 高级扩展界面(AXI)协议由于大幅度扩展了AMBA 2.0片上总线的性能和灵活性,因而具备了更多的优势,同时也增加了设计的复杂度。
DesignWare IP为AMBA 3 AXI 协议的解决方案让设计者能快速、简便地集成此高速协议,同时降低了风险,加快了设计周期。
为AMBA 3 AXI协议的DesignWare IP解决方案提供了存取三种主要需求元件的权限,包括综合实现IP、验证IP和使用Synopsys的CoreAssembler工具实现子系统自动集成。
在基于AMBA 3 AXI协议的下一代高速设计中,这三部分的组合使得设计人员能充分降低设计和验证时间。
技术背景――AMBA 3 AXI协议为了正确领会面向基于AMBA 3 AXI协议的工程设计挑战的复杂性,我们必须理解AMBA 3 AXI协议自身的技术特点。
AMBA 3 AXI协议是专门为实现下一代IC设计,由包括Synopsys在内的30多家公司合作开发的。
AMBA 3 AXI协议定义了一种单向通道的架构,它能有效使用寄存器片断实现管道的高速连接。
它支持多重突发事务、完成无序处理事务,和高效使用读、写和地址/控制操作的通道的联系,能使系统具有较高的性能和效率。
这种性能只受外围设备能力的限制。
AMBA 3 AXI协议:通道的作用AMBA 3 AXI协议的架构和以前的AMBA协议有很大不同,因为它引入了通道。
五个独立通道均由一组信息信号组成,使用一种双向“V ALID”和“READY”的握手机制。
当通道具有有效数据或者控制信息时,信息源使用“V ALID”信号。
目标则使用“READY”信号表示可以接收数据。
3GPP协议TS24008中文版
1. 简述该文档描述了第三代移动通信系统和数字小区通信系统用在无线接口的核心网协议流程。
主要描述了无线接口上的流程(参考接口Um或Uu，参考跑3GPP 24.002或3GPP 23.002)比如呼叫控制CC, 移动性管理MM，和会话管理SM。
文中每当提及"further study"或"FS"或"FFS"的地方表示本文不会对相应的容作标准阐述。
这些流程都是按照无线接口的控制信道上交换的信令定义的。
控制信道在3GPP 44.003和3GPP 25.301中描述。
该协议的功能性描述和流程，以及其他层和实体间的交互将在3GPP 24.007中描述。
1.3 层3流程的结构可以用“积木”法来描述层3的流程。
基础的积木是三个子层的协议控制实体提供的“基本流程”，这些子层是无线资源管理RRM，移动性管理MM和连接管理CM。
1.5 在A/Gb模式下逻辑信道的使用逻辑信道在3GPP 45.002中定义。
下述的这些控制信道都是承载信令信息或指定类型的用户分组数据：1) 广播控制信道BCCH：下行，用来广播小区独有信息2) 同步信道SCH：下行，用来广播同步信息和BSS标识信息3) 寻呼信道PCH：下行，用来发送寻呼给MS4) 随机接入信道RACH：上行，用来请求一条专用控制信道DCCH5) 接入允许信道AGCH：下行，用来分配一条专用控制信道DCCH6) 独立专用控制信道SDCCH：双向7) 快速辅助控制信道FACCH：双向，和一条业务信道TCH关联8) 慢速辅助控制信道SACCH：双向，和一条SDCCH或者TCH关联9) 小区广播信道CBCH：下行，用作非点对点短消息传输10) 指示信道NCH：下行，用来通知用户VBS呼叫或VGCS呼叫信令层2定义了两个服务接入点，以SAPI划分(详见3GPP 44.006)1) SAPI0：支持包括用户消息的信令信息的传输2) SAPI3：支持用户短消息的传输层3根据每条消息进行SAP的选择，以及逻辑控制信道的选择，L2操作模式(确认模式AM，非确认模式UM或随机接入)的选择。
RTP协议中文版
RTP协议中文版1. 引言本协议旨在定义实时传输协议（RTP）的中文版标准格式，以便于中文用户理解和使用。
RTP是一种用于音频和视频传输的协议，广泛应用于实时通信、流媒体和视频会议等领域。
2. 范围本协议适用于所有使用RTP协议进行音频和视频传输的应用程序和设备。
3. 规范参考本协议参考以下文档：- RFC 3550: RTP: A Transport Protocol for Real-Time Applications- RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control- RFC 4566: SDP: Session Description Protocol4. 术语定义在本协议中，以下术语的定义适用于所有章节：- RTP：实时传输协议，一种用于音频和视频传输的协议。
- SSRC：同步信源标识符，用于唯一标识RTP数据流中的同步信源。
- RTCP：实时传输控制协议，用于传输RTP会话的控制信息。
- SDP：会话描述协议，用于描述会话的媒体参数和网络地址等信息。
5. RTP数据包格式RTP数据包由固定长度的头部和可变长度的有效载荷组成。
头部包含以下字段：- 版本（V）：协议版本号，占2位。
- 填充（P）：指示数据包是否有填充字节，占1位。
- 扩展（X）：指示数据包是否包含扩展头部，占1位。
- CSRC计数（CC）：指示CSRC标识符的数量，占4位。
- 标记（M）：用于指示数据包是否为关键帧，占1位。
- 负载类型（PT）：指示有效载荷类型，占7位。
- 序列号（SN）：用于标识RTP数据包的顺序，占16位。
- 时间戳（TS）：用于同步RTP数据流的时间戳，占32位。
- 同步信源标识符（SSRC）：用于唯一标识RTP数据流中的同步信源，占32位。
- CSRC标识符（CSRC）：用于标识参与混合的源，每个CSRC标识符占32位。
RFB协议-中文
The RFB ProtocolTristan RichardsonRealVNC Ltd(formerly of Olivetti Research Ltd / AT&T Labs Cambridge)Version 3.8Last updated 5 October 2006RFB协议翻译:晓风英文版版权归RealVNC中文版CopyLeftE-mail:xfsuper@ Blog: 2007.4.12目录1 简介32 显示协议33 输入协议34 像素数据的重现45 协议扩展46 协议消息4 6.1握手消息 5 6.2安全类型7 6.3初始化消息 7 6.4客户到服务器消息 9 6.5服务器到客户消息 13 6.6编码 15 6.7伪编码 201简介RFB ("remote 帧缓存") 是一个远程图形用户的简单协议，因为它工作在帧缓存级别上，所以它可以应用于所有的窗口系统，例如：X11,Windows 和 Mac系统。
其中VNC (Virtual Network Com p uting) 就采用RFB.远程终端用户使用机器（比如显示器、键盘/鼠标）的叫做RFB客户端，提供帧缓存变化的被称为RFB服务器。
RFB 是真正意义上的“瘦客机”协议。
RFB协议设计的重点在于减少对客户端的硬件需求。
这样客户端就可以运行在许多不同的硬件上，客户机的任务实现上就会尽量的简单。
RFB协议对于客户端是无状态的。
也就是说：如果客户端从服务器端断开，那么如果它重新连接相同的服务器，客户端的状态会被保存。
甚至，一个不同的客户端可以用来连接相同的RFB服务器。
而在新的客户端已经能够获得与前一个客户端相同的用户状态。
因此，用户的应用接口变的非常便捷。
只要合适的网络连接存在，那么用户就可以使用自己的应用程序，并且这些应用会一直保存，即使在不同的接入点也不会变化。
这样无论在哪，系统都会给用户提供一个熟悉、独特的计算环境。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
翻译:许江华Adobe Systems Inc.AMF3SpecificationCategory:ActionScript Serialization类别：AS序列化Action Message Format--AMF3Copyright NoticeCopyright(c)Adobe Systems Inc.(2002-2006).All Rights Reserved.Abstract概览Action Message Format(AMF)is a compact binary format that is used to serialize ActionScr ipt object graphs.Once serialized an AMF encoded object graph may be used to persist and retrieve the public state of an application across sessions or allow two endpoints to communicate through the exchangeof strongly typed data.AMF(Act ion Message Format动作信息格式)是用来序列化AS(ActionScr ipt动作脚本)实例对象(object graphs)的压缩的二进制格式。
序列化的AMF编码的实例对象可用来持久化，并且在不同的会话中获得应用的公共状态，或者允许在两个端点(比如客户端和服务器端--译者注)通过强类型数据交换进行通信。
AMF was introduced in Flash Player6in2001and remained unchanged with the introduction of ActionScr ipt2.0in Flash Player7and with the release of Flash Player8.This version of AMF is referred to as AMF0(See[AMF0]).In Flash Player9,Action Script3.0was introduced along with a new ActionScr ipt Virtual Machine(AVM+)-the new data types and language features made possible by these improvements prompted AMF to be updated.Given the opportunity to release a new version of AMF,several opt imiza tions were also made to the encoding format to remove redundant information from serialized data.This specif ication defines this updated version of AMF,namely AMF3.AMF引进于2001年的FlashPlayer6，并且在引入AS2.0的FlashPlayer7和FlashPlayer8中没有改变的保留了。
这个版本的AMF参考于AMF0(查阅[AMF0])。
在FlashPla yer9中，AS3.0同新的AS虚拟机(AVM+)一起被引进—新的数据类型和语言特性的改进致使AMF升级成为可能，给了一个发布新的AMF版本的机会，新版本的AMF在序列化数据的时候做了一些优化，使得编码格式去除了一些冗余信息。
升级后的AMF版本便是AMF3。
Table of Contents目录(略)1Introduction介绍1.1Purpose目的Action Message Format(AMF)is a compact binary format that is used to serialize ActionScr ipt object graphs.Once serialized an AMF encoded object graph may be used to persist and retrieve the public state of an application across sessions or allow two endpoints to communicate through the exchangeof strongly typed data.(译者注：之前有翻译)The first version of AMF,referred to as AMF0,supports sending complex objects by reference which helps to avoid sending redundant instances in an object graph.第一个版本的AMF，即AMF0，支持在避免了在对象图中发送冗余的实例的通过引用发送复杂的对象。
It also allows endpoints to restore object relationships and support circular references while avoiding problems such as infinite recursion during serialization.他也允许端点存储对象关系，并且支持在避免问题--如在序列化时无穷的递归--的情况下的循环引用。
A new version of AMF,referred to as AMF3to coincide with the release of ActionScr ipt3.0, improves on AMF0by sending object traits and strings by reference in addition to object instances.新版本的AMF，即AMF3，与AS3.0版本保持一致，在通过引用发送除对象实例外的对象特性和字符串做了改进。
AMF3also supports some new data types introduced in ActionScr ipt3.0.AMF3也支持在AS3.0中的一些新的数据类型。
1.2Notational Conventions标记转换1.2.1Augmented BNF参数化的BNFType definitions in this specif ication use Augmented Backus-Naur Form(ABNF)syntax[RFC2234].在这个规格中类型定义使用参数化的巴克斯范式(ABNF)语法[RFC2234]。
(译者注：BNF is a formal meta-syntax used to express context-free Grammars.BNF is one of the most commonly used meta-syntactic notation s for specifying the syntax of programming languages,command sets,PDUs,and similar things.However,pure BNF is rather limited,so the two variations EBNF and ABNF have become more popular.)The reader should be familiar with this notation before reading this document.读者在阅读这个文档之前应该熟悉这个注解。
1.3Basic Rules基本规则Throughout this document bytes are assumed to be octets,or8-bits.这个文档的字节是8位的。
U8An unsigned byte(8-bits,an octet)无符号字节（8位，一个8位字节）U16An unsigned16-bit integer in big endian(network)byte order在网络中的字节顺序中的无符号的占用16个二进制位的整数U32An unsigned32-bit integer in big endian(network)byte order在网络中的字节顺序中的无符号的占用32个二进制位的整数DOUBLE8byte IEEE-754double precisionfloating point value in network byteorder(sign bit in low memory).在网络中的字节循序的（符号位在低存储）8字节的IEEE-754双精度浮点数MB A megabyte or1048576bytes.兆字节More complicated data type rules require special treatment which is outlined below.更多的复杂的数据类型规则需要特殊的处理，概括如下：1.3.1Variable Length Unsigned29-bit Integer Encoding可变长度的无符号29位整数的编码AMF3makes use of a special compact format for writing integers to reduce the number of bytes required for encoding.AMF3使用一种特别的压缩格式来写整数，用于压缩编码的字节数量。
As with a normal32-bit integer,up to4bytes are required to hold the value however the high bit of the first3bytes are used as flags to determine whether the next byte is part of the integer.对于一个正常的32-bit的整数，需要4个字节来存储，然而前3个字节的最高位是用于标识下一个字节是不是整数的一部分With up to3bits of the32bits being used as flags,only29significant bits remain for encoding an integer.This means the largest unsigned integer value that can be represented is229–1在32-bit中多达3个bit是用来标志的，所以对编码的一个整数仅仅有29个bit有意义。