杨幂被爆视频,附身控制美女视频,美女视频mm123

翻譯周鵬

2006-1-24

摘要

本規(guī)范定義了SyncML客戶和服務(wù)的同步協(xié)議。

它規(guī)范了怎樣使用SynML表示層協(xié)議去完成SyncML客戶端和服務(wù)端的操作。

1. 介紹

本規(guī)范的目的是用SyncML表示層協(xié)議(using the SyncML Representation protocol)定義同步協(xié)議.本協(xié)議的名稱稱為SyncML 同步協(xié)議,為不同的同步過(guò)程定義協(xié)議,同步過(guò)程發(fā)生在SyncML客戶端和服務(wù)端.它們間的消息順序圖參考MSC‘s. 本規(guī)范包含了一些普通的有用的同步案例.

1.1 SyncML框架

通過(guò)SyncML框架(圖一)提供的SyncML接口實(shí)現(xiàn)本規(guī)范.本規(guī)范不要求實(shí)現(xiàn)SyncML接口的所有特征.

圖一 SyncML框架

應(yīng)用"A" 描述的是一個(gè)提供網(wǎng)絡(luò)同步服務(wù)的應(yīng)用程序. 應(yīng)用"B"是相同網(wǎng)絡(luò)上面的設(shè)備.服務(wù)和設(shè)備使用相同的網(wǎng)絡(luò)傳輸協(xié)議(HTTP).

在上圖中,同步引擎在SyncML服務(wù)器中實(shí)現(xiàn),有時(shí)也可以在客戶端提供同步引擎.SyncML 接口

同步服務(wù)代理(Sync server)和客戶同步代理(Client Agent)使用本協(xié)議和SyncML 接口(the SyncML interface

‘SyncML I/F‘)提供表示層協(xié)議.

1.2 設(shè)備的角色

圖二描述了一部作為SyncML客戶的手機(jī)和一個(gè)SyncML 服務(wù)器同步的例子. SyncML 客戶發(fā)送 SyncML消息給SyncML服務(wù)器, 這個(gè)SyncML消息包含了SyncML 客戶的修改數(shù)據(jù).服務(wù)器同步數(shù)據(jù)(包含可能的增加修改刪去),數(shù)據(jù)是服務(wù)器的同步消息(SyncML messages),之后,同步服務(wù)器(the SyncML server)返回給同步客戶(SynML Client)它的修改數(shù)據(jù).

圖二移動(dòng)電話和服務(wù)器同步的例子

上圖提供了一個(gè)十分簡(jiǎn)單的例子,描述了規(guī)范中的設(shè)備角色:

同步客戶端(SyncML Client)- 設(shè)備包含了同步客戶代理,它首先發(fā)送它的修改數(shù)據(jù)給服務(wù)器. 客戶必須能夠接收同步服務(wù)器(the SyncML server)的影響. 同步客戶端(SyncML Client)通常首先發(fā)送修改,但是,有些情況下服務(wù)器會(huì)首先初始化同步.同步客戶端通常是移動(dòng)電話設(shè)備,個(gè)人電腦,PDA 設(shè)備.

同步服務(wù)器(SyncML server) -- 它是包含了同步引擎和同步代理的設(shè)備.通常是等待通步客戶端發(fā)發(fā)起

同步請(qǐng)求和修改數(shù)據(jù).當(dāng)它收到客戶的修改數(shù)據(jù),服務(wù)器處理同步分析并且給客戶端響應(yīng).

同步服務(wù)器在傳輸協(xié)議層可以主動(dòng)的發(fā)送命令初始化同步. 典型的同步服務(wù)器設(shè)備是服務(wù)設(shè)備或者是個(gè)人電腦

1.3 同步類型

本規(guī)范定了七種同步類型,將在下面表一種介紹

表一 SyncML同步類型

同步類型

描述

參考

兩方同步類型

(Two-way sync)

普通的同步類型,客戶端和服務(wù)器相互交換修改數(shù)據(jù),客戶端首先發(fā)送修改.

第五章

慢同步

(Slow sync)

一種雙方同步的形式,服務(wù)器需要比較客戶端的每一項(xiàng)數(shù)據(jù)的每一個(gè)字段,這種同步方式客戶端需要把全部數(shù)據(jù)發(fā)送給服務(wù)器.然后服務(wù)器進(jìn)行比較.

第五章五節(jié)

客戶端方同步(One-way sync

from client only)

客戶端發(fā)送它的修改數(shù)據(jù)給服務(wù)器,服務(wù)器步發(fā)送修改給客戶端

第六章

客戶端更新同步

(Refresh sync

from client only)

客戶端發(fā)送所有的數(shù)據(jù)給服務(wù)器,替換服務(wù)器中的數(shù)據(jù)

第六章第三節(jié)

服務(wù)器端單方同步(One-way sync

from server only)

客戶端獲得所有的服務(wù)器的修改數(shù)據(jù),客戶端不發(fā)送自己的修改數(shù)據(jù)給服務(wù)器

第七章

服務(wù)器端更新同步(Refresh sync

from server only)

服務(wù)器發(fā)送所有的數(shù)據(jù)給客戶端,替換客戶端的數(shù)據(jù)

第七章五節(jié)

服務(wù)器提醒同步Server Alerted

Sync

服務(wù)器提醒客戶端執(zhí)行同步

第八章

1.4 符合和約定

參考英文版

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",

"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].

Any reference to components of the Device Information DTD or XML snippets are specified in this type face.

1.4.1 MSC 名稱概念

用在消息序列圖上面的名稱概念如下

l BOX - 一個(gè)初始過(guò)程或者設(shè)備的內(nèi)部過(guò)程

l Hexagon- 開(kāi)始傳輸?shù)囊粋€(gè)需要條件

l Arrow-代表一個(gè)消息或者一個(gè)傳輸過(guò)程

2.協(xié)議的基礎(chǔ)

在此章節(jié),所有的同步類型的特征和需求都將被定義.

2.1 改變?nèi)罩拘畔?div style="height:15px;">

本協(xié)議要求所有設(shè)備(客戶端設(shè)備和服務(wù)端設(shè)備)能夠跟蹤他們之間的發(fā)生的改變和同步.

他們需要維護(hù)數(shù)據(jù)項(xiàng)的修改日志信息,修改包含替換,增加,刪去. 本協(xié)議沒(méi)有規(guī)定在設(shè)備內(nèi)部

怎樣維護(hù)這些日志信息.然而,當(dāng)同步開(kāi)始的時(shí)候,設(shè)備必須知道哪些數(shù)據(jù)項(xiàng)發(fā)生了改變.

為了標(biāo)識(shí)這些數(shù)據(jù)項(xiàng),唯一標(biāo)識(shí)符需要使用.不同的操作也需要標(biāo)識(shí),比喻是替換增加刪去等

2.1.1 多個(gè)設(shè)備

如果一個(gè)設(shè)備要和多個(gè)設(shè)備同步,日志信息必須能夠表明在上一次同步之前所有的修改.

