SyncML协议翻译

1、SyncML 同步协议(SyncMLSyncProtocol)翻译周鹏2006-1-24摘要本规范定义了 SyncML 客户和服务的同步协议。它规范了怎样使用 SynMLg 示层协议去完成 SyncM 咯户端和服务端的操作。1.介绍本规范的目的是用 SyncMLlfe 示层协议(usingtheSyncMLRepresentationprotocol)定义同步协议.本协议的名称称为 SyncML 同步协议， 为不同的同步过程定义协议，同步过程发生在 SyncML 客户端和服务端.它们问的消息顺序图参考 MSCs.本规范包含了一些普通的有用的同步案例.1.1SyncML 框架通过 SyncML

2、框架(图一)提供的 SyncML 接口实现本规范.本规范不要求实现SyncML8 口的所有特征.图一 SyncML 框架应用A”描述的是一个提供网络同步服务的应用程序,应用B是相同网络上面的设备.服务和设备使用相同的网络传输协议(HTTP).在上图中， 同步引擎在 SyncML务器中实现， 有时也可以在客户端提供同步弓 I 擎.SyncML接口同步服务代理(Syncserver)和客户同步代理(ClientAgent)使用本协议和SyncML 接口(theSyncMLinterfaceSyncMLI/F)提供表示层协议.1.2设备的角色图二描述了一部作为SyncML客户的手机和一个SyncML

3、服务器同步的例子.SyncML客户发送 SyncML 消息给 SyncML 服务器， 这个 SyncML 消息包含了 SyncML 客户的修改数据.服务器同步数据(包含可能的增加修改删去)，数据是服务器的同步消息(SyncMLmessages),之后，同步服务器(theSyncMLserver)返回给同步客户(SynMLClient)它的修改数据.图二移动电话和服务器同步的例子上图提供了一个十分简单的例子，描述了规范中的设备角色：同步客户端(SyncMLClient)-设备包含了同步客户代理， 它首先发送它的修改数据给服务器.客户必须能够接收同步服务器(theSyncMLserver)的影响.

4、同步客户端(SyncMLClient)通常首先发送修改，但是，有些情况下服务器会首先初始化同步.同步客户端通常是移动电话设备，个人电脑,PDA 设备.同步服务器(SyncMLserver)-它是包含了同步引擎和同步代理的设备.通常是等待通步客户端发发起同步请求和修改数据.当它收到客户的修改数据，服务器处理同步分析并且给客户端响应.同步服务器在传输协议层可以主动的发送命令初始化同步.典型的同步服务器设备是服务设备或者是个人电脑1.3同步类型本规范定了七种同步类型，将在下面表一种介绍表一 SyncML 同步类型同步类型描述经专两方同步类型(Two-waysync)普通的同步类型，客户端和服务器相互

5、交换修改数据,客户端首先发送修改.第五章慢同步(Slowsync)一种双方同步的形式，服务器需要比较客户端的每一项数据的每一个字段，这种同步方式客户端需要把全部数据发送给服务器.然后服务器进行比较.第五草九节客户端方同步(One-waysyncfromclientonly)客户端发送它的修改数据给服务器，服务器步发送修改给客户端第八章客户端更新同步(Refreshsyncfromclientonly)客户端发送所有的数据给服务器，替换服务器中的数据第六章第三节服务器端单方同步(One-waysyncfromserveronly)客户端获得所有的服务器的修改数据，客户端不发送自己的修改数据给服务

6、器第七章服务器端更新服务器发送所有的数据给客户端，替换客户端的数据第七章五节同步(Refreshsyncfromserveronly)服务器提醒同步 ServerAlertedSync服务器提醒客户端执行同步第八章1.4符合和约定参考英文版ThekeywordsMUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,RECOMMENDEDNOTRECOMMENDEDMAYandOPTIONALinthisdocumentaretobeinterpretedasdescribedinRFC2119.Anyreferencetocomponent

