RVP：存在和即時訊息傳送協議 (3) (轉)

RVP：存在和即時訊息傳送協議 (3) (轉)[@more@]

PROPFIND

PROPFIND DAV 方法用來獲取節點的屬性。屬性包含 PRESENCE INFORMATION 的一些元組（相關值的集合），如線上狀態或所代表的 PRINCIPAL 的顯示名稱。 對於 RVP，PROPFIND 方法用來從其它 PRINCIPALS 各自的本地上獲取其線上狀態。此方法還可以用來提取 RVP 實現可能保持的其它屬性，如在伺服器上的永久聯絡人列表。

PROPFIND 方法檢索在所請求的 URL 上定義的屬性。PRESENTITY 提交 REQUEST 方法主體中的 propfind 元素，此元素說明正在請求的資訊。請求特定的屬性值、所有屬性值或者資源屬性名稱的列表都是可能的。PRESENTITY 必須提交至少具有一個屬性的主體。

如果在檢索屬性時出現錯誤，則在響應中必須包括一個相應的錯誤結果。請求檢索一個不存在的屬性值是一個錯誤，並且必須加以記錄。如果響應使用一個多狀態 XML 元素，則必須返回一個包含 404 Not Found （未找到）狀態值的 XML 元素。

每個響應 XML 元素都必須包含一個 href XML 元素，它標識在其上定義了 prop XML 元素中的屬性的那個資源。作為一個平面列表返回對具有內部成員的資源的 PROPFIND 請求的結果，此列表中項的次序並不重要。

雖然 DAV 允許 PROPFIND 請求的深度為 0、1 或“無窮大”，其中“無窮大”是預設值，但是 RVP 要求深度標頭為零。這是由於以分佈方式實現名稱空間時支援其它深度有困難所造成的。如果深度標頭不存在或者深度引數不為零，則 RVP PRESENCE SERVICES 會返回狀態程式碼：412 -Precondition Failed（先決條件失敗）。

示例

以下示例說明如何檢索 RVP PRESENTITY 的顯示名屬性。

>>請求 PROPFIND /instmsg/aliases/deriks HTTP/1.1 Host: im.example.RVP-Notifications-Version: 0.2 RVP-From-Principal: Depth: 0 Content-type: text/xml Content-Length: XXXX >>響應 HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: XXXX RVP-Notifications-Version: 0.2 Derik Stenerson HTTP/1.1 200 OK

PROPPATCH

PROPPATCH DAV 方法用來設定節點的屬性。對於 RVP，此方法可以用來設定 PRESENCE SERVICE 上 PRINCIPAL 的線上狀態，或者設定 RVP 保持的其它屬性。例如，當一個 PRESENTITY “登入”時，PRESENTITY 向 PRESENTITY 的本地伺服器發出一個 PROPPATCH 請求，要求將線上狀態屬性設定為“線上”。

RVP 引入了租用屬性的概念。租用屬性值會在一段超時過後自動復位為預設值。在實現合作者列表的線上狀態時可以使用它們。例如，PRESENTITY 的線上狀態可以將自身復位為離線狀態，除非它被重新整理。這在客戶機崩潰、失敗或其它必須將 PRESENTITY 狀態復位為離線的情況下有用。

儘管 RVP 實現可能禁止租用特定的屬性值，但是所有的 RVP 屬性都可以具有租用值。PRESENTITIES 獲取和設定租用值的方式與處理常規 DAV 屬性的方式相同；由 PRESENCE SERVICE 負責識別和解釋租用值並強制其行為。如果所請求的超時是 RVP PRESENCE SERVICE 的管理策略所不允許的，則 RVP PRESENCE SERVICE 可能拒絕設定屬性值。