2.2 同步錨點(diǎn)的語(yǔ)法

2.2.1 數(shù)據(jù)庫(kù)的同步錨點(diǎn)

為了清楚的同步,本協(xié)議使用數(shù)據(jù)庫(kù)的同步錨點(diǎn)(參考定義),有兩個(gè)同步錨點(diǎn):Last和Next(

參考Mea Information DTD),他們?cè)谕匠跏蓟臅r(shí)候使用.

Last 同步錨點(diǎn): 表示發(fā)送設(shè)備發(fā)送數(shù)據(jù)前,發(fā)生的一個(gè)同步事件,主要記錄上一此發(fā)生同步的時(shí)間戳

Next 同步錨點(diǎn): 表示當(dāng)前發(fā)送設(shè)備發(fā)送數(shù)據(jù)時(shí),發(fā)生的同步時(shí)間,一般就是當(dāng)前的時(shí)間戳

因此,客戶端和服務(wù)器相互發(fā)送各自的同步錨點(diǎn),錨點(diǎn)信息包含在Alert命令的Meta元素中.

接收設(shè)備必須響應(yīng)Next錨點(diǎn),通過(guò)stats元素傳回給發(fā)送設(shè)備.

使用同步錨點(diǎn)是規(guī)范同步實(shí)現(xiàn),在下以前同步之前,同步服務(wù)器需要存儲(chǔ)Next錨點(diǎn).

在一個(gè)同步session完成之前,存儲(chǔ)的錨點(diǎn)不能被更新.

一個(gè)設(shè)備不會(huì)最發(fā)送給其他設(shè)備和從其他設(shè)備接收任何的SyncML消息時(shí),一個(gè)同步session就算完成了,同步在Sync命令級(jí)別完成了.但是,傳輸還沒(méi)有完成,只有當(dāng)傳輸級(jí)的通信完成,才能看作同步完成了.如何同步設(shè)備之間的通信沒(méi)有結(jié)束,設(shè)備不能更新同步錨點(diǎn).

2.2.1.1 數(shù)據(jù)庫(kù)錨點(diǎn)的使用例子

在這個(gè)例子中,一個(gè)同步客戶和服務(wù)器同步兩次(同步sesssions #1和#2),在同步session #1之后,同步客戶的內(nèi)存被重設(shè),因此,數(shù)據(jù)庫(kù)的錨點(diǎn)和同步session #2的錨點(diǎn)步相同,同步服務(wù)器發(fā)現(xiàn)這個(gè)信息,將對(duì)客戶初始一個(gè)慢同步(slow sync).

同步session #1 在上網(wǎng)2001.11.10.10:10:10,上一次同步在2001.09.09.09:09:099(在session #1之前),在這個(gè)同步seesion中,沒(méi)有初始化慢同步,因?yàn)殄^點(diǎn)是相同的.

同步session #2 在2001.11.11.11:11:11,因?yàn)橥娇蛻舻膬?nèi)容被從新,服務(wù)器初始一個(gè)慢同步.

在下圖中,描述了兩個(gè)同步session,僅描述了初始化階段和同步錨點(diǎn)

例子3 同步錨點(diǎn)的使用

2.2.2 數(shù)據(jù)項(xiàng)的同步錨點(diǎn)

本協(xié)議沒(méi)有明確的指定如何傳輸單獨(dú)的數(shù)據(jù)項(xiàng),如何需要這個(gè)功能,數(shù)據(jù)錨點(diǎn)必須在數(shù)據(jù)項(xiàng)中提供,

vCalendar的序列數(shù)字屬性和電子日歷和日程交換數(shù)據(jù)格式.

2.3 數(shù)據(jù)項(xiàng)的ID匹配

本協(xié)議是建立在同步服務(wù)和同步客戶都有自己的數(shù)據(jù)ID標(biāo)識(shí),服務(wù)器和客戶的ID標(biāo)號(hào)可能相同,也可能不相同,因此,服務(wù)器必須要維護(hù)客戶ID(LUID)和服務(wù)ID(server ID)指向相同的數(shù)據(jù)項(xiàng).

圖四顯示了一個(gè)同步以后的ID匹配的例子,在這個(gè)例子中服務(wù)端的匹配表分為兩個(gè)獨(dú)立的數(shù)據(jù)表

通常,LUID數(shù)據(jù)在客戶設(shè)備端指定,如果服務(wù)器增加了一個(gè)數(shù)據(jù)項(xiàng)給客戶設(shè)備端,客戶設(shè)備自己指定LUID(設(shè)備本地?cái)?shù)據(jù)項(xiàng)ID),客戶端返回這個(gè)數(shù)據(jù)項(xiàng)的LUID給服務(wù)器,服務(wù)器更新匹配表.

當(dāng)服務(wù)器增加一條數(shù)據(jù)項(xiàng)給客戶設(shè)備,如果GUID的長(zhǎng)度大于客戶端定義的臨時(shí)GUID,服務(wù)器不能把實(shí)際的GUID發(fā)送給客戶,服務(wù)器必須用很小的臨時(shí)GUID,臨時(shí)GUID在客戶端的設(shè)備信息文檔中定義.

如果服務(wù)器修改了一個(gè)存在的數(shù)據(jù)項(xiàng)(這個(gè)數(shù)據(jù)項(xiàng)在客戶設(shè)備和服務(wù)器中都存在),

服務(wù)器必須能用客戶這個(gè)項(xiàng)的LUI標(biāo)識(shí).客戶端修改了數(shù)據(jù)項(xiàng),項(xiàng)也是用LUID標(biāo)識(shí),當(dāng)修改發(fā)送給服務(wù)器,服務(wù)器能過(guò)匹配LUID到GUID通過(guò)匹配表.

2.3.1 匹配操作的緩存

在SyncML客戶請(qǐng)求一個(gè)或多個(gè)增加之后,客戶端已經(jīng)完成了這些增加,并且給它們指定了LUID,如果服務(wù)器沒(méi)有明確的規(guī)定需要需要一個(gè)同步消息的情況下,客戶端能夠緩存這些LUID的匹配操作.客戶端也允許立即給服務(wù)器發(fā)送匹配操作.

如果匹配項(xiàng)被緩存,在接下來(lái)的同步session中,匹配操作被發(fā)送給服務(wù)器.

在客戶端能處理與這些數(shù)據(jù)項(xiàng)的時(shí)候(增加的但是匹配操作被緩存了的數(shù)據(jù)項(xiàng)),匹配操作必須送出. 如果SyncML服務(wù)器有傳輸控制協(xié)議(OBEX),它必須請(qǐng)求一個(gè)同步命令的響應(yīng).

在獲得客戶的同步命令之前服務(wù)器不能斷開(kāi)連接

2.4 沖突處理

服務(wù)器和客戶端同時(shí)修改相同的數(shù)據(jù)項(xiàng)的時(shí)候會(huì)發(fā)生沖突,一般在服務(wù)設(shè)備的同步引擎(sync engine)中解決. 本協(xié)議和表示層協(xié)議提供的功能告訴客戶端已經(jīng)解決的沖突.