7、softheDeviceInformationDTDorXMLsnippetsarespecifiedinthistypeface.1.4.1MSC 名称概念用在消息序列图上面的名称概念如下BOX-一个初始过程或者设备的内部过程Hexagon-开始传输的一个需要条件Arrow-代表一个消息或者一个传输过程2 .协议的基础在此章节，所有的同步类型的特征和需求都将被定义.2.1改变日志信息本协议要求所有设备（客户端设备和服务端设备）能够跟踪他们之间的发生的改变和同步.他们需要维护数据项的修改日志信息，修改包含替换，增加,删去.本协议没有规定在设备内部怎样维护这些日志信息.然而，当同步开始的时候，设

8、备必须知道哪些数据项发生了改变.为了标识这些数据项，唯一标识符需要使用.不同的操作也需要标识，比喻是替换增加删去等2.1.1多个设备如果一个设备要和多个设备同步，日志信息必须能够表明在上一次同步之前所有的修改.2.2同步锚点的语法2.2.1数据库的同步锚点为了清楚的同步，本协议使用数据库的同步锚点（参考定义），有两个同步锚点:Last 和 Next（参考 MeaInformationDTD）,他们在同步初始化的时候使用.Last 同步锚点：表示发送设备发送数据前，发生的一个同步事件，主要记录上一此发生同步的时间戳Next 同步锚点：表示当前发送设备发送数据时，发生的同步时间，一般就是当前的时间

9、戳因此，客户端和服务器相互发送各自的同步锚点，锚点信息包含在 Alert 命令的 Meta 元素中.接收设备必须响应 Next 锚点，通过 stats 元素传回给发送设备.使用同步锚点是规范同步实现，在下以前同步之前，同步服务器需要存储 Next 锚点.在一个同步 session 完成之前，存储的锚点不能被更新一个设备不会最发送给其他设备和从其他设备接收任何的 SyncML 消息,时，一个同步 session 就算完成了,同步在 Sync 命令级别完成了.但是，传输还没有完成只有当传输级的通信完成， 才能看作同步完成了.如何同步设备之间的通信没有结束， 设备不能更新同步锚点.数据

10、库锚点的使用例子在这个例子中， 一个同步客户和服务器同步两次 （同步 sesssions#1 和#2） ,在同步 session#1之后，同步客户的内存被重设，因止匕，数据库的锚点和同步 session#2 的锚点步相同，同步服务器发现这个信息，将对客户初始一个慢同步（slowsync）.同步 session#1 在上网 2000:10:10,上一次同步在2001.09.09.09:09:099（在 session#1 之前），在这个同步 seesion 中，没有初始化慢同步，因为锚点是相同的.同步 session#2 在 2001:11:11,因为同步客户

11、的内容被从新，服务器初始一个慢同步.在下图中，描述了两个同步 session,仅描述了初始化阶段和同步锚点例子 3 同步锚点的使用2.2.2 数据项的同步锚点本协议没有明确的指定如何传输单独的数据项，如何需要这个功能，数据锚点必须在数据项中提供，vCalendar 的序列数字属性和电子日历和日程交换数据格式.2.3数据项的ID匹配本协议是建立在同步服务和同步客户都有自己的数据 ID 标识，服务器和客户的 ID 标号可能相同，也可能不相同，因此，服务器必须要维护客户 ID(LUID)和服务 ID(serveED)指向相同的数据项.图四显示了一个同步以后的 ID 匹配的例子，在这个例子中服务端的匹

12、配表分为两个独立的数据表通常,LUID 数据在客户设备端指定，如果服务器增加了一个数据项给客户设备端，客户设备自己指定 LUID(设备本地数据项 ID),客户端返回这个数据项的 LUID 给服务器，服务器更新匹配表.当服务器增加一条数据项给客户设备，如果 GUID 的长度大于客户端定义的临时 GUID,服务器不能把实际的 GUID 发送给客户，服务器必须用很小的临时 GUID,临时 GUID 在客户端的设备信息文档中定义.如果服务器修改了一个存在的数据项（这个数据项在客户设备和服务器中都存在），服务器必须能用客户这个项的 LUI 标识.客户端修改了数据项，项也是用 LUID 标识，当修改发送给

