Header
Support the headers below for DAV / HTTP: DAV and DEPTH. The new RVP header includes RVP-Notifications-Version, Call-back, subscription-id, subscription-lifetime, and notification-type.
Existing DAV / HTTP header
The RVP implementation can ignore all DAV-specific headers unless otherwise stated.
DAV header
Since the current version of this protocol is just partially compliant with DAV, the server never returns to this header and ignores it in the request.
DEPTH header
This header that only supports only zero in the propFind method, which is required in this method.
New RVP header
RVP-Notifications-Version
This header provides the version number of the notification protocol. Each request and response must include this header.
Call-back
This header is taken from GENA, is used in the subscribe method; it gives the URL of the asynchronous Notify callback of the subscription notification.
Subscription-id
This header is taken from GENA, which is used in the Subscribe request / response and NOTIFY and UNSUBSCRIBE requests. It gives the unique identifier of the subscribe.
Subscription-Lifetime
This header is taken from GENA and is used in the Subscribe method. If you rent a subscription, it indicates that more information is required (in the request) subscription and actual (in response) timeout.
Notification-Type
This header is taken from GENA and is used in the Subscribe method. It indicates the required notification type (within the Gena frame).
The value can be UPDATE / PROPCHANGE or PRAGMA / NOTIFY, and can be extended to other values.
RVP-ACK-TYPE
This header determines when the sender of the Notify message is satisfied with the completion of the transmission and request. It can have Singlehop, Deepor, or DeepAnd value.
Rvp-hop-count
This header is used to indicate how many times forwarded to generate this request, including the source of the Notify message (initially set to 1).
RVP-from-Principal
This header indicates the source of this method. It is usually a logic URL of the sender.
Return code
RVP uses several existing HTTP return codes, as well as several returns from DAV. Here are the usual return code:
200 Successful
This code indicates that the request has been successfully implemented.
207 MultiStatus
This code will be received as a response to the PropPatch or PROPFIND request. This request has a text / HTML HTTP body, which has a single XML element called MultiStatus. The MultiStatus element has a set of XML elements called responses, including state code of 200, 300, 400, and 500 series, which is generated during the call method.
302 OBJECT MOVED
This code indicates that the requested node is not maintained by the server. The response includes a new URL of the node. As a response to the request emitted to the router, this type of response is usually received.
401 Access Denied
This code indicates that a node has rejected access. When the Presence Service is trying to access the protected node, it uses this code as a response. The response header contains details of the available authorization scheme.
412 Precondition Failed
This code indicates that the request cannot be applied to the requested node. An example of its usage is that when an entity attempts to send instant message to a no longer available Principal.
500 INTERNAL Server Error This code indicates that Principal is missing in the session. For example, this return code will be used when a Principal is discussed with multiple Principals, and its Instant Inbox receives this return. Then, the sender of Instant Message can indicate that the Principal has left the dialog.
XML document type definition
The following is the element used in DAV:
set
Prop
TIMEOUT
DisplayName
Subscription
Subscription-id
HREF
Subscriptions
MultiStatus
Response
PROPSTAT
PropertyUpdate
RVP element
The following table describes the elements provided by RVP.
Element defines the parent's role State
DAV:
Indicates the current status information of the node, Leased-Value
Indicates the "current rental value" State Default-Value
Indicates the current default state of the node (currently "
"
,
Or
one)
Value
Indicates the current state of the node (currently "
"
or
one)
ONLINE
|
Indicates "Online" state OFFLINE
|
Indicates "offline" status Away
|
Indicates the "departure" state busy
|
Indicates "Busy" Status Back-Soon
|
Indicates the "Quick return" Status on-Phone
|
Indicates the "telephone" status AT-LUNCH
|
Indicates the "lunch" state view-id
Provide unique identifiers for nodes Principal
Contains details about Principal RVP-Principal
Detailed note of Principal's logic Urlemail
DAV:
Contains details of the email address about Principal Mobile Mobile-State
DAV:
Determine the movement of Principal (ie, mobile phone) status is online Mobile-Description
DAV:
Description Principal's mobile (ie, mobile phone) NOTIFICATION
NONE indicates an instant message or an update to Principal status. PropNotification
Indicates that the state of Principal changes MESSAGE
Indicates that send or receive an instant information Notification-from
|
Source of notification or message Notification-to
|
Indicates that the notification or message should be sent to Who MSGBody
Message Contact with MIME encoded with MIME you need to send
|
Detailed explanation How to contact Principal Contact Description
Description contact information MIME-DATA
Contracts actual instant message to send or receive
MIME payload
Three types of payload can be passed within the MIME data notified. The following sections contain details of each of these payloads.
Instant messaging
This payload is the most common type. It is usually used to send some text between two Principals. MIME data as follows:
Type a message
This payload is used to indicate that Principal is typing. In Exchange 2000 Server, these notices are sent once every 4 seconds.
Application invitation
Use this payload when the request is started.
Reference
These articles can be found on the Internet Engineering Working Group (English) Web site:
"A Model for Presence and Instant Messaging," DAY, M., J. Rosenberg, And H. Sugano, RFC 2778 [Model].
HTTP Extensions for Distributed Authoring, Goland Y., E. Whitehead, A. Faizi, S. Carter and D. Jensen, RFC 2518 [WebDAV]. Hypertext Transfer Protocol HTTP / 1.1, Fielding, R. J. GetTys, J. Mogul, H. Frystyk, And T. Berners-Lee, RFC 2068 [http].
"Instant Messaging / Presence Protocol Requirements," DAY, M., S. Aggarwal, G. Mohr, And J. Vincent RFC 2779, [IMPP-REQTS].