一般認(rèn)為同步引擎包含在SyncML 服務(wù)器中,然而,客戶端也可以提供同步引擎處理沖突.

對(duì)于后一種情況,服務(wù)器僅僅告訴客戶端發(fā)生了沖突,客戶端能夠處理這些沖突.

有很多的策略來(lái)解決這些沖突,對(duì)于常見(jiàn)的策略,SyncML表示層協(xié)議提供狀態(tài)碼(status codes).服務(wù)器的同步引擎能夠解決沖突,并且發(fā)送沖突信息和沖突是如何解決的.這些通知信息包含在status元素中.

下面是一個(gè)例子描述了服務(wù)器發(fā)送狀態(tài)碼給客戶設(shè)備.

<Cmd>Replace</Cmd>

</Status>

如何管理和配置策略,超出了本協(xié)議和SyncML表示層協(xié)議的范圍

2.5 安全

本協(xié)議要求支持基本認(rèn)證和MD5數(shù)字簽名,服務(wù)器和客戶端能夠交換授權(quán)信息.

認(rèn)證過(guò)程參考第三章

2.6地址

2.6.1 設(shè)備和服務(wù)的地址

SyncML規(guī)范使用URI 標(biāo)志對(duì)SyncML SyncHdr頭元素中的設(shè)備和服務(wù)地址進(jìn)行編址。

設(shè)備通常；連接Internet，要參考URI基礎(chǔ)的編址，源可能是：

<LocURI>http://www.syncml.org/sync-server</LocURI>

</Source>

臨時(shí)連接的設(shè)備，可能是不用它自己的標(biāo)識(shí)機(jī)制表示，移動(dòng)手機(jī)設(shè)備的源可能是：

</Source>

如何使用這只類型的編碼機(jī)制，在傳輸層和設(shè)備和服務(wù)地址是比匹配的。

2.6.1.1 RespURI和Re-direction 狀態(tài)碼的用法

在SyncML協(xié)議規(guī)范中第一了RespURI元素。本協(xié)議要求設(shè)備支持接收RespURI元素，但是可以不支持Re-direction（3xx）狀態(tài)碼。

2.6.2 數(shù)據(jù)庫(kù)的編址

在SyncML 操作中的數(shù)據(jù)庫(kù)編址使用的是URI機(jī)制，對(duì)客戶端和服務(wù)端的編址可以使用絕對(duì)和相對(duì)的URI 。在兩種情況下，服務(wù)端數(shù)據(jù)庫(kù)的source元素可以如下：

<Sync>...

<LocURI>./calendar/james_bond</LocURI>

</Target>

...</Sync>

<Sync>

<LocURI>http://www.syncml.org/sync-server/calendar/james_bond</LocURI>

</Target>

...</Sync>

2.6.3 數(shù)據(jù)項(xiàng)的編址

在SyncML Item元素中的數(shù)據(jù)項(xiàng)的編址是使用URI-based ?？梢允褂孟鄬?duì)的URI‘s。

一個(gè)數(shù)據(jù)項(xiàng)的源元素可以如下：

<Item>...

</Source>

...</Item>

2.7交換設(shè)計(jì)的能力

本協(xié)議提供了在同步初始化階段交換設(shè)備的能力（參考第四章）， sync 客戶或sync 服務(wù)器都可以發(fā)送交換請(qǐng)求。當(dāng)最初的同步完成前或客戶更新了靜態(tài)設(shè)備信息，Sync 客戶必須送它的設(shè)備信息到服務(wù)器。如果服務(wù)端要求客戶端的設(shè)備信息，客戶端必須把它的設(shè)備信息發(fā)送給服務(wù)器。這個(gè)客戶應(yīng)該并且支持接受服務(wù)器設(shè)備信息。如果客戶端要求服務(wù)端的設(shè)備信息，服務(wù)端必須發(fā)送它的設(shè)備信息給客戶端，服務(wù)器必須支持功能獲得和處理客戶設(shè)備信息，這些設(shè)備信息可以是客服端發(fā)送的或者是服務(wù)端請(qǐng)求的。

實(shí)施考慮。設(shè)備信息的交換信息可能需求傳送大相當(dāng)數(shù)量數(shù)據(jù)。因而, 每次當(dāng)同步初始化時(shí),設(shè)備應(yīng)該避免請(qǐng)求交換。另外, 如果客戶端確切其它設(shè)備不可能支持它設(shè)備能力，客戶端應(yīng)該考慮是否它需要寄發(fā)所有設(shè)備具體數(shù)據(jù)。

如果客戶端清楚的表明它不支持這個(gè)vCard3.0 內(nèi)容格式, 服務(wù)器支持vCard3.0，但服務(wù)器不應(yīng)該送vCard3.0 的屬性信息。

2.8 設(shè)備內(nèi)存管理

本協(xié)議與Meta信息DTD 提供指定設(shè)備數(shù)據(jù)庫(kù)的動(dòng)態(tài)內(nèi)存或在設(shè)備上面堅(jiān)持存貯的內(nèi)存的能力。有多少剩余的內(nèi)存可以被使用。每次同步的時(shí)候都可以交換這些設(shè)備能力。當(dāng)sync 初始化完成時(shí)，靜態(tài)內(nèi)存能力被交換。 (參見(jiàn)第二章七節(jié)和第四章) 。

雖然，同步客戶和服務(wù)器發(fā)送內(nèi)存能力是可選的，同步客戶應(yīng)該送這些并且同步服務(wù)器也可以。

不同的類型的內(nèi)存能力的用法是依賴于設(shè)備的存貯模型。下面有一個(gè)例子說(shuō)明怎樣表示一個(gè)設(shè)備上的日歷數(shù)據(jù)庫(kù)的動(dòng)態(tài)內(nèi)存的能力, 當(dāng)發(fā)送同步命令：

<Sync>

<Target><LocURI>./calendar/james_bond</LocURI></Target>

<Source><LocURI>./dev-calendar</LocURI></Source>

<Meta>

</Mem>

</Meta>

...

</Replace>

...

</Sync>

在同步命令的Meta元素的數(shù)據(jù)庫(kù)具體內(nèi)存元素必須同在同步命令中的Source元素指定的源數(shù)據(jù)庫(kù)相關(guān)聯(lián) 在一起來(lái)源數(shù)據(jù)庫(kù)指定在Sync 命令的來(lái)源元素。

因而, 這個(gè)數(shù)據(jù)庫(kù)不在在Meta 元素中指定。

2.8 包中多條消息