13、服务器，服务器能过匹配 LUID 到 GUID 通过匹配表.2.3.1匹配操作的缓存在 SyncML 客户请求一个或多个增加之后，客户端已经完成了这些增加，并且给它们指定了 LUID,如果服务器没有明确的规定需要需要一个同步消息的情况下，客户端能够缓存这些LUID 的匹配操作.客户端也允许立即给服务器发送匹配操作.如果匹配项被缓存，在接下来的同步 session 中，匹配操作被发送给服务器.在客户端能处理与这些数据项的时候（增加的但是匹配操作被缓存了的数据项），匹配操作必须送出.如果 SyncML务器有传卒 U 控制协议（OBEX）,它必须请求一个同步命令的响应.在获得客户的同步命令之前服务器

14、不能断开连接2.4冲突处理服务器和客户端同时修改相同的数据项的时候会发生冲突，一般在服务设备的同步引擎（syncengine）中解决.本协议和表示层协议提供的功能告诉客户端已经解决的冲突.一般认为同步引擎包含在 SyncML 服务器中，然而，客户端也可以提供同步引擎处理冲突.对于后一种情况，服务器仅仅告诉客户端发生了冲突，客户端能够处理这些冲突.有很多的策略来解决这些冲突，对于常见的策略，SyncML 表示层协议提供状态码（statuscodes）.服务器的同步引擎能够解决冲突，并且发送冲突信息和冲突是如何解决的.这些通知信息包含在 status 元素中.下面是一个例子描述了服务器发送状态码给

15、客户设备.12Replace1212208如何管理和配置策略，超出了本协议和 SyncMUg 示层协议的范围2.5安全本协议要求支持基本认证和 MD 吸字签名，服务器和客户端能够交换授权信息.认证过程参考第三章2.6地址2.6.1设备和服务的地址SyncMW 范使用 URI 标志对 SyncMLSyncHdr 头元素中的设备和服务地址进行编址。设备通常；连接 Internet,要参考 URI 基础的编址，源可能是：/sync-server临时连接的设备，可能是不用它自己的标识机制表示，移动手机设备的源可能是：IMEI:493005100592800如何使

16、用这只类型的编码机制，在传输层和设备和服务地址是比匹配的。 RespURI 和 Re-direction 状态码的用法在 SyncML 协议规范中第一了 RespURI 元素。本协议要求设备支持接收 RespURI 元素，但是可以不支持 Re-direction(3xx)状态码。2.6.2数据库的编址在 SyncML 操作中的数据库编址使用的是 URI 机制，对客户端和服务端的编址可以使用绝对和相对的 URI。在两种情况下，服务端数据库的 source 元素可以如下：./calendar/james_bond./sync-server/ca

17、lendar/james_bond.2.6.3数据项的编址在 SyncMLItem 元素中的数据项的编址是使用 URI-based。可以使用相对的 URIs。一个数据项的源元素可以如下：101.2.7交换设计的能力本协议提供了在同步初始化阶段交换设备的能力（参考第四章），sync 客户或sync 服务器都可以发送交换请求。当最初的同步完成前或客户更新了静态设备信息，Sync 客户必须送它的设备信息到服务器。如果服务端要求客户端的设备信息，客户端必须把它的设备信息发送给服务器。这个客户应该并且支持接受服务器设备信息。如果客户端要求服务端的设备信息，服务端必须发送它的设备信息给客户端，服务器必须支

18、持功能获得和处理客户设备信息，这些设备信息可以是客服端发送的或者是服务端请求的。实施考虑。设备信息的交换信息可能需求传送大相当数量数据。因而，每次当同步初始化时，设备应该避免请求交换。另外，如果客户端确切其它设备不可能支持它设备能力，客户端应该考虑是否它需要寄发所有设备具体数据。如果客户端清楚的表明它不支持这个 vCard3.0 内容格式，服务器支持 vCard3.0，但服务器不应该送 vCard3.0 的属性信息。2.8设备内存管理本协议与 Meta 信息 DTD 提供指定设备数据库的动态内存或在设备上面坚持存贮的内存的能力。有多少剩余的内存可以被使用。每次同步的时候都可以交换这些设备能力。

