RVP: Presence and Instant Messaging Protocol (4)

access permission

Supported Elements Define Permissions with Read, Write, Readacl, WriteaCl, and ALL. No supported access has Writeowner, Delete, CreateChild and deletechild. New access elements with allow or DENY parent are specified below.

Name Functions Send-TO Determining Who Allows WhoSence Messages NonePresence determines who access Presence information NoneList determines who lists the property nonereceive-from determines who will receive notifications and subscription notifications NoneSubscriptions determine who is allowed to access the subscription list NoneSubscribe-Others determines who allows you to subscribe to properties and notification None using unrecognized callbacks

Principal

All RVP Principals have a unique identifier, which is their logical URL. In order to identify this Principal within the ACL, each tag pair must contain one and only one child and child.

Name Define Parent Function RVP-Principal Packs an RVP URL and makes it different from any other Principal, regardless of what it is. Any valid RVP Principal identifier (PRINCIPAL identifier like http://im.acme.com/instmsg/maxb or the presence service identifier like im.acme.com). NULL values ​​are not allowed. Presence Service will remove blank around the RVP Principal identifier. Presence Service will never be generated in . It is important to note that there is no form of Principal inheritance (ie im.example.com is not http://im.example.com/instmsg/maxb's supercoming exceptions). If a Principal is connected to the accepted credentials (as part of the element) in , it should look at Principal, as if the Principal is not available. The same is listed in the ACL. If you do not specify a credential, or if is empty, you must use 400-CRedentials Not Specified to reject the ACL manipulation. Credentials Uniquely identifies the credentials you must give. Any set of one or more valid credential identifiers (currently " " or ""). NTLM Indicates that Principal must meet a NTLM challenge from Presence Service. After setting the ACL, Presence Service should not check the existence of specified Principal. Nonedigest Indicates that Principal must meet a Digest challenge from Presence Service. After setting the ACL, Presence Service should not check the existence of specified Principal. NoneAssrtion Indicates that Principal does not need to give the credentials to prove its identity. NoneInternal Indicates that Principal must prove its identity by relying on some of the PRESENCE SERVICE (another process, such as email, phone, etc.). Noneany indicates that Principal, which gives any valid credentials should be considered this Principal. None

Note: AllauthPrincipals, a representative provides a general collection of all Principal, which provides some form of authentication, Principal, for the identifier, and not support. Example

When a presentity starts, it needs to get the current Principal's ACL. The following example illustrates all Watchers (except http://im.examples/maxb), how is it allowed to get a notification of Principal and send a notification. It also illustrates all permissions of its own nodes in http://im.acme.com/instmsg/aliases/maxb.

>> request

ACL / Instarsg / AliaseS / MaxB HTTP / 1.1

RVP-Notifications-Version: 0.2

Host: im.acme.com

Content-Length: 0

Rvp-from-principal: http://im.acme.com/instmsg/aliases/maxb

>> Response

HTTP / 1.1 200 Successful

Content-Type: Text / XML

Content-Length: XXXX

RVP-Notifications-Version: 0.2

None

http://im.example.com/instmsg/aliases/maxb/

http://im.acme.com/instmsg/aliases/maxb

Other methods

These HTTP methods are not supported by GET, HEAD, POST, and PUT. If these methods are received, 501-Not Implement should be returned.

These DAV methods are also not supported by Copy, Move, Lock, UNLOCK, and OPTIONS. Copy and Move should return an error code 405-Method Not ALLOWED (not allowing this method). If you receive Lock, Unlock, and Options, you should return the error code 501-Not Implement.

Authentication

Authentication is done within RVP by using the HTTP / 1.1 method. This allows the Presence Service to refuse access to protection resources by returning a status code 401-unauthorized (unauthorized) and at least one WWW-Authenticate header that specifies the authorized architecture. In RVP, two architectures are allowed: NTLM (NT LAN Manager) and Digest Access authentication.

RVP uses HTTP Challenge - Response Authentication, this authentication allows Presence Service to provide the Allowed authentication type for Presentity. Then expect Presentity to try again according to the return authentication information.

NT LAN Manager (NTLM)

Since the username and password are not moved in the network in the form of a clear text (unencrypted), the NT LAN Manager authentication provided by Exchange 2000 Server allows PRESENTITY to authenticate with a safe approach.

Digest Access Authentication

DiGest Access authentication verifies whether the two sides share a secret (ie password), this secret does not pass in the form of a plain text. For more information on Digest Access authentication, see RFC 2617-TTP Authentication: Basic and Digest Access Authentication. This authentication architecture can be used in a platform (such as UNIX) that does not support NTLM.

Example

The following example illustrates requests and responses that allow Presentity to authenticate on their own nodes. As shown in the Subscribe request example, Principal is called http://im.acme.com/instmsg/aliases/maxb. This example illustrates the server to reject the initial request and specify the available authentication scheme is NTLM and Digest. Then, the client uses NTLM authentication to issue a second request.

>> request

Subscribe / Instmsg / AliaseS / Maxb HTTP / 1.1

SUBSCRIPTION-LIETIME: 14400

Notification-Type: Pragma / Notify

Call-back: http://198.176.154.132:1234

RVP-Notifications-Version: 0.2host: Imhome1.acme.com

Content-Length: 0

Rvp-from-principal: http://im.acme.com/instmsg/aliases/maxb

>> Response

HTTP / 1.1 401 Access Denied

Www-automate: Negotiate

WWW-Authenticate: NTLM

Www-authenticate: Digest QOP = "auth", realm = "im .acme.com",

Nonce = "78a8ffeeb123458a400358100000B4D0ED33AE239123441B44896487FEDA"

Content-Type: Text / HTML

Content-Length: XXXX

RVP-Notifications-Version: 0.2

>> request

Subscribe / Instmsg / AliaseS / Maxb HTTP / 1.1

Subscription-Lifetime: 14400

Notification-Type: Pragma / Notify

Call-back: http://198.176.154.132:1234

RVP-Notifications-Version: 0.2

Host: imHome1.acme.com

Content-Length: 0

Authorization: NTLM

Tlrmtvntuaadabcdgaayaf4aaaaabgadgaaaaaaaababcdgaoaeaaaaaqabaatg

Aaaaaaaacoaaaabykaghiabwbiaguacgb0ag8augbpaeiarqbs

>> Response

HTTP / 1.1 200 Successful

Subscription-ID: 98210

Subscription-Lifetime: 14400

RVP-Notifications-Version: 0.2