本協(xié)議提供在多個(gè)SyncML消息中傳遞一個(gè)SyncML包。如果一個(gè)SyncML 包對(duì)于一條SyncML 消息太大，這種情況可能是由于傳輸協(xié)議或者小設(shè)備的原因?qū)е碌?。如果在多條SyncML 消息中傳送一個(gè)SyncML 包，最后一條消息必須包含F(xiàn)ianl元素，屬于這個(gè)包的其他消息一定不要包含F(xiàn)inal元素。當(dāng)一個(gè)包中所有的命令發(fā)送完以后，F(xiàn)inal元素必須包含在這些命令之后。如果一個(gè)包中的其他項(xiàng)沒(méi)有結(jié)束，則不能包含F(xiàn)inal元素。例如, 如果服務(wù)器仍然送這個(gè)包#4給客戶, 這個(gè)客戶不能關(guān)閉包裹#5早于在接受包# 4的最后一條消息前。如果一個(gè)錯(cuò)誤發(fā)送，不能用Final元素表明邏輯階段沒(méi)有完成。

如果設(shè)備接受最后的一條消息，這條消息包含了Sync元素但是缺少了Final元素，設(shè)備必須能夠在下條消息中處理這種情況, 下條消息中中有其它 Sync 元素同步相同的數(shù)據(jù)庫(kù)。

接受包含多種消息的SyncML包的設(shè)備必須能夠要求更多消息。要求更多消息是通過(guò)發(fā)送Alert命令，并且指定alert 代碼。222代碼將被返回或者有其他的SyncML命令返回，333 alert代碼可以被省去。

這發(fā)生由送一個(gè)機(jī)敏命令與一個(gè)具體機(jī)敏代碼, 222 回到這個(gè)包裹的創(chuàng)作者, 或如果有其它SyncML 命令被送作為反應(yīng), 機(jī) 敏命令與這個(gè)222 機(jī)敏代碼也許被省去。在接受這則消息以后包含最后的元素, 機(jī)敏命令不能被使用。在收到包含了Final元素的消息以后，Alert命令不能在使用。

如果發(fā)送了錯(cuò)誤，同步將被終止，不要在發(fā)送更多的消息。

當(dāng)包的發(fā)送者要求更多的消息的時(shí)候，包的接收者開(kāi)始發(fā)送它的下一個(gè)包。在第三章第七節(jié)，它被指定在接受到包含F(xiàn)inal元素的消息之前，命令或元素被允許發(fā)送，包含F(xiàn)inal元素的消息和發(fā)送命令或元素的消息屬于同一個(gè)包。

下面這個(gè)例子說(shuō)明了一個(gè)同步客戶在多個(gè)消息（2個(gè)消息）中發(fā)送包＃3和服務(wù)器在多個(gè)消息（2個(gè)消息）中發(fā)送包＃4。

2.10 大對(duì)象的處理

本協(xié)議提供方法同步那些大小超出在一則消息之內(nèi)傳送的對(duì)象。通過(guò)分割對(duì)象成能是否消息能夠被傳送的小部分，使用< MoreData / > 元素告訴接收者，這個(gè)大塊數(shù)據(jù)項(xiàng)目還沒(méi)有完成，還會(huì)有其他的部分傳送過(guò)來(lái)。

當(dāng)接收者接收到一個(gè)包含<MoreData/> 元素的對(duì)象，它必須響應(yīng)“214-小部分對(duì)象收到并且緩存了”和，并且，如果不需要發(fā)送其他的命令，使用alert 222（在第二章第九部分）機(jī)制要求下一條消息。

能夠在一條消息中傳輸?shù)膶?duì)象不能使用<MoreData/>元素，分割成幾個(gè)小部分的對(duì)象，處理最后一條傳送消息中不包含<MoreData/>元素，其他的傳送消息都需要包含。

發(fā)送者不能增加新的數(shù)據(jù)對(duì)象到任何一條消息知道前面的數(shù)據(jù)對(duì)象發(fā)送完成。分割成小部分的對(duì)象必須連續(xù)的發(fā)送，新的命令或者新的數(shù)據(jù)項(xiàng)不能在中間發(fā)送。

2.1 沒(méi)有單獨(dú)初始化的同步

同步可以在沒(méi)有單獨(dú)初始化的情況下開(kāi)始(參考第四章的初始化同步), 初始化可以和同步同時(shí)進(jìn)行,這樣可以減少傳送SyncML 消息的數(shù)量.

如果同步?jīng)]有初始化過(guò)程,在包#1(客戶發(fā)送的)中的Alert命令將放置在包#3中,包#3中同時(shí)也放置了Sync命令. 在包#2中的Alert命令(服務(wù)端發(fā)送的)將放置在包#4中,在包#4中同時(shí)也放置了Sync命令.

同步服務(wù)器必須能夠處理這兩種情況:在同步命令前沒(méi)有單獨(dú)的初始化和在同步命令前有單獨(dú)的初始化.

參考附件中的例子.

2.11.1 強(qiáng)壯性和安全性

如果客戶決定采用沒(méi)有單獨(dú)的初始化過(guò)程的同步,下面的一些事情需要考慮:

在服務(wù)器獲得客戶的同步錨點(diǎn)前,客戶發(fā)送修改命令給服務(wù)器,這種情況下,獲得錨點(diǎn),如果服務(wù)端請(qǐng)求一個(gè)慢同步,那么,客戶端需要發(fā)送所有的數(shù)據(jù).