19、当 sync 初始化完成时，静态内存能力被交换。（参见第二章七节和第四章）。虽然，同步客户和服务器发送内存能力是可选的，同步客户应该送这些并且同步服务器也可以。不同的类型的内存能力的用法是依赖于设备的存贮模型。下面有一个例子说明怎样表示一个设备上的日历数据库的动态内存的能力，当发送同步命令：./calendar/james_bond./dev-calendar810081.在同步命令的 Meta 元素的数据库具体内存元素必须同在同步命令中的 Source 元素指定的源数据库相关联在一起来源数据库指定在 Sync 命令的来源元素。因而，这个数据库不在在 Meta 元素中指定。2.9包中多条消息本

20、协议提供在多个 SyncML 消息中传递一个 SyncML 包。如果一个 SyncML 包对于一条 SyncML 消息太大，这种情况可能是由于传输协议或者小设备的原因导致的。如果在多条 SyncML 消息中传送一个 SyncML包，最后一条消息必须包含 Fianl 元素，属于这个包的其他消息一定不要包含 Final 元素。当一个包中所有的命令发送完以后，Final 元素必须包含在这些命令之后。如果一个包中的其他项没有结束，则不能包含 Final 元素。例如，如果服务器仍然送这个包#4 给客户，这个客户不能关闭包裹#5 早于在接受包#4 的最后一条消息前。 如果一个错误发送，不能用 Final

21、元素表明逻辑阶段没有完成。如果设备接受最后的一条消息，这条消息包含了 Sync 元素但是缺少了 Final 元素,设备必须能够在下条消息中处理这种情况，下条消息中中有其它 Sync 元素同步相同的数据库。接受包含多种消息的 SyncML 包的设备必须能够要求更多消息。要求更多消息是通过发送 Alert 命令，并且指定 alert 代码。222 代码将被返回或者有其他的 SyncML 命令返回，333alert 代码可以被省去。这发生由送一个机敏命令与一个具体机敏代码，222 回到这个包裹的创作者，或如果有其它 SyncML 命令被送彳为反应，机敏命令与这个 222 机敏代码也许被省去。在接受这

22、则消息以后包含最后的元素，机敏命令不能被使用。在收到包含了 Final 元素的消息以后，Alert 命令不能在使用。如果发送了错误，同步将被终止，不要在发送更多的消息。当包的发送者要求更多的消息的时候，包的接收者开始发送它的下一个包。在第三章第七节，它被指定在接受到包含 Final 元素的消息之前，命令或元素被允许发送，包含 Final 元素的消息和发送命令或元素的消息属于同一个包。下面这个例子说明了一个同步客户在多个消息（2 个消息）中发送包#3 和服务器在多个消息（2 个消息）中发送包#4。2.10大对象的处理本协议提供方法同步那些大小超出在一则消息之内传送的对象。通过分割对象成能是否消息

23、能够被传送的小部分，使用MoreData/元素告诉接收者，这个大块数据项目还没有完成，还会有其他的部分传送过来。当接收者接收到一个包含MoreData/元素的对象，它必须响应“214-小部分对象收到并且缓存了”和，并且，如果不需要发送其他的命令，使用 alert222（在第二章第九部分）机制要求下一条消息。能够在一条消息中传输的对象不能使用MoreData/元素，分割成几个小部分的对象，处理最后一条传送消息中不包含MoreData/元素，其他的传送消息都需要包含。发送者不能增加新的数据对象到任何一条消息知道前面的数据对象发送完成。分割成小部分的对象必须连续的发送，新的命令或者新的数据项不能在中

24、间发送。2.11有单独初始化的同步同步可以在没有单独初始化的情况下开始（参考第四章的初始化同步），初始化可以和同步同时进行，这样可以减少传送 SyncML 消息的数量.如果同步没有初始化过程，在包#1（客户发送的）中的 Alert 命令将放置在包#3 中，包#3中同时也放置了 Sync 命令.在包#2 中的 Alert 命令（服务端发送的）将放置在包#4 中,在包#4中同时也放置了 Sync 命令.同步服务器必须能够处理这两种情况：在同步命令前没有单独的初始化和在同步命令前有单独的初始化.参考附件中的例子.2.11.1 强壮性和安全性如果客户决定采用没有单独的初始化过程的同步，下面的一些事情需

