Net-RVP
view release on metacpan or search on metacpan
docs/draft-calsyn-rvp-01.txt view on Meta::CPAN
interactions and client-server/server-server interactions are
defined below in such a way to minimize dynamic server state
while preserving network bandwidth and giving the clients a
predictable level of reliability.
5.1.7. Subscriptions
Subscriptions are usually registered ultimately at the server
that publishes information. The exception is the case where a
proxy that receives a new subscription request already has a
subscription to that data AND the data is public. Since the
proxy will already be getting notifications on that data, the
proxy can fan out notifications to individual end-points. Since
the first subscription always goes to the publishing server, and
the response indicates whether the data is public or controlled,
the proxy knows how to handle additional subscriptions.
A subscription request always includes:
- The source of the subscription (for access control)
- The call-back address
- Desired timeout value for subscription
The response to a subscription always includes:
- Whether the events being subscribed to are public or
controlled
- What the subscription-ID is (so it can be referred to if it
needs to be cancelled)
- What timeout was assigned to the subscription
- Whether the subscription must be cancelled if the subscriber
goes offline
If a client subscribes to a proxy server which in turn subscribes
to a publishing server, then the client's RVP address is listed
as the source, but the proxy's address is listed as the call-back
address. The subscription response (OK, failure) is proxied back
to the originator.
Calsyn, Dusseault & Mohr [Page 9]
INTERNET-DRAFT RVP March 13, 1997
The subscription originator stores the timeout value (a date/time formatted with RFC 1123 as specified in schema draft), so that
the originator can refresh the subscription before it times out.
When the originator wishes to cancel the subscription, it can do
so by specifying the subscription-ID. The same mechanism is used
when the client goes offline, for any subscriptions listed as
such.
Issues: Can one person subscribe another person? How should we
handle Reply-Tos that are different from the subscription
requester?
5.1.8. Multiple client issues
The issues for multiple clients connected at the same time
haven't been worked out yet. Which ones should receive instant
messages? If one client is "idle" and one client is "busy" what
is the user marked as?
Is there any way for another user to query the status of a
particular client? E.g. to see if the desktop is idle while the
laptop is active & vice-versa? Also, idea of addressing IM's to
a particular online client?
If multiple clients are connected, and the home server refers to
one client, that client is primary. Other clients must send
their status to the primary client.
6. Security
6.1. Authentication
Users may log in to their home RVP server, but this is not
required. Each request MAY contain user credentials, using HTTP
syntax, in order to authenticate the user to the server which
will actually process the request.
Upon receiving a request for the return or modification of
information, the server processing the request MUST validate the
authentication and honor any access control list entries which
might gate the completion of the request.
Return codes in HTTP style should be provided for indicating
insufficient access rights.
6.2. Content Protection
In addition to authentication contained in the headers and
intended for server authorization, the content (contained in the
entity) MAY be signed and or sealed according to prevailing MIME
encoding, signing and encryption standards.
Calsyn, Dusseault & Mohr [Page 10]
INTERNET-DRAFT RVP March 13, 1997
This content signing/sealing is the mechanism for ensuring
against message-stream modification, replay and/or repudiation.
6.3. Server-to-Server Security
Servers may exchange server credentials along with user
credentials. Servers which are acting on a request will use
embedded credentials to authenticate and authorize the requesting
user or process. Server implementations MAY choose to support
SSL or other authentication mechanism, but this is generally
redundant and highly consumptive of CPU resources.
Private messages should be secured from endpoint to endpoint.
6.4. Privacy Issues
Each RVP server MUST support and honor ACLs placed on objects and
docs/draft-calsyn-rvp-01.txt view on Meta::CPAN
10.2.17. Request-ID
A token to uniquely identify a request to the requestor, opaque
to the destination of a request. When generating a response to a
request that has a "Request-ID" header, the "Request-ID" header
must be including verbatim in the response
10.2.18. Server
See section 14.39 of the HTTP/1.1 specification [5]. Optionally
used to specify server software version.
10.2.19. Session-ID
Sent with a NOTIFY message when there is no subscription-ID; used
to maintain context in replies to that notification.
10.2.20. Subscription-ID
Sent with a successful response to a subscription message. Used
in future notifications which result from that subscription, or
to cancel subscription.
10.2.21. Via
As in HTTP/1.1, used when a message is proxied.
10.2.22. XML-body
Used to specify ACL levels with the ACL method, and sometimes to
specify notification-type. Not fully defined yet. In
particular, the authors need to define what subset of all
possible XML semantics must be supported by an implementation.
Calsyn, Dusseault & Mohr [Page 20]
INTERNET-DRAFT RVP March 13, 1997
It must be possible for a simple implementation to refuse complex
XML bodies not defined as required in this draft.
10.3. Responses
HTTP/1.1 responses are expanded to include these new codes or
enhanced meaning:
RVP/1.0 207 SUBSCRIBE
RVP/1.0 ??? REFER (or we could use 302 "Moved Temporarily")
Existing HTTP/1.1 responses used in RVP:
HTTP/1.1 400 Bad Request (bad syntax)
HTTP/1.1 401 Unauthorized (Need to get authenticated first)
HTTP/1.1 402 Forbidden (ACLs forbid user to do that)
HTTP/1.1 404 Not Found (object or property not found)
HTTP/1.1 501 Not Implemented (method not understood by server)
HTTP/1.1 503 Service Unavailable (i.e. too busy)
10.4. Proxying and Referral
The default behavior for a RVP object on a server is for that
server to respond to queries and subscriptions and receive
instant messages for that object. However, there are exceptional
circumstances. Both servers and clients can optionally support
these features.
Each RVP object may have a property named "LINK". The value of
the LINK property is [link-method], [RVP-URL]. When the property
is set using the PUT method, there may be a timeout property
included with standard timeout syntax (never, date/time, logout).
If the expiration is reached before the property value is
refreshed, the server should reset the LINK property to NULL.
The link-method can be PROXY, REFER, REFER-NOTIFICATIONS or LINK.
The RVP-URL must be a full URL, including DNS address and path.
Proxying a node means that rather than respond for the object,
the server will forward requests to the address listed in the
RVP-URL, and will also proxy replies. If the server is ever
unable to proxy because the host has become unavailable, it
should immediately timeout the LINK property and go back to
handling queries itself. Proxies are intended to be used with
firewalls: a RVP proxy can sit on a firewall and route messages.
Referring an object means that the server will respond to any
request, subscription or instant message with a referral to the
address listed in the RVP-URL, requiring the originating client
of the request, subscription or message to repeat it to the
referred address. It may be desirable for the server to PING the
referral address periodically to ensure that the referral is
still valid: if the host is no longer available the value of LINK
might go back to null.
Calsyn, Dusseault & Mohr [Page 21]
INTERNET-DRAFT RVP March 13, 1997
"REFER-NOTIFICATIONS" indicates that:
- Unsolicited messages to the user should go to the referral
address
- Requests should continue to come to the object's home
- Notifications in response to a subscription should continue to
be sent to the Reply-To specified in the subscription. The
Reply-To address should always be tried first.
A LINK value of LINK typically indicates a link to the "real"
home of the content requested: this allows content to be linked
to from more than one node. One node is the real home for the
object and all duplicate nodes link to the real home.
When an entity decides to start hosting an object by setting the
LINK field on that object's home node, it may wish to download
all the object data including the subscription list from the
server that was previously responsible for it. Ideally the GET
command which asks for all the node’s data would be bundled with
the PUT command which switches responsibility using the LINK
( run in 0.778 second using v1.01-cache-2.11-cpan-df04353d9ac )