XML 架構允許在 PROPPATCH 請求和響應中指定一個檢視識別符號元素，因為某個節點可能有多個 PRESENTITIES 設定屬性（即從多臺機器登入的）。此規範允許將狀態更改複製到所有 PRESENTITIES 中，並且允許某些狀態是某個 PRESENTITY 所特有的。例如，如果一個 PRINCIPAL 讓多個 PRESENTITIES 登入，則任何狀態更改為 "busy"（繁忙） 或 "out to lunch"（出去就餐）將導致所有的 PRESENTITIES 都得到此狀態更改的通知。然而，如果某個 PRESENTITY 變為離線的或空閒的，則其它的 PRESENTITY 不會得到此狀態更改的通知，並且 PRINCIPAL 在不同的 PRESENTITY 上仍然保持線上。

當 PROPPATCH 請求不包含檢視識別符號時，一個成功的響應會包含一個。此識別符號對租用屬性和指定此檢視識別符號的任何後續 PROPPATCH 請求是唯一的。如果具有該檢視識別符號的所有租用屬性到期，則該識別符號不再有效，也不應該使用它。

示例

以下示例將一個 RVP PRESENTITY 的線上狀態值設定為線上，時間間隔是一小時。除非該屬性隨後由 PRESENTITY 復位，否則 PRESENCE SERVICE 會在一小時後將線上值轉變回離線。

>>請求: PROPPATCH /instmsg/aliases/deriks HTTP/1.1 Host: im.example.com RVP-Notifications-Version: 0.2 RVP-From-Principal: Content-Type: text/xml Content-Length: XXXX 3600 >>響應: HTTP/1.1 207 Multi-Status RVP-Notifications-Version: 0.2 Content-Type: text/xml Content-Length: XXXX 3600 3577 HTTP/1.1 200 OK

實現的考慮事項

RVP PRESENTITY 使用 PROPPATCH 方法以及租用值將其線上狀態屬性保持為線上。PRESENTITY 使用一些超時值（即 t），使 PRESENCE SERVICE 在經過 t 之後從線上狀態屬性轉變回離線。

如果 PRINCIPAL 繼續在 PRESENTITY 上登入，則 PRESENTITY 應該透過在 t 到期之前發出另一個 PROPPATCH 請求，並就屬性獲得時間間隔為 t 的新租用，以便重新整理線上狀態屬性。因此，如果 t=30 分鐘，則 PRESENTITY 應該在大約 29 分鐘時發出另一個 PROPPATCH 請求。否則，如果 PRESENTITY 在 30 分鐘時發出一個 PROPPATCH 請求，則新的 PROPPATCH 請求可能會在第一次租用到期之後到達 PRESENCE SERVICE。在這種情況下，PRINCIPAL 線上狀態的任何訂閱者（即在其聯絡人列表上有此 PRINCIPAL 的所有 WATCHERS ）可能獲得虛假的通知 — 一個釋出給正在登出的 PRINCIPAL，而緊接著的另一個則釋出給再次登入的 PRINCIPAL。

幾個考慮事項確定應該使用的正確 t 值。如果 PRESENTITY 是 OUT OF CONTACT（（失去聯絡，即 PRESENTITY 崩潰），則 PRESENCE SERVICE 將無法知道 PRESENTITY 已經崩潰，並且在租用到期之前，PRINCIPAL 的線上狀態屬性一直保持線上。因此，即使 PRINCIPAL 處於離線狀態，t 也會限制 WATCHERS 繼續將 PRINCIPAL 視為“線上”的時間間隔。將 WATCHER 的聯絡人列表的狀態保持為“新的”，要求 t 較小 — 理想的情況是接近於零。

然而，如果 PRINCIPAL 已登入，則 PRESENTITY 必須重新發出 PROPPATCH 請求，其時間間隔小於 t，以便保持線上狀態。因此，每個登入的 PRESENTITY 都會消耗 PRESENCE SERVICE 的資源，因為 PRESENTITY 有效地 "" PRESENCE SERVICE，其時間間隔小於 t。甚至在空閒狀態下，這也會產生網路通訊量。如果一個 PRESENCE SERVICE 上登入了成千上萬的 PRESENTITIES，則此負載可以是相當大的。要使 ping 負載得到控制，請將 t 設定為儘可能大的值，以便每個 PRINCIPAL 的都不會降級。

注：  2000 Server Instant Messaging 使用的 ping 時間間隔為 20 分鐘。