25、要考虑：在服务器获得客户的同步锚点前，客户发送修改命令给服务器，这种情况下，获得锚点，如果服务端请求一个慢同步，那么，客户端需要发送所有的数据.客户端在没有收到服务器的同步锚点之前，客户发送了客户端的修改.如果客户需要请求一个慢同步，客户早期（在包#3 中）发送的数据，可以不用在发送给服务器，但是所有的数据必须发送给服务器.客户发送给服务器它的修改在有任一种可能性使服务器送它的认证（如果必须）到这个客户。即，客户不可能肯定是正确服务器通信。2.12忙信号如何服务器能够接收客户的修改数据，但是，它不能在合理的时间内处理客户的这个请求，服务器应该发送忙的 status 码给客户.客户端收到服务器的

26、忙信号以后，客户可以在晚些时候要求同步或者重新开始一个同步.如何客户重新开始一个同步，那么客户的 Last 同步锚点一定不能被更新.如果服务器发送了忙 status 码给客户后，没有收到客户的请求，那么服务器必须假设它将从头开始同步，服务器不能更新 Last 锚点，也不能修改客户的 Next 锚点.2.12.1 服务器的忙 status服务器通过发送忙 status 包给客户通知服务器正忙.这个包可以在完全接收任何一个包之前.在客户请求包中的 Syncbody 部分有数据项和其它命令，忙 status 包不能返回他们的状态信息.5.%2.在忙 status 包中的元素的要求如下VerDTD 元

27、素的值必须四1.1;VerProto 元素的值必须是SyncML/1.1;SessionID 必须能够表明一个同步 Sesson 的 IDMsgID 必须明确的表明它属于一个 session 的第几个包消息（服务端发送给客户的）Target 元素指定目标设备Source 元素指明原设备或者服务6.%2.对 SyncHdr 元素的 status 元素必须包含在 SyncBody.status 码（101 正在处理）必须返回，这个状态码是位 SyncHdr 的.ExampleofBusyStatus1.1SyncML/1.112IMEI:493005100592800http:/w

28、/sync-server120SyncHdr/sync-serverIMEI:4930051005928001012.12.2 客户的结果（Result）Alert 命令结果 Alert 命令是客户发送给服务器要求上一条消息的结果的命令.客户通过发送结果 Alert 命令给服务器.在包中消息的要求如下：1.%2.%3.在 SyncHdr 元素中的元素要求如下：VerDTD 元素的值必须四1.1;VerProto 元素的值必须是SyncML/1.1;SessionID 必须能够表明一个同步 Sesson 的 IDMsgID 必须明

29、确的表明它属于一个 session 的第几个包消息（服务端发送给客户的）Target 元素指定目标设备或者服务Source 元素指明原设备2.%2.%3.alert 元素必须包含在 SyncBody 中,Alert 元素的要求如下：CmdID 是需要的Item 元素指明服务和客户设备Data 元素用来包含 Alert 码,Alert 码为2213.%2.%3.Final 兀素一定不要包含.如果服务器收到客户的结果 Alert 时，服务还是忙，那么服务器必须返回101status 给客户，这个状态码对于客户发送的消息的 SyncHdr 和 Alert 命令.ExampleofRe

30、sultAlert1.1SyncML/1.113/sync-serverIMEI:4930051005928001221/sync-serverIMEI:4930051005928003.鉴权在这章中，使用 basic 和 MD5 数字签名的授权过程.这两种方式设备都必须支持.1.鉴权请求如果返回给一个请求（消息或者命令）的响应码是 401（没有授权）或者 407（授权需要） ，那么这个请求是要求授权的.在这中情况下，返回给请求的 Status 命令必须包含包含一个 Chal元素.Chal 元素包含对请求资源的授权