客戶端在沒(méi)有收到服務(wù)器的同步錨點(diǎn)之前,客戶發(fā)送了客戶端的修改.如果客戶需要請(qǐng)求一個(gè)慢同步,客戶早期(在包#3中)發(fā)送的數(shù)據(jù),可以不用在發(fā)送給服務(wù)器,但是所有的數(shù)據(jù)必須發(fā)送給服務(wù)器.

客戶發(fā)送給服務(wù)器它的修改在有任一種可能性使服務(wù)器送它的認(rèn)證(如果必須) 到這個(gè)客戶。即, 客戶不可能肯定是正確服務(wù)器通信。

2.12 忙信號(hào)

如何服務(wù)器能夠接收客戶的修改數(shù)據(jù),但是,它不能在合理的時(shí)間內(nèi)處理客戶的這個(gè)請(qǐng)求,服務(wù)器應(yīng)該發(fā)送忙的status 碼給客戶.

客戶端收到服務(wù)器的忙信號(hào)以后,客戶可以在晚些時(shí)候要求同步或者重新開(kāi)始一個(gè)同步.如何客戶重新開(kāi)始一個(gè)同步,那么客戶的Last 同步錨點(diǎn)一定不能被更新.

如果服務(wù)器發(fā)送了忙status碼給客戶后,沒(méi)有收到客戶的請(qǐng)求,那么服務(wù)器必須假設(shè)它將從頭開(kāi)始同步,服務(wù)器不能更新Last 錨點(diǎn),也不能修改客戶的Next錨點(diǎn).

2.12.1 服務(wù)器的忙status

服務(wù)器通過(guò)發(fā)送忙status 包給客戶通知服務(wù)器正忙.這個(gè)包可以在完全接收任何一個(gè)包之前. 在客戶請(qǐng)求包中的Syncbody部分有數(shù)據(jù)項(xiàng)和其它命令,忙status 包不能返回他們的狀態(tài)信息.

1.在忙status包中的元素的要求如下:

VerDTD元素的值必須四‘1.1‘;

VerProto元素的值必須是‘SyncML/1.1‘;

Session ID 必須能夠表明一個(gè)同步Sesson 的ID

MsgID 必須明確的表明它屬于一個(gè)session 的第幾個(gè)包消息(服務(wù)端發(fā)送給客戶的)

Target 元素指定目標(biāo)設(shè)備

Source 元素指明原設(shè)備或者服務(wù)

2.對(duì)SyncHdr元素的status元素必須包含在SyncBody.

status 碼(101 正在處理)必須返回,這個(gè)狀態(tài)碼是位SyncHdr的.

2.12.1.1 Example of Busy Status

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

</Status>

</SyncBody>

</SyncML>

2.12.2 客戶的結(jié)果(Result) Alert 命令

結(jié)果Alert命令是客戶發(fā)送給服務(wù)器要求上一條消息的結(jié)果的命令.客戶通過(guò)發(fā)送結(jié)果Alert命令給服務(wù)器.

在包中消息的要求如下:

1.在SyncHdr元素中的元素要求如下:

VerDTD元素的值必須四‘1.1‘;

VerProto元素的值必須是‘SyncML/1.1‘;

Session ID 必須能夠表明一個(gè)同步Sesson 的ID

MsgID 必須明確的表明它屬于一個(gè)session 的第幾個(gè)包消息(服務(wù)端發(fā)送給客戶的)

Target 元素指定目標(biāo)設(shè)備或者服務(wù)

Source 元素指明原設(shè)備

2.alert元素必須包含在SyncBody中,Alert元素的要求如下:

CmdID是需要的

Item 元素指明服務(wù)和客戶設(shè)備

Data 元素用來(lái)包含Alert 碼,Alert碼為 ‘221‘

3. Final元素一定不要包含.

如果服務(wù)器收到客戶的結(jié)果Alert時(shí),服務(wù)還是忙,那么服務(wù)器必須返回‘101‘status給客戶,這個(gè)狀態(tài)碼對(duì)于客戶發(fā)送的消息的SyncHdr和Alert命令.

2.12.2.1 Example of Result Alert

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

</SyncHdr>

<Alert>

<Item>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

</Item>

</Alert>

</SyncBody>

</SyncML>

3.鑒權(quán)

在這章中,使用 basic 和 MD5 數(shù)字簽名的授權(quán)過(guò)程. 這兩種方式設(shè)備都必須支持.

3.1 鑒權(quán)請(qǐng)求

如果返回給一個(gè)請(qǐng)求(消息或者命令)的響應(yīng)碼是401(沒(méi)有授權(quán))或者407(授權(quán)需要),那么這個(gè)請(qǐng)求是要求授權(quán)的.在這中情況下,返回給請(qǐng)求的Status命令必須包含包含一個(gè)Chal 元素. Chal元素包含對(duì)請(qǐng)求資源的授權(quán)要求.設(shè)備可能會(huì)使用Cred元素重復(fù)這個(gè)請(qǐng)求過(guò)程.如果這個(gè)請(qǐng)求包含了Cred元素,那么返回401碼表明授權(quán)被拒絕. 客戶和服務(wù)器都能夠要求授權(quán).

如果響應(yīng)碼是401的響應(yīng)包含和上次響應(yīng)相同的要求授權(quán)信息,并且用戶代理已經(jīng)認(rèn)證過(guò)至少一次,那么,用戶應(yīng)該給響應(yīng)一些相應(yīng)的診斷信息.

如果響應(yīng)碼是212(認(rèn)證通過(guò)),那么余下的同步過(guò)程不在需要認(rèn)證了.

在MD5數(shù)字簽名的認(rèn)證情況下,Chal元素能過(guò)被返回.在Chal元素中next nonce 熟悉必須用被使用,表明下個(gè)同步session 開(kāi)始的時(shí)候使用的簽名.

如果一個(gè)請(qǐng)求包含了安全認(rèn)證并且響應(yīng)碼是200(同步命令已經(jīng)成功完成),那么相同的認(rèn)證必須在下一個(gè)同步請(qǐng)求中發(fā)送.如果Chal元素被包含并且要求使用MD5數(shù)字簽名認(rèn)證.如何包含了Chal元素并且需要使用MD5數(shù)字簽名,一個(gè)新的數(shù)據(jù)簽名必須被創(chuàng)建,同樣也是MD5的數(shù)據(jù)簽名.在使用MD5數(shù)據(jù)簽名認(rèn)證的情況下,Chal元素能夠被返回.單下個(gè)請(qǐng)求開(kāi)始的時(shí)候,Chal中的next nonce必須被使用.

當(dāng)一個(gè)授權(quán)已經(jīng)發(fā)生,在整個(gè)seesion過(guò)程中必須使用相同的授權(quán)類型.

授權(quán)失敗(用戶ID和密碼錯(cuò)誤或者需要一個(gè)授權(quán))的要求如下:

響應(yīng)消息表明服務(wù)層的授權(quán)失敗,并且,響應(yīng)消息必須并且僅僅任包含Status命令(Put,get命令不能包含在響應(yīng)中),status 命令必須提供給收到的請(qǐng)求的每一個(gè)命令.

在session還要繼續(xù)的情況下,包含了合適的認(rèn)證的下一條消息必須包含一個(gè)

對(duì)SyncHdr的status,和前一條消息必須是相同的Session ID,當(dāng)授權(quán)失敗RespURI被指定的情況下,消息必須送給RespURI.

3.2 授權(quán)

當(dāng)收到包含了401或者407的響應(yīng)以后,請(qǐng)求如果需要重復(fù)發(fā)送,那么,請(qǐng)求必須包含Cred元素.另外,設(shè)備可以把包含chal元素的請(qǐng)求第一個(gè)發(fā)送,如果授權(quán)被配置成需要的.Cred 元素的內(nèi)容在文檔[1]中說(shuō)明.授權(quán)類型獨(dú)立請(qǐng)求或者預(yù)先配置.

3.3 服務(wù)層授權(quán)

當(dāng)需要授權(quán)時(shí)候,協(xié)議僅僅支持服務(wù)層的授權(quán)(在SyncHdr元素).設(shè)備必須支持服務(wù)層的授權(quán). 使用SyncHdr元素的Cred元素和Status命令完成服務(wù)層的授權(quán).在status命令中,授權(quán)請(qǐng)求被傳送.授權(quán)可以是雙方向的,客戶可以授權(quán)給服務(wù)器,服務(wù)器也可以授權(quán)給客戶.

3.4 數(shù)據(jù)庫(kù)層的授權(quán)

1.本規(guī)范規(guī)定設(shè)備可以支持?jǐn)?shù)據(jù)庫(kù)層的授權(quán).通過(guò)Alert元素中的Cred元素和和sync命令和status完成.在status命令中包含了早期定義的請(qǐng)求信息.認(rèn)證可以是雙方向的,客戶可以授權(quán)給服務(wù)器,服務(wù)器也可以授權(quán)給客戶.

3.5 授權(quán)例子

3.5.1 Basic授權(quán)請(qǐng)求

