可移动终端数据同步技术要求－－数据同步协议（征求意见稿）.doc

GB YD中华人民共和国信息产业部 发布2006-实施2006-发布可移动终端数据同步技术要求Technical requirement for removable terminal data synchronization数据同步协议Data Sync Protocol（征求意见稿）（本稿完成日期： 2006年3月10号）YD/T 中华人民共和国通信行业标准ICS XX.XXX.XXXXXX1YD/T 目 次前 言IV1 范围52 规范性引用文件53 术语和定义64 缩略语85 概述86 SyncML 介绍86.1 SyncML 结构96.2 设备任务96.3 同步类型107 协议基础107.1 更改日志信息107.1.1 多设备107.2 同步标志的使用107.2.1 数据库同步标志107.2.2 数据项同步标志117.3 数据项ID 映射117.3.1 映射操作缓存127.4 冲突解决127.5 安全137.6 编址137.6.1 设备和服务编址137.6.2 RespURI 和Re-direction 状态码的用法137.6.3 数据库编址137.6.4 数据项编址147.7 设备性能信息交换147.8 设备存储管理147.9 多消息包157.10 大对象的处理157.11 无单独初始化的同步177.11.1 健壮性和安全性考虑177.12 中断和重新开始同步会话177.12.1 同步会话的中断177.12.2 同步会话的恢复207.13 忙信号237.14 服务器端的忙状态237.14.2 来自客户端的结果通告248 鉴权258.1 鉴权请求258.2 鉴权258.3 服务器层鉴权258.4 数据库层的鉴权268.5 鉴权举例268.5.1 基于数据库查询的基本鉴权268.5.2 需要请求的MD5摘要访问鉴权279 初始化同步299.1 客户端初始化要求309.1.1 客户端同步初始化包的例子319.2 服务器端初始化要求339.2.1 服务器端初始化数据包的例子349.3 差错情况处理389.3.1 服务器端没有发包389.3.2 客户端初始化未完成389.3.3 初始化错误3810 双向同步3810.1 通知服务器端客户端数据修改3910.1.1 向服务器端发送修改通知的例子4010.2 通知客户端的服务器端修改4110.2.1 服务器端向客户端发送修改实例4110.3 客户端的数据更新状态4210.3.1 发送到服务器端的数据更新状态的例子4310.4 服务器端的MAP 确认4310.4.1 Map确认的实例4410.5 慢同步4410.6 错误情况处理4410.6.1 初始化后服务器没有发送任何包4510.6.2 没有发自客户端的数据更新状态4510.6.3 没有发自服务器端的数据Map 确认4510.6.4 定义错误代码的错误4511 客户端的单向同步4511.1 客户端发送更改结果到服务器端4511.2 服务器方的状态包4611.3 客户端的重建同步4611.4 对错误情况的处理4611.4.1 初始化后服务器没有数据包发来4611.4.2 错误码出错4612 服务器端单向同步4612.1 发给服务器的同步通告4712.2 服务器对客户端的修改4712.3 客户端的数据更新状态4712.4 服务器端的映射确认4712.5 服务器端的重建同步4712.6 错误情况4812.6.1 没有服务器数据包发来4812.6.2 没有从客户端发来的数据更新状态4812.6.3 没有从服务器发来的映射确认4812.6.4 错误码的错误4813 服务器通知同步4813.1 同步通告4813.2 错误情况处理4913.2.1 无客户端数据数据包发来4913.2.2 错误码出错4914 协议值和通告编码4914.1 协议值4914.2 通告编码49附录A5049前 言本标准是可移动终端数据同步通用技术规范。本标准附录A是参考性附录。本标准由中华人民共和国信息产业部提出。本标准由中国通信标准化协会归口。本标准起草单位：北京邮电大学PCN&CAD中心。本标准主要起草人：宋美娜 鄂海红 可移动终端数据同步技术要求数据同步协议1 范围本标准规定了可移动终端数据同步技术要求中的数据同步协议。2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。DEVINF “SyncML Device Information”, Open Mobile Alliance, OMA-SyncML-DevInfo-V1_2,URL:http:.DSREPU “SyncML Representation Protocol, Data Synchronization Usage”, Open Mobile Alliance,OMA-SyncML-DataSyncRepInformation-V1_2, URL:http:.IMCVCAL “vCalendar The electronic calendaring and scheduling exchange format Version 1.0”,URL:/pdi/vcal-10.docIMEI “Digital cellular telecommunications system (Phase 2+) (GSM); Universal MobileTelecommunications System (UMTS); Numbering, addressing and identification” (3G TS 23.003Version 3.4.0 Release 1999),URL:/action/PU/20000523/ts_123003v030400p.pdfMETA “SyncML Meta Information protocol specification”, Open Mobile Alliance, OMA-SyncMLMetaInformation-V1_2, URL:http:REPPRO “SyncML Representation Protocol”, Open Mobile Alliance, OMA-SyncML-RepPro-V1_2,URL:http:RFC1321 “The MD5 Message-Digest Algorithm“, URL:/rfc/rfc1321.txtRFC2045 “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”,N. Freed & N. Borenstein, November 1966, URL:/rfc/rfc2045.txtRFC2119“Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner, March 1997,URL:/rfc/rfc2119.txtRFC2234“Augmented BNF for Syntax Specifications: ABNF”. D. Crocker, Ed., P. Overell.November 1997. URL:/rfc/rfc2234.txtRFC2396“Uniform Resource Identifiers (URI): Generic Syntax”, T. Berners-Lee, et al., August 1998,URL:/rfc/rfc2396.txtSAN “SyncML Server Alerted Notification”, Open Mobile AllianceTM , OMA-SyncML-SAN-V1_2 ,URL:WBXML “WAP Binary XML Content Format Specification”, WAP Forum, WAP-240-WBXML,URL:XML “Extensible Markup Language (XML) 1.0”, World Wide Web Consortium Recommendation,URL:/TR/REC-xml3 术语和定义应用 Application一个支持SyncML协议SyncML应用。 应用可以是SyncML协议命令的发起方和接收方。应用可以充当一个SyncML客户端或一个SyncML 服务器端。性能信息交换 Capabilities exchangeSyncML 允许一个客户端和服务器端交换它们各自支持的设备、用户和应用特性的能力。客户端 Client当应用发出SyncML“request”消息时，一个SyncML 客户端指的是数据同步角色。例如，SyncML 消息中的Sync SyncML 命令。客户端修改 Client Modification是指客户端的数据库与服务器端的数据库修改同步之前客户端数据库中一个修改项。命令 Command一个SyncML 命令是一个数据同步原语。每一个SyncML命令向接收方指定将要执行的一个单独的操作。例如：本规范支持的SyncML 命令包括：Add， Alert，Atomic， Copy，Delete，Exec，Get， Map，Replace， Search， Sequence 和Sync。数据 Data信息交换的单元，需进行编码在网络上传输。数据集合 Data collection它是一个元素，可以担当其它数据元素的容器, (如ci1,data1, in,datan)。在SyncML中，数据集合相互之间是同步的。见数据元素的的说明。数据元素 data element一组数据以及与数据的相关标识符，(如, i, data)。等价数据元素 Data element equivalence当两个数据元素同步时，这两个数据元素称为等价数据元素。确切的语义由一个特定的数据同步模式定义。数据交换 Data exchange发送，请求或者接收一组数据元素的行为。数据格式 Data format用来格式化数据类型的编码方法。例如，字符，整数或者对字符进行编码的二进制数据。数据类型 Data type用来表示数据对象的策略。（如：text/calendar MIME 内容类型是对应日历信息的一种iCalendar 表示法，或者text/directory MIME 内容类型是对应联系信息的一种vCard 表示法。数据同步 Data synchronization两个数据集合之间建立数据等价的行为。这时一个数据集合中的每个数据元素映射到另一个数据集合的数据项中，它们的数据是等价的。数据同步协议 Data synchronization protocol明确定义的“握手”协议或在发起方和接收方的数据集合中完成数据元素的同步所需要的工作流程。SyncML 规范是制定开放的数据同步协议的基础。全球唯一标识 GUID (Global Unique Identifier)数据库中分配给某个对象的号码，GUID 值是不能重用的。在实际使用中，该号码不必一直是唯一的，但当它们存在于一些映射表中时必须是唯一的。本地唯一标识 LUID (Locally Unique Identifier)数据库中分配给某个对象的号码。LUID 的值仅在本地是唯一的，比如，对特殊的SyncML 客户端数据库，但是可以被其它SyncML客户端数据库标识。在该协议中，SyncML 客户端设备给每个对象签署一个本地唯一不可重用的标识（LUID），而且在每个设备和应用中是唯一的。消息 Message一个SyncML 消息是一个SyncML包的基本内容。它包括SyncML 命令，相关的同步数据和元信息。SyncML 消息是一个XML文档。操作 OperationSyncML操作是指由SyncML包指定的SyncML命令来完成的概念上的数据同步处理。例如，“将我的个人地址簿与公共地址簿进行同步“。发起方 Originator发出一个SyncML 请求的网络设备。包 Package SyncML包是指一组完整的数据同步命令和相关数据元素，这些命令和数据元素在发起方和接收方之间传送。SyncML 包可包含一个或多个SyncML 消息。语法分析器 Parser指一个XML 语法分析器。但对于支持SyncML，它不是必需的。然而，整合了XML分析器的SyncML 能更容易实现。这篇文档假定读者对XML的语法和术语已经有所了解。接收方 Recipient接收SyncML 请求、处理请求并发送所有作为结果的SyncML 响应的网络设备。表示协议 Representation protocol以明确定义的格式用于交换特殊形式的信息。SyncML 是传送数据同步操作的一种表示协议。请求消息 Request一种由发起方发送到接收方网络设备的SyncML初始消息。服务器 ServerSyncML服务器指当一个应用发起SyncML“response”消息时的数据同步角色。例如，在SyncML 消息中的结果命令。服务器通告 Server Alerted Notification 服务器同步通告的一般术语。服务器端修改 Server Modification 是指服务器端的数据库与客户端的数据库修改同步之前服务器端数据库中一个修改项。慢同步 Slow Synchronization 当一个数据集第一次同步或者同步状态丢失时，那整个数据集就必须重发。因为这是一个耗时的操作，所以称之为慢同步。同步标志 Synchronization Anchor 用于标识一个同步事件的字符串。这个字符串的格式可以是一序列号，或者是ISO 8610 格式扩展表示和时间戳格式。同步数据 synchronization data 指在SyncML 命令中的数据元素。通常，也可以指在SyncML 消息或SyncML 包中的数据元素的总和。同步引擎 Synchronization Engine 在SyncML 服务器端中用来分析一个数据集和来自SyncML 客户端及服务器端修改的部分被称之同步引擎。同步引擎完成冲突检测及解决。SyncML 请求消息 SyncML request message 一种由发起方发送到接收方网络设备的SyncML初始消息。SyncML 响应消息 SyncML response message 由SyncML请求的接收方返回给提出请求的发起方的一种SyncML的响应消息。临时GUID Temporary GUID 服务器端给数据库某个对象签署的一个临时号码（参见GUID）。仅当对来自客户端与GUID 相关的数据项进行MAP 操作时，临时LUID 才被赋值，之后临时GUID 可以被删除。4 缩略语下列缩略语适用于本标准。ABNFAugmented Backus-Naur Form RFC2234DTDDocument Type Definition文档类型定义GUIDGlobal Unique Identifier全球唯一标识HTTPHyper Text Transfer Protocol超文本传输协议IMEIInternational Mobile Equipment Identifier国际移动设备标识LUIDLocal Unique Identifier本地唯一标识MD5Message Digest algorithm version 5 RFC1321MD5算法 RFC1321MSCMessage Sequence Chart消息顺序图MSGMessage消息OBEXObject Exchange protocol对象交换协议URIUniform Resource Identifier RFC2396统一资源标识URLUniform Resource Locator RFC2396统一资源位置WAPWireless Application Protocol无线应用协议WSPWireless Session Protocol无线会话协议XMLExtensible Markup Language扩展标记语言5 概述本标准以消息顺序图（MSC）的方式定义了数据同步客户端和服务器之间的各种同步过程的协议。它详细说明了如何使用基于SyncML的数据同步表示协议，使客户端和服务器之间互操作性解决方案得以实现。6 SyncML 介绍本标准的目标是用基于SyncML的数据同步表示协议定义一种同步协议，称为数据同步协议。本标准以消息顺序图（MSC）的方式定义了产生于数据同步客户端和数据同步服务器之间的各种同步过程，涵盖了最有用和通用的同步实例（913 章）。6.1 SyncML 结构本标准是利用SyncML 结构的SyncML 接口来实现的（见图1），但并非所有的SyncML接口都必须遵从本标准。图1 SyncML结构 “应用A”表示为位于不同网络设备上的其它应用（比如“应用B”）提供同步服务的一种网络服务，这些服务和设备通过通用的网络传输（比如HTTP）进行连接。上图中，即使实际中SyncML客户端也提供“同步引擎”功能，“同步引擎”功能还是完全放在SyncML服务器端。“同步服务代理”和“同步客户代理”通过在本标准中定义的和SyncML 接口提供的表示协议互相通信。6.2 设备任务图2 给出了一个同步的例子，其中手机作为SyncML 客户，一台真正的服务器作为SyncML 服务器。SyncML 客户端发送包含客户数据修改信息的SyncML消息给SyncML服务器，服务器根据SyncML 消息中的数据同步服务器中存储的数据，然后服务器把修改信息回应给SyncML客户端。图2 手机和服务器之间同步示例这个例子非常简单，但描述了本标准中设备的作用：SyncML 客户端：指包含了同步客户代理并首先把其修改信息发给服务器的设备，而且客户端必须能接收来自SyncML 服务器端的应答。尽管总是SyncML 客户端先发送修改信息，但在某种情况下，服务器端也能发起同步过程。SyncML 客户端通常可以是手机、PC 或PDA设备。SyncML 服务器：指包含了同步服务代理和同步引擎的设备，通常要等待SyncML 客户端发起同步过程并把客户端修改信息发送到服务器端。服务器端负责接收客户端的修改信息并进行同步分析。如果在传输层支持服务器端的主动命令，SyncML 服务器端也可以主动发起同步过程。一般服务器设备或PC 都可以是SyncML 服务器。6.3 同步类型本协议定义了7中不同的同步类型。如表1所示。表1 SyncML同步类型同步类型描述参见双向同步客户端和服务器端相互交换修改信息，客户端首先发送修改信息。第10章慢同步一种双向同步方式，所有数据项都按字段逐个比较，实际上就是客户端把所有数据库中的数据发送给服务器，由服务器对这些数据与服务器中的数据进行同步分析（按字段）。第10.5节客户端单向同步客户端把修改信息发送给服务器，但服务器不给客户端发送修改信息。第11章客户端重建同步客户端发送其数据库中所有数据给服务器（即输出），服务器端用客户端数据替换目标数据库中的所有数据。第11.3节服务器端单向同步客户端从服务器端取得所有修改信息，但客户端不发送其修改信息给服务器端。第12章服务器端重建同步服务器端发送其数据库中的所有数据给服务器客户端，客户端用服务器端数据替换目标数据库中的所有数据。第12.5节服务器端通告同步服务器端通知客户端进行同步，即服务器端通知客户端与服务器开始指定的同步过程。第13章7 协议基础本章定义了所有同步类型的通用特性和要求。7.1 更改日志信息本协议要求设备（包括客户端和服务器端）能跟踪同步过程，负责维护与数据库中的数据项修改有关的更改日志信息。修改的类型可以是：替换、增加和删除等。本协议不指定设备管理的更改日志信息的格式，但一旦同步开始，设备必须（MUST）能指明哪个数据项已经改变。使用唯一的标识（详见6.3 节）来指明哪个数据项改变，使用不同的操作（比如“替换”）表示修改类型。7.1.1 多设备对于一个设备同时与多个设备同步的情况，更改日志信息必须能表明与上次每一个设备同步有关的修改信息。7.2 同步标志的使用7.2.1 数据库同步标志为了清晰地标识同步，本协议使用与数据库（例如：日历数据库）相关的同步标志（见定义）。有两种同步标志，Last 和Next（见Meta 信息DTD3），总是在同步发起时被传送。Last 同步标志从发送设备的角度描述了上一个数据库同步中的事件（例如时间），Next 同步标志从发送设备的角度描述了当前的同步事件，客户端和服务器端互相发送它们自己的标识符。同步标志通过SyncML Initiative 中定义的Meta 信息DTD 在通告操作的Meta 信息中传送。接收设备必须在通告命令状态（状态中的项目元素数据）中向发送设备回应Next 同步标志。同步标志的使用是特别实现的，为了能有效使用它，在下一个同步之前，另一个设备需要存储Next 同步标志。SyncML 服务器也必须存储Next 同步标志以便能有效使用它。如果设备存储了Next 同步标志，下一次同步期间就可以与另一设备的Last 同步标志比较是否相同。如果相同，此设备就可以认为上次同步过程没有出错；如果不同，此设备可以向另一设备请求特别操作（比如慢同步）。设备中存储的同步标志在同步会话完成前不能修改。当一个设备不再准备从别的设备发送和接收任何SyncML消息时认为同步会话结束，同步成功建立在同步命令层上（同步命令只返回状态码200）。另外，传输层（SyncML层之下）通信也要在同步过程完成前正确结束。如果同步设备之间的通信没有遵照传输层协议正常结束，设备不能修改其同步标志。但是，如果被中断的对话重新开始，Next标志的值必须更新（参见7.12.2节）。 数据库同步标志使用举例本例中，同步客户端和服务器端相互同步两次（同步会话1 和2），同步会话1 之后，同步客户端的永久存储器被将清除，因此数据库标志在同步会话2 时不再匹配，同步服务器端会发布这一情况并与客户端发起慢同步过程。同步会话1 开始于2001 年10 月10 日10 时10 分10 秒，其前一同步过程（即在同步会话1 之前）开始于2001 年10 月9 日9 时9 分9 秒。在这个同步会话中，由于同步标志匹配，没有发起慢同步过程，即同步服务器端存储了相同的同步事件时间（2001 年10 月9 日9 时9 分9 秒）。同步会话2 开始于2001 年10 月11 日11 时11 分11 秒，同步会话2 结束后同步客户端的存储器被清空，同步服务器端将发起慢同步。下图描述了两个同步会话过程，只列出了初始阶段和客户端同步标志。图3 同步标志用法示例7.2.2 数据项同步标志本协议没有专门指定传输与数据项相关的同步标志的功能。如果确实需要此功能，必须在其数据项中提供，比如vCalendar，电子日历和日程表交换格式IMCVCAL的序列号5。7.3 数据项ID 映射本协议基于的原则是客户端和服务器端的数据库均拥有自己的数据项ID。这些ID 之间可能相互匹配，也可能不匹配。因为ID 可能是不同的，所以服务器端必须保持数据项ID映射表。也就是说，服务器端知道哪个客户端ID（LUID）和哪个服务器端ID（GUID）指向相同的数据项。图4 说明了同步后一个ID 映射表的例子。在这个例子中，服务器端映射表的描述与实际数据库分离。图4 数据项ID映射示例LUID 总是由客户端设备分配的。这意味着即使是服务器端向客户端设备添加数据项，客户端也要为其分配一个LUID。在这种情况下，客户端将该LUID 返回给服务器端。这个过程采用了映射操作。当客户端发送了映射操作后，服务器端能够用客户端的LUID 更新它的映射表。当服务器端向客户端添加一个新数据项时，如果实际的GUID 大小超过了客户端定义的临时GUID 的最大长度，它就不会发送实际的GUID。如果实际的GUID 大小超过了最大长度限制时，服务器端在向客户端添加一个数据项时，必须使用一个更小的临时GUID。临时GUID 的最大长度在客户端的设备信息文档中定义。如果服务器端修改了一个现存数据项（如：存在于这两种设备上的数据项），当服务器端与客户端间的修改信息（如替换或删除）同步后，服务器端必须用客户端的LUID 标识该数据项。如果是客户端修改数据项的情况，当修改信息传送到服务器端的时候，数据项同样用LUID 来标识。服务器端能够用映射表将LUID 和它自己的GUID 映射起来。7.3.1 映射操作缓存当SyncML服务器端向SyncML 客户端发送一个或多个添加请求后，客户端将这些添加项加入它的数据库中，并为它们分配LUID。客户端有可能缓存与这些LUID 相关的映射操作。如果服务器端明确指出它不需要同步消息应答，客户端则可以缓存这些映射操作。但是，客户端总是允许在将数据项添加到数据库之后立即将映射操作发送给服务器端。这是服务器端指出它无需应答的情况。如果缓存了映射项，那么将会在紧接着的同步会话开始时将映射操作发回给服务器端（在从客户端到服务器端的Pkg#3中）。也就是说，服务器端必须在处理任何与这些映射操作数据项相关的更新之前接收到映射操作。如果SyncML 服务器能控制传输层协议（如：作为OBEX 客户端），那么它必须对发送给客户端的同步命令请求应答。因此，服务器端不能在取得客户端的响应之前断开连接。7.4 冲突解决由于在服务器和客户端的数据库中修改相同的数据项，导致了冲突的产生。一般是通过服务器端设备的同步引擎软件解决冲突问题的。本协议和SyncML 表示协议一起提供了通知SyncML客户端冲突解决的功能。假设SyncML 服务器一般都包括同步引擎功能，但并不排除客户端也提供同步引擎的功能的情况。在这种情况下，客户端也可以解决冲突。服务器端可以仅仅向客户端返回一个冲突或冲突产生通知，由客户端解决该冲突。冲突解决策略有多种，SyncML 表示协议为这些通用策略提供了状态码（见同步表示协议中的第11章）。因此，如果服务器端的同步引擎解决了一个冲突，那么它能够发送关于冲突和如何解决冲突的信息，并通过使用Status 元素产生这种通知。下面的例子描述了服务器端向客户端发送一个状态的例子：112Replace1212208 至于如何管理以及配置冲突解决策略，不属于本协议和SyncML表示协议的范畴。7.5 安全本协议要求支持服务器层上的基本鉴权和MD5摘要访问鉴权机制（如：在SyncHdr中）。同步客户端和服务器端都可以请求鉴权，收到鉴权要求的设备必须返回授权证书。第8章定义了用于本协议的鉴权过程。7.6 编址7.6.1 设备和服务编址SyncML SyncHdr 元素内的设备或服务编址采用SyncML表示规范中定义的URI 机制，而总是连接到互联网上的设备可参考基于URI 的编址。例如，Source 元素如下：/sync-server例如，临时连接的设备可能更倾向于用自己的标识机制来标识自己。如：一部移动电话设备的Source 元素可能是：IMEI:493005100592800传输层的编址方式与SyncML中的编址方式是独立的，两种机制不需要匹配。7.6.2 RespURI 和Re-direction 状态码的用法本协议要求设备支持接收SyncML 表示协议规范内定义的RespURI 元素，但是对Re-direction 状态码（3XX）的支持则不是必须的。7.6.3 数据库编址SyncML操作内的数据库编址是通过SyncML表示协议定义的URI 机制进行的。服务器端和客户端的数据库可以采用绝对或相对的URI。例如，在这两种情况下，一个服务器端数据库的元素如下所示：./calendar/james_bond./sync-server/calendar/james_bond.7.6.4 数据项编址SyncML 数据项元素内的数据项编址采用SyncML 表示规范定义的基于URI 的机制进行。采用的是相对URI。例如：一个数据项的Source 元素如下所示：.101.7.7 设备性能信息交换本协议提供了在初始化阶段交换设备性能信息的功能（见第9章）。交换请求可由同步客户端或同步服务器端发起。当完成第一次与服务器端的同步时，或当静态设备信息在客户端更新后，同步客户端必须将设备信息发送到服务器端。客户端也必须能够在服务器端提出请求时传送自己的设备信息，还应当能够支持接收服务器端的设备信息。同步服务器端必须能够在客户端提出请求时传送自己的设备信息。服务器端必须支持接收和处理客户端设备信息的功能。实现考虑事项。设备信息交换可能要求在空中传输相当大的数据。因此，设备应当避免在同步初始化时每次都请求信息交换。另外，设备应当考虑到如果其它设备很明显地不必使用一些数据时，它们是否还应当传送所有的设备数据。例如，如果客户端指出它不支持vCard3.0 内容格式，那么如果服务器端支持这种方式的话，就不应当发送支持vCard3.0 的属性。7.8 设备存储管理本协议采用元信息DTD，提供了指定设备数据库或设备持久存储的动态存储能力。这种性能说明了剩下多少存储容量可供使用。当每次同步完成时，就可指定这种动态能力。当同步初始化完成时，将会交换静态存储容量信息（见7.7 章节和第9 章）。虽然对同步客户端和服务器端而言，发送持久的存储能力是可选的，但是同步客户端应当发送它们，同步服务器端也可以这么做。不同类型存储能力的使用是由设备上的持久性存储模式决定的。以下例子描述了怎样表现一个设备上的日历数据库的动态存储能力。1./calendar/james_bond./dev-calendar810081.同步命令Meta 元素中的特定数据库存储元素必须与同步命令Source 元素中的特定的源数据库相联系。因此，Meta 元素内不再指定数据库。7.9 多消息包本协议提供了用多个SyncML消息传送一个SyncML 包的功能。如果一个SyncML包太大，以至于不能在一个SyncML消息中传输时，这种功能是必须的。这种限制很可能是由于传输协议或小容量设备的限制而产生。如果一个SyncML包在多个SyncML消息中传送，包中的最后一个消息必须包括Final元素（见SyncML 表示协议）。包中的其它消息不必包含Final 元素。当所有属于一个特定包的必须的命令都发送后，必须包含Final 元素。如果另一端没有结束前述的包，则不必包括Final 元素。例如，如果服务器端仍然向客户端发送第4 号包，那么客户端不必在接收属于第4 号包的最后一个消息前结束第5 号包。当发生错误时，Final之外的元素不能用来表明一个逻辑阶段没有结束。如果一个设备接收到一个Final标记丢失和包括一个数据库同步元素的消息，该设备必须能够在接下来的消息中处理这种情况，即有其它同步元素针对相同的数据库。接收到包含多条消息的SyncML 包的设备必须能够请求更多的消息。这种情况是在用指定的通告代码222 发送Alert 命令回数据源或其它SyncML 命令作为响应发送时发生的，以222 为代码的Alert 命令可以忽略。当收到包含Final元素的消息时，则不再使用Alert 命令。如果产生错误，可能不希望有更多的消息，这样可以防止同步的延续。如果这是有意义的话，当数据包的接收方向数据源方请求更多的消息时，可以同时开始发送下一个包。因此，第3-7 节指出了哪些命令或元素可以在接收到一个包的最后一个消息前发送。以下例子描述了同步客户端在多消息中（2 条消息）发送3 号包，服务器端也在多消息（2 条消息）中发送4 号包。图5 发送一个包内有多条消息的示例7.10 大对象的处理此协议为同步那些大小超过在一条消息传输的容量的对象提供了解决方法。它通过把该对象拆分成能在消息中传送的几个大数据块，并使用元素告知接收方：此数据块是不完整的，后面还有更多的数据块。当接收到带有元素的数据对象时，接收方必须以如下状态响应：“213块状数据包已收到并已进行缓冲处理”；同时，如果没有其它的命令需要发送，将用在7.9节中所定义的以222 为代码的Alert命令请求下条消息。当收到该数据对象的最后一数据块时，接收方将该对象所分的数据块重建为完整的数据对象并执行发送方请求的命令。合适的状态必须发送至发送方。每一数据块中的命令必须严格按atomic处理（要执行就全部执行，要么就都不执行），也就是说，接收方只有在成功地接收完并重组好数据对象的所有数据块后，才能处理该数据对象。能以单一消息传送的数据对象一定不能跟着元素。涉及多消息的数据对象必须在所有的数据块后跟着元素，最后一个数据块除外。在原先的数据对象还未传送完成前，传送者不可将新的数据对象加入任何消息中。如果一个数据对象在多消息间被分块的话，这些数据块必须放在邻近的消息中传送。新的Sync命令（即：Add, Replace, Delete, Copy, Atomic , Sequence）或新的数据项不能放在属于一个数据对象的数据块间。Meta 和Item信息最好是在每一条属于同一数据对象的数据块所在消息的下一消息中重复。如第8章所述，在包含同一数据对象的不同数据块的消息之间，有关该数据对象的鉴定细节可能有所不同。如果一个设备支持大对象的处理，该设备必须在Alert或Sync命令中以Meta信息的形式声明它所能够接收的对象的最大值，如同在META中定义的那样。服务器和客户端应当按照它们所知的自己和接收方的最大消息容量，以确定在分割数据对象时应遵行的大小标准。如果一个数据对象在多消息间被分割为数据块，必须用Meta 信息中的元素来告知接收方该数据对象的总大小。元素必须放在数据对象的第一个数据块中。当接收到最后一个数据块时，接收方必须核实重组后的数据对象的大小是否匹配发送者在Meta 信息中所提供的元素里所标注的大小。如果大小不匹配，返回424（大小不匹配）状态码报告错误。接收方尽力避免执行该命令。发送方可能会试图重发整个数据对象。如果接收方在先前的数据项完成之前发现一个新的数据对象或命令（即先前的数据块中还有元素），接收方必须返回通告223（数据块的结束数据还未收到）。通告应该包含来自原命令的source 和 target（或者其中一个）信息，使发送方能够识别失败命令。注意：在这里一个Status不能够满足，因为一个用来参考的command ID不是必须的。接收方一定不能乱发该命令，发送方会试图发送全部数据对象。以下例子描述了添加一个大对象时的消息交换的片断：15text/x-vcard30002BEGIN:VCARDVERSION:2.1FN:Bruce SmithN:Smith;BruceTEL;WORK;VOICE:+1-919-555-1234TEL;WORK;FAX:+1-919-555-9876NOTE: here starts a huge note field, or icon etc.接收方应返回它的命令或一个222通告码。.282here is the rest of the huge field.blah, blah, blah.END:VCARD.7.11 无单独初始化的同步同步可以在没有单独初始化的情况下开始（见第4 章的初始化）。这意味着初始化可以和同步同时进行，从而减少SyncML 消息在空中发送的数量。如果没有初始化就进行同步，1 号包的Alert 命令（从客户端）将在放置了Sync 命令的3 号包内发送。同样，2 号包内的Alert 命令（从服务器端）将在放置了Sync 命令的4 号包内发送。同步服务器必须能够处理这两种情况：带单独初始化的同步或没有单独初始化的同步。参见附录中的例子。7.11.1 健壮性和安全性考虑如果客户端实现决定采用无单独初始化的同步，必须考虑以下问题： 在服务器端从客户端处获得同步标识之前，客户端向服务器端发送它的修改信息。因此，如果服务器有请求慢同步的需求时，客户端可能需要重新发送全部数据。 在发送客户端修正信息前，服务器端没有接收到同步标识。因此，如果客户端需要请求一个慢同步，那么在先前在3 号包内向服务器端发送的数据则不必发送，并且所有的数据需要向服务器端发送。 在服务器有向客户端发送认证信息（如果需要）的可能性之前，客户端向服务器发送它的修正信息。例如，客户端不能确认是否是和正确的服务器通信。7.12 中断和重新开始同步会话中断可能以如下两种方式发生：1. 用户