31、要求.设备可能会使用 Cred 元素重复这个请求过程.如果这个请求包含了 Cred 元素,那么返回 401 码表明授权被拒绝.客户和服务器都能够要求授权.如果响应码是 401 的响应包含和上次响应相同的要求授权信息， 并且用户代理已经认证过至少一次，那么,用户应该给响应一些相应的诊断信息.如果响应码是 212（认证通过），那么余下的同步过程不在需要认证了.在 MD 嗷字签名的认证情况下,Chal 元素能过被返回.在 Chal 元素中 nextnonce 熟悉必须用被使用，表明下个同步 session 开始的时候使用的签名.如果一个请求包含了安全认证并且响应码是 200（同步命令已经成功完成），

32、那么相同的认证必须在下一个同步请求中发送.如果Chal元素被包含并且要求使用MD吸字签名认证.如何包含了 Chal 元素并且需要使用 MD 嗷字签名，一个新的数据签名必须被创建，同样也是 MD5 勺数据签名.在使用 MD 嗷据签名认证的情况下,Chal 元素能够被返回.单下个请求开始的时候,Chal 中的 nextnonce 必须被使用.当一个授权已经发生，在整个 seesion 过程中必须使用相同的授权类型.授权失败（用户 ID 和密码错误或者需要一个授权）的要求如下：响应消息表明服务层的授权失败， 并且， 响应消息必须并且仅仅任包含 Status 命令 （Put,get命令不能包含在响应中

33、）,status 命令必须提供给收到的请求的每一个命令.在 session 还要继续的情况下，包含了合适的认证的下一条消息必须包含一个对 SyncHdr 的 status,和前一条消息必须是相同的 SessionID,当授权失败 RespURI 被指定的情况下，消息必须送给 RespURI.1.授权当收到包含了 401 或者 407 的响应以后，请求如果需要重复发送，那么，请求必须包含 Cred元素.另外，设备可以把包含 chal 元素的请求第一个发送，如果授权被配置成需要的.Cred 元素的内容在文档1中说明.授权类型独立请求或者预先配置.1.服务层授权当需要授权时候，协议仅仅支持服务层的授

34、权（在 SyncHdr 元素）.设备必须支持服务层的授权.使用 SyncHdr 元素的 Cred 元表和 Status 命令完成服务层的授权.在 status 命令中，授权请求被传送.授权可以是双方向的，客户可以授权给服务器，服务器也可以授权给客户.1.数据库层的授权1.本规范规定设备可以支持数据库层的授权.通过 Alert 元素中的 Cred 元素和和 sync 命令和status 完成.在 status 命令中包含了早期定义的请求信息.认证可以是双方向的， 客户可以授权给服务器，服务器也可以授权给客户.3.5 授权例子Basic 授权请求在这个例子中，可以试在没有认证信息的情况初始化同步，

35、服务端先客户请求服务层的认证信息.客户必须重发包#1,包#1 中包含了认证信息.服务接收认证并且 seesoin 被授权.在这个例子中，SyncBody 的内容没有被包含.Pkg#1fromClient1.1SyncML/1.111/sync-serverIMEI:493005100592800.Pkg#2fromServer1.1SyncML/1.111IMEI:493005100592800/sync-server110SyncHdr/sync-serverIMEI:49

36、3005100592800syncml:auth-basicb64407Pkg#1(withcredentials)fromClient1.1SyncML/1.112/sync-serverIMEI:493005100592800syncml:auth-basicQnJ1Y2UyOk9oQmVoYXZlPkg#2fromServer1.1SyncML/1.112IMEI:493005100592800/sync-server110SyncHdr/sync-serverIMEI

37、:493005100592800212MD5 数据签名认证请求在这个例子中，客户试着在没有任何的认证的情况下开始初始化同步（包#1）,服务器向客户请求服务层的认证.认证类型是 MD5 客户必须重新发送包含了认证信息的包#1,服务器接收认证，session 被授权.服务器发送下一个 nonce 认证给客户，客户将使用她在下一个同步 session 开始的时候是用 nonce 的认证.在这个例子中，SyncBody 的内容没有显示.Pkg#1fromClient1.1SyncML/1.111/sync-serverIMEI:493005100592800Br

38、uce2Pkg#2fromServer1.1SyncML/1.111IMEI:493005100592800/sync-server110SyncHdr/sync-serverIMEI:493005100592800syncml:auth-md5b64407Credentialsmissing-Pkg#1(withcredentials)fromClient1.1SyncML/1.112/sync-serverIMEI:493005100592800syncml:auth-m