在這個(gè)例子中,可以試在沒(méi)有認(rèn)證信息的情況初始化同步,服務(wù)端先客戶請(qǐng)求服務(wù)層的認(rèn)證信息.客戶必須重發(fā)包#1,包#1中包含了認(rèn)證信息.服務(wù)接收認(rèn)證并且seesoin被授權(quán).在這個(gè)例子中,SyncBody的內(nèi)容沒(méi)有被包含.

Pkg #1 from Client

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

</SyncHdr>

...

</SyncBody>

</SyncML>

Pkg #2 from Server

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

<Chal>

<Meta>

<Type xmlns=‘syncml:metinf‘>syncml:auth-basic</Type>

</Meta>

</Chal>

</Status>

...

</SyncBody>

</SyncML>

Pkg #1 (with credentials) from Client

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

<Cred>

<Meta><Type xmlns=‘syncml:metinf‘>syncml:auth-basic</Type></Meta>

<Data>QnJ1Y2UyOk9oQmVoYXZl</Data> <!—base64 formatting of

"userid:password"-->

</Cred>

</SyncHdr>

...

</SyncBody>

</SyncML>

Pkg #2 from Server

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

</Status>

...

</SyncBody>

</SyncML>

3.5.2 MD5數(shù)據(jù)簽名認(rèn)證請(qǐng)求