NOTIFY

RVP NOTIFY 方法，取自 GENA，將非同步通知傳送到 RVP 節點 — 即通知接收器。當一個 WATCHER A 透過本地伺服器向另一個 PRINCIPAL B 上的屬性更改發出 SUBSCRIBE 請求時，WATCHER A 會接收到 PRINCIPAL B 上的屬性更改的 NOTIFY 請求。

注： 請求主體中的通知 XML 元素包含通知資料。

在不建立較早訂閱的情況下也可以發出 NOTIFY 訊息。例如，假定具有正確的訪問控制，則任何實體都可以將 NOTIFY 訊息傳送到一個組節點（如 ）；組節點無須向任何其它節點發出 SUBSCRIBE 請求。

在一個 intr 中，NOTIFY 訊息通常由本地伺服器用來將通知傳送到它們的 INSTANT INBOXES。NOTIFY 訊息也由 PRESENCE SERVICES 用來將它們託管的 PRESENTITIES 的線上狀態更改傳送到其它 PRESENCE SERVICES。

因為 NOTIFY 訊息的發件人可能要求確認傳送，所以一旦完成了傳送就會發出成功響應。為了確定 NOTIFY 訊息的發件人何時對完成傳送和要求確認滿意，會出現一個新的 RVP-Ack-Type 標頭。此標頭可以包含以下欄位。

• SingleHop 只是在最初收件人（即本地伺服器）接收 NOTIFY 訊息時，發件人才請求確認。 
  
  
• DeepOr 發件人僅在最終目標之一接收到 NOTIFY 時才請求確認。此用法的一個示例是，當使用者將一個 INSTANT MESSAGE 傳送給委託人或者印表機缺紙時，要求員之一得到通知。
  
  
• DeepAnd 發件人僅在所有最終目標接收到 NOTIFY 訊息時才請求確認。此用法的一個示例是，訊息被髮送到一個組或分發列表，且有多個 WATCHERS 正在等待 NOTIFY 訊息。

此外，在 NOTIFY 請求中，另一個標頭是 RVP-Hop-Count。這是一個基於 1 的值，指定為產生此請求已經發生了多少次轉發。

客戶機->伺服器  RVP-Hop-Count = 1

伺服器->伺服器  RVP-Hop-Count = 2

伺服器->客戶機  RVP-Hop-Count = 3

NOTIFY 方法使用新的 RVP XML 元素：message、propnotification、notification-from、notification-to、contact、description、msgbody 和 mime-data。

示例

此示例說明 PRESENTITY 如何將即時訊息傳送到 INSTANT INBOX 。

>>請求 NOTIFY /instmsg/aliases/maxb HTTP/1.1 Host: im.acmewidgets.com RVP-Notifications-Version: 0.2 RVP-Ack-Type: DeepOr RVP-Hop-Count: 1 RVP-From-Principal: Content-Type: text/xml Content-length: XXXX Derik Stenerson max >>響應 HTTP/1.1 200 Succesul RVP-Notifications-Version: 0.2

此示例說明在 deriks 登入時 NOTIFY 訊息是如何傳送給 maxb 的。為了此示例所要達到的目的，PRINCIPAL 位於聯絡人列表 上，並且 maxb 已經訂閱了 deriks 的線上狀態。 

>>請求 NOTIFY / HTTP/1.1 RVP-Hop-Count: 2 RVP-Notifications-Version: 0.2 Host: 128.1.1.11 Content-Length: XXXX Content-Type: text/xml RVP-From-Principal: im.example.com >>響應 HTTP/1.1 200 Successful RVP-Notifications-Version:0.2

ACL

ACL 方法為 XML 架構提供了一些補充。訪問控制列表 (ACL) 用來確定誰可以訪問和節點上的資訊。例如，它限制 WATCHER 檢視 PRESENTITY 是否線上的能力。

RVP ACL 的名稱空間與 DAV ACL 的稍有不同，因為有幾個元素是不需要的，另外又新增了幾個新元素。名稱空間是 。