39、d5Zz6EivR3yeaaENcRN6lpAQ=Pkg#2fromServer1.1SyncML/1.112IMEI:493005100592800/sync-server110SyncHdr/sync-serverIMEI:493005100592800syncml:auth-md5b64LG3iZQhhdmKNHg=212.4、同步初始化实际的同步过程需要初始同步（参考章节 5-7）,初始同步过程可以传送和执行同步命令（synccommand。在初始同步前，同步服务器（SyncMLserver）可能会提示同步

40、客户同步。但是初始同步过程不能忽略。初始同步的目的有：、服务器和客户端在 SyncMK 别进行权限认证。、表明使用哪个数据库和使用什么协议。、交换服务器和客户设备的处理能力前两点通过 SyncML示层协议中的 Alert 命令实现。服务器和客户设备必须支持实现上面的功能。服务器和客户设备交换能力可以通过 SyncML示层协议中的 Put、 Get命令和设备的 DTD息实现。初始同步过程如下：在实际的同步信息中包含了有些处理过程（一些响应）上面图像中的箭头表示 SyncML 包。SyncML 包可以包含一个或多个消息（messaged。这个过程中的属于的包共同一个 Session,就是说有相同的

41、 SessionID 号每个包的目的和需要将在下节介绍。4.1 客户端（Client）的初始化请求前面的章节提到，客户端在初始化的时候，（Client）通知服务器需要同步哪个数据库和使用哪种的同步类型。同时，客户端还能包含授权信息和服务能力（servicecapabilities。在 Alert 命令中指示哪个数据库需要同步。每一个数据库需要使用一个单独的 Alert 命令。另外，Alert 命令可以去 exchangethesyncanchors.如果需要授权信息，必须要包含包头（SyncHdr）中包含 Cred 元素。数据可以是 Basic 或者 MD 功口密的数字签名。可以通过在包体（S

42、yncBody）元素中使用 Put 命令来交换服务器和设备的能力。客户端必须要服务和设备信息，这些信息可以从设备（Device）DTD 中获得。客户端发送给服务器的同步初始化包（在图 6Pkg#1）的详细需求如下：4.在 SyncHdr（包头）元素中的要求如下：A.VerDTD 元素的值必须是1.1。B.必须 VerProto 元素来制定使用的协议和协议版本，其值必须为SyncML/1.1C.必须制定同步的 sessionIDD,必须使用 Msgid 清晰的表明消息属于一个同步 session(syncsession)E、如果需要认证的，必须包含 Cred 元素。在指明需要使用哪些数据库的时候

43、，使用 Alert 元素。Alert 元素需包含在 SyncBody 元素中，具体的要求如下：A.必须使用 CmdID 元素B.Alert 元素必须有响应。在 Alert 元素中必须包含 Data 元素。Data 元素的值表明 Alert 代码。具体参考 AlertCodes。item 元素中的 Target 元素表明目标数据源E.item 元素中的 Source 元素表明客户的数据源F.客户的同步(syncanchors)必须包含在 previous 和 current 同步(anchors),在 Meta 元素中包含同步(anchors).在服务端和客户端交换服务能力，如何是客户发给服务，

44、需要在 SyncBody元素中使用 Put 命令。必须要 CmdID在 Put 命令的 Meta 元素中必须包含 Type 元素指明 MetaInfDTD在 Item 元素中的 Source 元素必须有一个值为./devinfll.D.Data 元素中包含的是设备和服务信息。.服务端向客户发送服务能力，需要在 SyncBody 中使用 Put 命令。必须要 CmdID在 get 命令的 Meta 元素中必须包含 Type 元素指明 MetaInfDTD在 Item 元素中的 Target 元素必须有一个值为./devinfll.D.Data 元素中包含的是设备和服务信息。8、必须包含 Final 元素表明这条信息结束4.1.1ExampleofSyncInitializationPackagefromClient1.1SyncML/1.111/sync-serverIMEI:493005100592800syncml:auth-basicQnJ1Y2UyOk9oQmVoYXZl50001200./contacts/james_bo