在這個(gè)例子中,客戶試著在沒(méi)有任何的認(rèn)證的情況下開(kāi)始初始化同步(包#1),

服務(wù)器向客戶請(qǐng)求服務(wù)層的認(rèn)證.認(rèn)證類型是MD5.客戶必須重新發(fā)送包含了認(rèn)證

信息的包#1,服務(wù)器接收認(rèn)證,session被授權(quán).服務(wù)器發(fā)送下一個(gè)nonce 認(rèn)證給

客戶,客戶將使用她在下一個(gè)同步session 開(kāi)始的時(shí)候是用nonce的認(rèn)證.

在這個(gè)例子中,SyncBody的內(nèi)容沒(méi)有顯示.

Pkg #1 from Client

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

<LocName>Bruce2</LocName>

</Source>

</SyncHdr>

...

</SyncBody>

</SyncML>

Pkg #2 from Server

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

<Chal>

<Meta>

<Type xmlns=’syncml:metinf’>syncml:auth-md5</Type>

</Meta>

</Chal>

</Status>

...

</SyncBody>

</SyncML>

Pkg #1 (with credentials) from Client

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

<Cred>

<Meta><Type xmlns=‘syncml:metinf‘>syncml:auth-md5</Type></Meta>

<Data> Zz6EivR3yeaaENcRN6lpAQ==</Data>

<!-- Base64 coded MD5 for user “Bruce2”, password “OhBehave”,

nonce “Nonce” -->

</Cred>

</SyncHdr>

...

</SyncBody>

</SyncML>

Pkg #2 from Server

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

<Chal>

<Meta>

<Type xmlns=’syncml:metinf’>syncml:auth-md5</Type>

<NextNonce xmlns=’syncml:metinf’>LG3iZQhhdmKNHg==</NextNonce>

<!—This nonce is used at the next session.-->

</Meta>

</Chal>

</Status>

...

</SyncBody>

</SyncML>

4、同步初始化

實(shí)際的同步過(guò)程需要初始同步（參考章節(jié)5－7），初始同步過(guò)程可以傳送

和執(zhí)行同步命令（sync commands）。

在初始同步前，同步服務(wù)器（SyncML server）可能會(huì)提示同步客戶同步。

但是初始同步過(guò)程不能忽略。

初始同步的目的有：

1、服務(wù)器和客戶端在SyncML級(jí)別進(jìn)行權(quán)限認(rèn)證。

2、表明使用哪個(gè)數(shù)據(jù)庫(kù)和使用什么協(xié)議。

3、交換服務(wù)器和客戶設(shè)備的處理能力

前兩點(diǎn)通過(guò)SyncML表示層協(xié)議中的Alert命令實(shí)現(xiàn)。服務(wù)器和客戶設(shè)備必須支持實(shí)現(xiàn)上面的功能。

服務(wù)器和客戶設(shè)備交換能力可以通過(guò)SyncML表示層協(xié)議中的Put、Get命令和設(shè)備的DTD信息實(shí)現(xiàn)。

初始同步過(guò)程如下：在實(shí)際的同步信息中包含了有些處理過(guò)程（一些響應(yīng)）

上面圖像中的箭頭表示SyncML包。SyncML包可以包含一個(gè)或多個(gè)消息（messages）。

這個(gè)過(guò)程中的屬于的包共同一個(gè)Session，就是說(shuō)有相同的Session ID號(hào)。

每個(gè)包的目的和需要將在下節(jié)介紹。

4.1 客戶端（Client）的初始化請(qǐng)求

前面的章節(jié)提到，客戶端在初始化的時(shí)候，（Client）通知服務(wù)器需要同步哪個(gè)數(shù)據(jù)庫(kù)和使用哪種的同步類型。

同時(shí)，客戶端還能包含授權(quán)信息和服務(wù)能力（service capabilities。

在Alert命令中指示哪個(gè)數(shù)據(jù)庫(kù)需要同步。每一個(gè)數(shù)據(jù)庫(kù)需要使用一個(gè)單獨(dú)的Alert命令。

另外，Alert命令可以去exchange the sync anchors. 如果需要授權(quán)信息，必須要包含包頭

（SyncHdr）中包含Cred元素。數(shù)據(jù)可以是Basic或者M(jìn)D5加密的數(shù)字簽名。

可以通過(guò)在包體（SyncBody）元素中使用Put命令來(lái)交換服務(wù)器和設(shè)備的能力。

客戶端必須要服務(wù)和設(shè)備信息，這些信息可以從設(shè)備（Device）DTD中獲得。

客戶端發(fā)送給服務(wù)器的同步初始化包（在圖6 Pkg#1）的詳細(xì)需求如下：

4.在SyncHdr（包頭）元素中的要求如下：

A.VerDTD元素的值必須是‘1.1’。

B.必須VerProto元素來(lái)制定使用的協(xié)議和協(xié)議版本，其值必須為‘SyncML/1.1’

C. 必須制定同步的session ID

D. 必須使用Msgid清晰的表明消息屬于一個(gè)同步session（sync session）

E、如果需要認(rèn)證的，必須包含Cred元素。

5. 在指明需要使用哪些數(shù)據(jù)庫(kù)的時(shí)候，使用Alert元素。Alert元素需包含在SyncBody元素中，具體的要求如下：

A. 必須使用CmdID元素

B.Alert元素必須有響應(yīng)。

C.在Alert元素中必須包含Data元素。Data元素的值表明Alert代碼。具體參考Alert Codes。

D. item元素中的Target元素表明目標(biāo)數(shù)據(jù)源

E.item元素中的Source元素表明客戶的數(shù)據(jù)源

F.客戶的同步（sync anchors）必須包含在previous 和 current 同步（anchors），在Meta元素中包含同步（anchors）

6. 在服務(wù)端和客戶端交換服務(wù)能力，如何是客戶發(fā)給服務(wù)，需要在SyncBody元素中使用Put命令。

A.必須要CmdID

B.在Put命令的Meta元素中必須包含Type元素指明MetaInf DTD

C.在Item元素中的Source元素必須有一個(gè)值為‘./devinf11‘.

D.Data元素中包含的是設(shè)備和服務(wù)信息。

7.服務(wù)端向客戶發(fā)送服務(wù)能力，需要在SyncBody中使用Put命令。

A.必須要CmdID

B.在get命令的Meta元素中必須包含Type元素指明MetaInf DTD

C.在Item元素中的Target元素必須有一個(gè)值為‘./devinf11‘.

D.Data元素中包含的是設(shè)備和服務(wù)信息。

8、必須包含F(xiàn)inal元素表明這條信息結(jié)束

4.1.1 Example of Sync Initialization Package from Client

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

<Meta><Type xmlns=‘syncml:metinf‘>syncml:auth-basic</Type></Meta>

<Data>QnJ1Y2UyOk9oQmVoYXZl</Data>

</Cred>

<Meta> <!--The Meta is now used to indicate the maximum SyncML message size, which

client can receive.-->

</Meta>

</SyncHdr>

<Alert>

<Item>

<Target><LocURI>./contacts/james_bond</LocURI></Target>

<Source><LocURI>./dev-contacts</LocURI></Source>

<Meta>

</Anchor>

</Meta>

</Item>

</Alert>

<Put>

<Meta><Type xmlns=‘syncml:metinf‘>application/vnd.syncml-devinf+xml</Type></Meta>

<Item>

<Source><LocURI>./devinf11</LocURI></Source>

<Data>

<Man>Big Factory, Ltd.</Man>

<OEM>Jane‘s phones</OEM>

<DevTyp>phone</DevTyp>

<SourceRef>./contacts</SourceRef>

<DisplayName>Phonebook</DisplayName>

<Rx-Pref>

<CTType>text/x-vcard </CTType>

</Rx-Pref>

<Tx-Pref>

<CTType>text/x-vcard</CTType>

</Tx-Pref>

</DataStore>

<CTCap>

<CTType>text/x-vcard</CTType>

<PropName>BEGIN</PropName>

<ValEnum>VCARD</ValEnum>

<ValEnum>VCARD</ValEnum>

<PropName>VERSION</PropName>

<ParamName>VOICE</ParamName>

</CTCap>

</SyncCap>

</DevInf>

</Data>

</Item>

</Put>

<Get>

<Meta><Type xmlns=‘syncml:metinf‘>application/vnd.syncml-devinf+xml</Type></Meta>

<Item>

<Target><LocURI>./devinf11</LocURI></Target>

</Item>

</Get>

</SyncBody>

</SyncML>

5、兩方同步

兩方同步是最普通的一種同步類型，客戶端和服務(wù)端都需要相互交換修改了的

數(shù)據(jù)?？蛻舳送ǔＪ且环N設(shè)備，首先提交修改信息。服務(wù)端通過(guò)比較客戶提交

的修改信息，然后統(tǒng)一服務(wù)端的數(shù)據(jù)。服務(wù)器發(fā)送服務(wù)端的修改數(shù)據(jù)給客戶端

，客戶端根據(jù)這些數(shù)據(jù)統(tǒng)一客戶端的數(shù)據(jù)。

上圖的箭頭代表SyncML包，SyncML包可能保護(hù)一條或多條消息。上面的數(shù)據(jù)包

是在一個(gè)session中，也就是這些SyncML的session ID是相同的。

上面每個(gè)包的目的和要求將在下個(gè)章節(jié)介紹。

如何沒(méi)有獨(dú)立的同步初始化，上圖中包的編號(hào)可能和時(shí)間的包編號(hào)不一樣。

5.1 客戶端發(fā)送修改給服務(wù)器

為了同步，客戶端需要把客戶端的從上次同步以后的所有修改數(shù)據(jù)發(fā)送給服務(wù)器。發(fā)送了這個(gè)同步包以后的所有客戶端的修改數(shù)據(jù)，必須在下一個(gè)session中再發(fā)送（注意，是下一次同步過(guò)程了。）

客戶端發(fā)送給服務(wù)端的包的要求：

1.在SyncHdr元素中的元素要求：

a.VerDTD的值必須是‘1.1‘

b.VerProto元素的值必須是‘SyncML/1.1‘

c.Session ID 必須表示一個(gè)同步session的ID

d.MsgID必須能明確的表明屬于哪一個(gè)從客戶端發(fā)送給服務(wù)端的session

e.Target元素必須指明目標(biāo)地址

f.Source元素必須指明源地址

2.客戶端發(fā)送的Alert命令必須有Status返回.

a.服務(wù)器沒(méi)有授權(quán)使用的服務(wù),同步將發(fā)生錯(cuò)誤.如何有錯(cuò)誤發(fā)生,客戶端必須返回錯(cuò)誤信息

b.服務(wù)器的下一個(gè)同步貓點(diǎn)必須保護(hù)在Data元素中.

3.服務(wù)器發(fā)送設(shè)備信息給客戶端,客戶端應(yīng)該處理這些設(shè)備信息,Status必須返回給服務(wù)器,在Package #2收到前可以被發(fā)送.

4.如果服務(wù)器要求客戶端的設(shè)備信息,Results元素必須被發(fā)送,在Package #2

收到前可以被發(fā)送.

a.Type 元素的MetaInf DTD必須保護(hù)在Meta元素中.

b.在Results元素中的Source元素的值必須是‘./devinf11‘

5.Sync元素必須被包含在SyncBody元素中,要求如下:

a.需要CmdID元素

b.Sync命令的響應(yīng)是需要的

c.Target指明目標(biāo)數(shù)據(jù)庫(kù)

d.Source指明源數(shù)據(jù)庫(kù)

e.自由內(nèi)存應(yīng)該在Meta元素中指定,只用內(nèi)存可以是源數(shù)據(jù)庫(kù)中的自由內(nèi)存

數(shù)量或者是客戶設(shè)備的自由內(nèi)存數(shù)量,這些信息只能在一個(gè)包中的第一條

消息中發(fā)送

6.在客戶端的修改中,操作元素的要求如下:

a.CmdID是需要的

b.這些操作必須要有響應(yīng)

c.Source 元素必須包含,指明LUID,包含在數(shù)據(jù)項(xiàng)的Item元素中.

d.MetaInf DTD的Type 元素必須包含

e.如果不是deletion操作,操作數(shù)據(jù)必須在Data元素中傳送

7.Final元素必須包含,在包的最后,表示這是最后的消息

5.2 服務(wù)端發(fā)送給客戶端的修改

發(fā)送給客戶端的同步包(圖7包4)有如下的目的:

u 通知客戶端同步分析的結(jié)果.

u 通知服務(wù)端的修改數(shù)據(jù)

在發(fā)送這個(gè)包之后完成的服務(wù)端的任何一個(gè)修改,都必須在下一個(gè)同步

session中同步,不能把這些修改數(shù)據(jù)做為這次同步的子包.

1.同步包的要求如下:

a VerDTD元素的值必須是‘1.1‘;

b.VerProto元素的值必須是‘SyncML/1.1‘

c.必須包含Sesion ID表示session的ID號(hào).

d.MsgID 必須明確的指定屬于那個(gè)session ID.

e.Target必須指定目標(biāo)設(shè)備

f.Source元素必須指明源設(shè)備和服務(wù)

2.如果客戶端需要,Status元素必須不包含在SyncBody中,表明客戶端發(fā)送數(shù)據(jù)處理后返回的狀態(tài).數(shù)據(jù)項(xiàng)的Status信息在包3完全接收前發(fā)送.

3.Sync 元素必須包括在SyncBody, 如果沒(méi)有及早發(fā)生的錯(cuò)誤,這些錯(cuò)誤能防止服務(wù)器處理sync 分析和送它的修改回到客戶。 Sync 元素, 有以下要求:

1. CmdID元素是需要的

2. Syn 命令需要響應(yīng)

3. Target元素指向目標(biāo)數(shù)據(jù)庫(kù)

4. Source元素指向源數(shù)據(jù)庫(kù)

4.在前一次同步以后的所有服務(wù)端的修改,他們需要操作元素(Replace,Delete和Add)在sync元素中.

1. CmdID元素是需要的

2. 這些操作需要響應(yīng)

3. 如果操作是增加操作(addtion),Source定義一個(gè)臨時(shí)的數(shù)據(jù)項(xiàng)的GUID.

如果不是增加操作(addtion),Source必須不能包含.

4. 如果不是增加操作(addtion),Target元素必須包含定義一個(gè)LUID,

如果是增加操作(addtion),Target元素必須不能包含.

5. MetaInfo DTD中的Type元素必須包含在Meta元素中指明數(shù)據(jù)項(xiàng)的類型.

在一個(gè)操作內(nèi)或一個(gè)數(shù)據(jù)項(xiàng)內(nèi)可以被使用.

5.Final元素必須包含,表明這是包中的最后一條消息.

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

</Status>

<TargetRef>./contacts/james_bond</TargetRef>

<SourceRef>./dev-contacts</SourceRef>

</Status>

<MsgRef>2</MsgRef><CmdRef>4</CmdRef><Cmd>Replace</Cmd>

</Status>

<Sync>

客戶的數(shù)據(jù)更新?tīng)顟B(tài)

