Net-RVP
view release on metacpan or search on metacpan
docs/RVP_specification.txt view on Meta::CPAN
4.1 Architecture .......................................... 4
4.1.1 General Interaction ............................... 5
4.1.2 Addressing ........................................ 5
4.2 Authentication ........................................ 6
4.3 Examples .............................................. 6
5. Protocol Methods ........................................... 7
5.1 SUBSCRIBE ............................................. 7
5.1.1 Subscribtion Ids .................................. 7
5.1.2 Leased subscriptions .............................. 7
5.1.3 Notification types ................................ 8
5.1.4 Notification delivery ............................. 8
5.1.5 Changing/discarding subscriptions ................. 9
5.1.6 Response .......................................... 9
5.1.7 Examples .......................................... 9
5.1.7.1 Login Subscription ........................... 9
5.1.7.2 Property subscription ....................... 10
5.2 UNSUBSCRIBE .......................................... 11
5.2.1 Example .......................................... 11
5.3 SUBSCRIPTIONS ........................................ 11
5.3.1 Example .......................................... 12
5.4 PROPFIND ............................................. 13
5.4.1 Example .......................................... 13
5.5 PROPPATCH ............................................ 14
5.5.1 Example .......................................... 15
5.5.2 Implementation considerations .................... 17
5.6 NOTIFY ............................................... 18
5.6.1 Examples ......................................... 19
5.7 ACL .................................................. 24
5.7.1 Access rights .................................... 24
5.7.2 Principals ....................................... 25
5.7.2.1 Credentials ................................. 25
5.7.2.2 ntlm ........................................ 26
5.7.2.3 digest ...................................... 26
5.7.2.4 assertion ................................... 26
Osborne et al 2
RVP
5.7.2.5 internal .................................... 26
5.7.2.6 any ......................................... 26
5.7.3 Examples ......................................... 27
5.8 Other methods ........................................ 28
6. Authentication ............................................ 29
6.1 NT Lan Manager (NTLM) ................................ 29
6.2 Digest Access Authentication ......................... 29
6.3 Example .............................................. 29
7. Headers ................................................... 30
7.1 Existing DAV/HTTP headers ............................ 30
7.2 RVP headers .......................................... 31
8. Return codes .............................................. 31
9. XML Document Type Definition .............................. 32
9.1 RVP elements ......................................... 33
9.1.1 State ............................................ 33
9.1.2 leased-value ..................................... 33
9.1.3 default-value .................................... 33
9.1.4 value ............................................ 33
9.1.5 online ........................................... 33
9.1.6 offline .......................................... 33
9.1.7 away ............................................. 34
9.1.8 busy ............................................. 34
9.1.9 back-soon . ...................................... 34
9.1.10 on-phone ...................................... 34
9.1.11 at-lunch ...................................... 34
9.1.12 view-id ....................................... 34
9.1.13 principal ..................................... 34
9.1.14 rvp-principal ................................. 34
9.1.15 email ... ..................................... 34
9.1.16 mobile-state .................................. 35
9.1.17 mobile-description ............................ 35
9.1.18 notification .................................. 35
9.1.19 propnotification .............................. 35
9.1.20 message ....................................... 35
9.1.21 notification-from ............................. 35
9.1.22 notification-to ............................... 35
9.1.23 msgbody ....................................... 35
9.1.24 contact ....................................... 36
9.1.25 description ................................... 36
9.1.26 mime-data ..................................... 36
10. MIME Payloads ............................................ 36
10.1 Instant Message ...................................... 36
10.2 Typing Message ....................................... 36
10.3 Application Invites .................................. 37
11. References ............................................... 37
12. Author’s Addresses ....................................... 38
3. Overview
RVP is designed to enable subscriptions and notifications within
an organization, and across a loosely coupled (federated)
constellation of organizations. These organizations may contain
large, scalable server farms, or may be small one-server
operations.
Osborne et al 3
RVP
RVP is a strict extension of HTTP/1.1. Being used on HTTP allows
RVP to leverage existing flexible and well-known technologies,
such as Firewall support, and Proxies. Also the requirements of
basic Authentication and Redirection have already been addressed
within HTTP.
4. Protocol Introduction
RVP-specific information is general transferred in new methods or
by specifying the RVP namespace in XML-formatted data within the
XML body of an HTTP protocol element. Use of XML in this way
allows an RVP server to coexist with an HTTP server. XML is used
in order to provide flexibility and extensibility.
4.1 Architecture
RVP allows for WATCHERs to obtain PRESENCE INFORMATION, for
PRESENTITYs to determine what WATCHERs are obtaining it’s
PRESENCE INFORMATION, and send INSTANT MESSAGEs to an INSTANT
MESSAGE INBOX within the current or different domain. To
accomplish this the architecture within Microsoft Exchange 2000
can be as follows (see [MODEL] and [IMPP-REQTS] for definitions
docs/RVP_specification.txt view on Meta::CPAN
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:Z="http://schemas.microsoft.com/rvp/">
<D:response>
<D:href>
http://im.example.com/instmsg/aliases/stevem
</D:href>
<D:propstat>
<D:prop>
<D:displayname>
Steve Morgan
</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
5.5 PROPPATCH
The PROPPATCH DAV method is used to set a node’s properties. For
RVP, this method can be used to set a PRINCIPAL’s online status
on a PRESENCE SERVICE or to set other properties maintained by an
RVP implementation. For example, when a PRESENTITY “logs on”,
the PRESENTITY will issue a PROPPATCH to the PRESENTITY’s home
server to set the “online-status” property to “online”.
RVP introduces the notion of “leased properties”. Leased
property values automatically reset to a default value after a
timeout period. They can be used to implement buddy list online
status – a PRESENTITY’s online status can reset itself to the
offline state unless refreshed. This is useful for scenarios
involving client crashes, network failures, etc. that necessitate
resetting a PRESENTITY’s status to offline.
All RVP properties can have leased values, though RVP
implementations may disallow leasing the values of particular
properties.
Osborne et al 14
RVP
PRESENTITYs get and set leased values in the exact same fashion
as they do regular DAV properties - it is up to the PRESENCE
SERVICE to recognize and interpret leased values and enforce
their behavior
An RVP PRESENCE SERVICE may decline to set a property value if
the requested timeout is not permitted by its admin policy.
As there may be multiple PRESENTITYs setting properties for a
certain node (i.e. User logs in from multiple machines), the XML
schema allows for a view identifier element to be specified in
the PROPPATCH requests and responses. This allows state changes
to be replicated amongst all PRESENTITYs, and certain states to
be specific to a PRESENTITY.
For example if a PRINCIPAL has multiple PRESENTITYs logged in,
any state changes to be “busy”, or “out to lunch”, will result in
all PRESENTITYs being notified of this status change. However if
a certain PRESENTITY became offline or idle, then no other
PRESENTITYs would be notified of this status change, and the
PRINCIPAL would remain online at a different PRESENTITY.
When a PROPPATCH request does not contain a view identifier, a
successful response will include one. This identifier is unique
to that leased property, and any subsequent PROPPATCH requests
that specify the view identifier. If all leased properties, with
that view identifier, expire then it is no longer valid and
should not be used.
5.5.1 Example
This example sets the “online-status” value of an RVP PRESENTITY
to “online”, for an interval of 1 hour. Unless the property is
subsequently reset by the PRESENTITY, the PRESENCE SERVICE will
revert the “online” value to “offline” after 1 hour.
>>Request:
PROPPATCH /instmsg/aliases/stevem HTTP/1.1
Host: im.example.com
RVP-Notifications-Version: 1.0
RVP-From-Principal: http://im.example.com/instmsg/aliases/stevem
Content-Type: text/xml
Content-Length: XXXX
<?xml version="1.0"?>
<D:propupdate xmlns:D="DAV:"
xmlns:Z="http://schemas.microsoft.com/rvp/">
<D:set>
<D:prop>
<Z:state>
<Z:leased-value>
<Z:value>
Osborne et al 15
RVP
<Z:online/>
</Z:value>
<Z:default-value>
<Z:offline/>
</Z:default-value>
<Z:timeout>3600</Z:timeout>
</Z:leased-value>
</Z:state>
</D:prop>
</D:set>
</D:propertyupdate>
>>Response:
HTTP/1.1 207 Multi-Status
RVP-Notifications-Version: 1.0
Content-Type: text/xml
Content-Length: XXXX
docs/RVP_specification.txt view on Meta::CPAN
The request could not be applied to the requested node. An
example of its use is when attempting to send an Instant Message
to a PRINCIPAL who is no longer available.
500 Internal Server Error
An example of this use is when a PRINCIPAL has left a discussion
with multiple PRINCIPALs. When the PRINCIPALs INSTANT MESSAGE
INBOX receives a notification for this session, it would use this
return code. The sender of the INSTANT MESSAGE would then be able
to indicate that the PRINCIPAL has left the conversation.
9. XML Document Type Definition
DAV elements
The elements that are used from DAV are as follows:
set
prop
timeout
displayname
subscription
subscription-id
href
subscriptions
multistatus
response
propstat
propertyupdate
9.1 RVP elements
The elements provided by RVP are as follows:
9.1.1 state
Definition: <!Element state (leased-value, view-id?)>
Parent: DAV:<prop>
Purpose: To indicate the current state information for the
node.
9.1.2 leased-value
Definition: <!Element leased-value (value, default-value,
timeout)>
Parent: <state>
Purpose: To indicate the current leased values status
9.1.3 default-value
Definition: <!Element default-value ANY>
Parent: <leased-value>
Osborne et al 32
RVP
Purpose: To indicate the current default status of the node
(currently one of “<online> <offline> <away> <busy>”
<back-soon> <on-phone> or <at-lunch>)
9.1.4 value
Definition: <!Element value ANY>
Parent: <leased-value>
Purpose: To indicate the current status of the node
(currently one of “<online> <offline> <away> <busy>”
<back-soon> <on-phone> or <at-lunch>)
9.1.5 online
Definition: <!Element online EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the online status
9.1.6 offline
Definition: <!Element offline EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the offline status
9.1.7 away
Definition: <!Element away EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the away status
9.1.8 busy
Definition: <!Element busy EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the busy status
9.1.9 back-soon
Definition: <!Element back-soon EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the back soon status
9.1.10 on-phone
Definition: <!Element on-phone EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the on the phone status
9.1.11 at-lunch
Definition: <!Element at-lunch EMPTY>
Parent: <default-value> | <value>
Purpose: To indicate the at lunch status
Osborne et al 33
RVP
9.1.12 view-id
Definition: <!Element view-id (#PCDATA)>
Parent: <state>
Purpose: A unique identifier for updates to a node
9.1.13 principal
Definition: <!Element principal (rvp-principal)>
Parent: <subscription>
Purpose: Container for details about the PRINCIPAL
9.1.14 rvp-principal
Definition: <!Element rvp-principal (#PCDATA)>
Parent <principal>
Purpose: To detail the logical URL for a PRINCIPAL
9.1.15 email
Definition: <!Element email (#PCDATA)>
Parent: DAV:<prop>
Purpose: Contains details of the PRINCIPAL’s email address
9.1.16 mobile-state
Definition: <!Element mobile-state (0 | 1)>
Parent: DAV:<prop>
Purpose: Determines if PRINCIPAL’s mobile is online
9.1.17 mobile-description
Definition: <!Element mobile-description (#PCDATA)>
Parent: DAV:<prop>
Purpose: Description of PRINCIPAL’s mobile (e.g. Cell phone
number)
( run in 0.311 second using v1.01-cache-2.11-cpan-df04353d9ac )