view release on metacpan or  search on metacpan

docs/draft-calsyn-rvp-01.txt  view on Meta::CPAN

       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
          properties in order to preserve the privacy of users.  These ACLs
          MUST allow the user to determine who may subscribe to, get
          properties from, put properties to, make/delete nodes within, and
          send messages to their user object and its child nodes.  The ACLs