客戶給服務(wù)器的數(shù)據(jù)更新?tīng)顟B(tài)包包含呢客戶更新數(shù)據(jù)的結(jié)果信息和新數(shù)據(jù)項(xiàng)目的LUID,LUID和臨時(shí)的GUID的匹配操作也要送給服務(wù)器.

如果服務(wù)器表示它不需要最后一個(gè)包的響應(yīng),客戶可以不發(fā)送修改信息包給服務(wù)器.如果客戶不打算發(fā)送這條消息,它必須能夠在下次同步前緩存這些Map操作.可以也可以發(fā)送這些修改狀態(tài)給服務(wù)器,即使服務(wù)器沒(méi)有要求客戶發(fā)送.

在包里的消息的要求如下:

在SyncHdr元素中的要求如下:

A.VerDTD元素的值必須四‘1.1‘;

B. VerProto元素的值必須是‘SyncML/1.1‘;

C. Session ID 必須能夠表明一個(gè)同步Sesson 的ID

D. MsgID 必須明確的表明它屬于一個(gè)session 的第幾個(gè)包消息(服務(wù)端發(fā)送給客戶的)

E.Target 元素指定目標(biāo)設(shè)備或者服務(wù)

F.Source 元素指明原設(shè)備

2.如果服務(wù)器請(qǐng)求,status元素必須包含在SyncBody元素中.它表明客戶修改數(shù)據(jù)的狀態(tài).statua信息可以在包#4完全結(jié)束前發(fā)送.

3.如果客戶已經(jīng)處理呢服務(wù)器的修改到自己的數(shù)據(jù)庫(kù)中,在SyncBody元素中必須包含Map元素.操作了一個(gè)數(shù)據(jù)庫(kù),就必須有一個(gè)Map操作與之對(duì)應(yīng),這個(gè)命令必須在包#4完全結(jié)束后發(fā)送.

A. CMDID是需要的

B. 在Map元素中Source和Target元素是需要

C.對(duì)Map 操作需要有響應(yīng)

D.Map元素的數(shù)據(jù)項(xiàng)中包含客戶的LUID和服務(wù)端ID(臨時(shí)的GUID)

發(fā)送給服務(wù)器的數(shù)據(jù)更新?tīng)顟B(tài)的例子

<VerProto>SyncML/1.1</VerProto>

<Target><LocURI>http://www.syncml.org/sync-server</LocURI></Target>

</SyncHdr>

<MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<SourceRef> http://www.syncml.org/sync-server </SourceRef>

</Status>

<TargetRef>./dev-contacts</TargetRef>

<SourceRef>./contacts/james_bond</SourceRef>

</Status>

<MsgRef>2</MsgRef><CmdRef>5</CmdRef><Cmd>Replace</Cmd>

</Status>

</Status>

<Map>

<Target><LocURI>./contacts/james_bond</LocURI></Target>

<Source><LocURI>./dev-contacts</LocURI></Source>

</MapItem>

</Map>

</SyncBody>

</SyncML>

5.4 服務(wù)端對(duì)可以Map的應(yīng)答

服務(wù)器收到客戶的數(shù)據(jù)的匹配信息,服務(wù)器需要對(duì)客戶的這些信息做出回應(yīng).即使客戶的最后一個(gè)包中沒(méi)有任何的Map操作,服務(wù)器也要和客戶進(jìn)行回應(yīng).

包中消息的要求如下:

在SyncHdr元素中的要求如下:

A.VerDTD元素的值必須四‘1.1‘;

B. VerProto元素的值必須是‘SyncML/1.1‘;

C.Session ID 必須能夠表明一個(gè)同步Sesson 的ID

D.MsgID 必須明確的表明它屬于一個(gè)session 的第幾個(gè)包消息(服務(wù)端發(fā)送給客戶的)

E.Target 元素指定目標(biāo)設(shè)備

F.Source 元素指明原設(shè)備或者服務(wù)

G.消息中一定不能包含響應(yīng)(response)

2.在SyncBody中必須包含status元素,它用來(lái)表明Map操作的狀態(tài).這些

能夠在包#5完全接收前發(fā)送.

3.Final元素必須包含,表明這是包的結(jié)尾.

Map應(yīng)答的例子

<VerProto>SyncML/1.1</VerProto>

<Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source>

</SyncHdr>

<MsgRef>3</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>

<TargetRef>http://www.syncml.org/sync-server</TargetRef>

</Status>

<TargetRef>./contacts/james_bond </TargetRef>

<SourceRef>./dev-contacts</SourceRef>

</Status>

</SyncBody>

</SyncML>

中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频