[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-rosenberg-simple-data-req) 00 01 02 03

SIMPLE WG                                                   J. Rosenberg
Internet-Draft                                               Dynamicsoft
Expires: December 26, 2003                                    M. Isomaki
                                                   Nokia Research Center
                                                           June 27, 2003


  Requirements for Manipulation of Data Elements in Session Initiation
      Protocol (SIP) for Instant Messaging and Presence Leveraging
                      Extensions (SIMPLE) Systems
                     draft-ietf-simple-data-req-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 26, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   In any presence application, it is frequently necessary for the user
   to configure a number of pieces of information. Users will need to
   manipulate their presentity list, adding and removing presentities,
   and manipulate their authorization lists, which specify the set of
   users that can subscribe to their presence. In this document, we
   provide a framework and requirements for such data manipulations.






Rosenberg & Isomaki    Expires December 26, 2003                [Page 1]


Internet-Draft       Data Manipulation Requirements            June 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Resource List Manipulation Requirements  . . . . . . . . . . .  6
   6.  Authorization Policy Manipulation  . . . . . . . . . . . . . .  8
   6.1 Acceptance Policy Requirements . . . . . . . . . . . . . . . .  8
   6.2 Notification Requirements  . . . . . . . . . . . . . . . . . .  9
   6.3 Content Requirements . . . . . . . . . . . . . . . . . . . . . 10
   6.4 General Requirements . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Changes from version 02  . . . . . . . . . . . . . . . . . . . 13
       Informative References . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15

































Rosenberg & Isomaki    Expires December 26, 2003                [Page 2]


Internet-Draft       Data Manipulation Requirements            June 2003


1. Introduction

   Consumer-based instant messaging and presence applications typically
   provide a rich set of features. In addition to being able to
   subscribe to, and get notified of, changes in presence, users can
   also configure the operation of the application.

   Most systems allow the user to add or remove users from their 'buddy
   list', which we refer to here as a resource list. The resource list
   is the set of presentities [2] that a user is subscribed to. This
   list is frequently stored on the server, allowing the user to
   generate a single subscription to the entire list. The server then
   'fans out' that subscription to all the presentities on the list.
   Subscription to resource lists is supported through the SIP event
   notification extension for resource lists [6]. However, no automated
   means is currently defined to create these lists, add users to them,
   remove users from them, or query for the set of users on the list.

   Similarly, most systems support user-defined authorization policies.
   A user can specify which watchers are (or are not) allowed to
   subscribe to their presence, and furthermore, what aspects of their
   presence a watcher is able to see. While SIMPLE [3] systems can
   support such authorization policies, besides human-driven techniques,
   such as web or voice response, there is no automated way to specify
   these policies.

   In this document, we propose a framework and a set of requirements
   for manipulation of resource lists and authorization policies.
   Further data manipulation requirements may be defined in the future,
   but they are out of the scope of this document.

2. Conventions

   In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
   'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
   and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1]
   and indicate requirement levels for compliant implementations.

3. Terminology

   This document uses the following terminology:


   Resource list:  A resource list is a set of presentities, each of
      which is identified by a URI. The list itself is identified by a
      URI (for example, sip:myfriends@example.com). Using the SIP event
      extension for resource lists [6], a watcher can subscribe to the
      resource list and learn about the presence state of all the



Rosenberg & Isomaki    Expires December 26, 2003                [Page 3]


Internet-Draft       Data Manipulation Requirements            June 2003


      presentities in the set.

   Presence Authorization Policy:  Presence authorization policy refers
      to the set of directives given to a presence agent on what
      subscriptions to accept, when to generate notifications for a
      subscription, and what information should be placed in those
      notifications.

   Acceptance Policy:  The component of presence authorization policy
      that determines whether or not to accept a subscription from a
      watcher.

   Notification Policy:  The component of presence authorization policy
      that determines when a notification should be sent to a watcher.

   Content Policy:   The component of presence authorization that
      determines the content of the information provided to a watcher in
      a notification.

   SIMPLE Data Elements:  SIMPLE data elements are user specified data
      that determine the behavior of a presence agent. This includes
      resource lists and presence authorization policy.

   Data Manipulation Client:  A data manipulation client is a protocol
      agent that reads, writes, and receives notifications of changes in
      SIMPLE data elements.

   Data Manipulation Server:  A data manipulation server is a protocol
      agent that receives reads, writes, and sends notifications of
      changes in SIMPLE data elements. The server is responsible for the
      storage of the SIMPLE data elements.


4. Framework

   The framework for the usage and manipulation of SIMPLE data elements
   are shown in Figure 1.



         SUBSCRIBE    |--------|
        ------------->|        |<---|    //-----\\
        <-------------|   PA   |    |   ||       ||
         NOTIFY       |--------|    |---|\\-----//|
                                        |         |
                                        | Storage |
                                        |         |
                                     |->|---------|



Rosenberg & Isomaki    Expires December 26, 2003                [Page 4]


Internet-Draft       Data Manipulation Requirements            June 2003


                      |--------|     |
                      |        |<----|
                      | Server |   Read/Write
                      |--------|
                         ^  |
                         |  |  RL/Auth manipulations
                         |  v
                         |--------|
                      |        |
                      | Client |
                      |--------|


               Figure 1: Framework for Data Manipulation


   The data manipulation client (just referred to as the client) uses
   some protocol, whose requirements are specified here, to interact
   with the data manipulation server. Those interactions include
   requests to read a SIMPLE data element, write one, or receive
   notifications in changes to one. The data manipulation server (just
   referred to as the server) manages a persistent store of the SIMPLE
   data elements, and interacts with the client.

   When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it
   may require access to SIMPLE data elements in order to process the
   request. For example, if the subscription is for a resource list, the
   PA will need to determine that this is the case, and secondly,
   'expand' the resource list, obtaining the list of URIs for that
   resource list.

   If the SUBSCRIBE request is for a presentity, the PA will need to
   obtain the presence authorization policy of that presentity in order
   to process the SUBSCRIBE request.

   In both cases, the PA requires only read access to the data. As a
   result, it obtains it directly from the data store, rather than
   interacting with the server. This, of course, is just a model of the
   system; a real implementation might involve interaction with the
   server before reading the data.

   Between the resource list and presence authorization policy, the
   presence authorization policy is a far more complicated piece of
   data. The authorization policy can be reasonably split into three
   separate pieces. The first, which we call the acceptance policy,
   determines whether or not to grant a subscription to the subscriber.
   This policy results in a binary decision. The second piece, which we
   call the notification policy, determines when that particular



Rosenberg & Isomaki    Expires December 26, 2003                [Page 5]


Internet-Draft       Data Manipulation Requirements            June 2003


   subscriber should receive notifications. For example, a subscriber
   might only be permitted to see when I log in or log out of IM, but
   not receive notifications when my phone goes on hook. This is closely
   related to the third piece, which we call the content policy. This
   policy specifies the content of the information present in a
   notification that is sent to a subscriber.

   All of these policies are data that is manipulated by the data
   manipulation protocol.

5. Resource List Manipulation Requirements

   The following are the set of requirements for the protocol between
   the client and the server for the purposes of manipulation resource
   lists. It is obvious that similar requirements would apply to lists
   used by other applications than presence as well, but those are
   outside the scope of this document.


   REQ PC-1:  It MUST be possible for the client to create resource
      lists and associate each of them with a distinct URI.

   REQ PC-2:  It MUST be possible for the user to specify the URI for
      the resource list when one is created. If the name cannot be
      allocated (because it already exists, for example), it MUST be
      possible to inform the client of the failure, and the reason for
      it.

   REQ PC-3:  It MUST be possible for the server to provide the client a
      URI for the list when one is created, in the case where the client
      does not provide it.

   REQ PC-4:  It MUST be possible to associate a display name with a
      resource list.

   REQ PC-5:  It MUST be possible to add an entry to the resource list.
      Each entry MUST be able to include at least a URI, and a display
      name. It MUST be possible for the entry to be any URI that is
      meaningful in the context of a resource list. Examples would
      include a SIP URI or pres URI [7].

   REQ PC-6:  It MUST be possible to extend the set of information
      associated with the entries in the resource list and with the list
      itself. An example would be a filtering document associated with
      the list.






Rosenberg & Isomaki    Expires December 26, 2003                [Page 6]


Internet-Draft       Data Manipulation Requirements            June 2003


   REQ PC-7:  It MUST be possible for a resource list to contain entries
      which are themselves resource lists.

   REQ PC-8:  It MUST be possible to remove an entry from the resource
      list. If the entry does not exist, it MUST be possible for the
      server to inform the client of this fact.

   REQ PC-9:  It MUST be possible to modify an entry in the resource
      list.

   REQ PC-10:  It MUST be possible to clear all entries from a resource
      list.

   REQ PC-11:  It MUST be possible to query for the set of URIs and
      other possible information related to a particular resource list
      by providing the URI for the resource list.

   REQ PC-12:  It MUST be possible to delete a resource list. In this
      context, deleted means that the name of the resource list is no
      longer defined, so that subscriptions to the list would fail.

   REQ PC-13:  It MUST be possible for a user to retrieve the list of
      resource lists that they have created.

   REQ PC-14:  It MUST be possible for the resource list to be
      associated with a list of authorized users who are able to query
      for the set of URIs and other possible information related to the
      list.

   REQ PC-15:  It MUST be possible for the resource list to be
      associated with a list of authorized users who are the only ones
      permitted to manipulate the resource list.

   REQ PC-16:  It MUST be possible for the resource list to be
      associated with a list of authorized users who are authorized to
      subscribe to the list.

   REQ PC-17:  It MUST be possible for a client to store a cached copy
      of the list. It MUST be possible for the client to manipulate the
      local cached copy even when there is no connectivity to the
      server. It MUST be possible to synchronize the cached copy with
      the master copy on the server, when connectivity is
      re-established.

      This particular requirement is crucial for wireless systems, where
      a copy of the list resides on the handset. Without this
      requirement, a user would not be able to view the list, or add a
      user to it, when they go out of coverage.



Rosenberg & Isomaki    Expires December 26, 2003                [Page 7]


Internet-Draft       Data Manipulation Requirements            June 2003


   REQ PC-18:  It MUST be possible multiple clients to manipulate a
      resource list without knowing of each other's actions. This
      implies that it MUST be possible for the server to notify each
      client of the changes if the client has indicated the need for the
      change notifications.

   REQ PC-19:  Manipulations of the resource list MUST exhibit the ACID
      property; that is, they MUST be atomic, be consistent, durable,
      and operate independently.

   REQ PC-20:  It SHOULD be possible for the client to batch multiple
      operations (add a presentity, remove a presentity) into a single
      request that is processed atomically.

   REQ PC-21:  It MUST be possible for the server to authenticate the
      client.

   REQ PC-22:  It SHOULD be possible to use the same database of client
      credentials used with SIP and SIMPLE, with the data manipulation
      protocol.

   REQ PC-23:  It MUST be possible for the client to authenticate the
      server.

   REQ PC-24:  It MUST be possible for message integrity to be insured
      between the client and the server.

   REQ PC-25:  It MUST be possible for confidentiality to be ensured
      between the client and server. As a motivating example, an
      eavesdropper on the protocol could ascertain the set of people in
      my resource list, resulting in divulging private information.

   REQ PC-26:  It MUST be possible for the protocol to operate through
      an intermediary, such as a proxy, to allow easier firewall
      traversal.


6. Authorization Policy Manipulation

   The following are the set of requirements for the protocol between
   the client and the server for the purposes of manipulating presence
   authorization policy. The requirements are divided between acceptance
   policy, notification policy, and content policy. It is obvious that
   these requirements would apply to other SIP event packages than
   presence as well, but those are outside the scope of this document.

6.1 Acceptance Policy Requirements




Rosenberg & Isomaki    Expires December 26, 2003                [Page 8]


Internet-Draft       Data Manipulation Requirements            June 2003


   REQ AP-1:  It MUST be possible for the acceptance policy to support
      rejection of the subscription if the watcher is present on a
      specified list of 'blocked watchers'. When a list is checked in
      this fashion, it is referred to as a blocked list.

   REQ AP-2:  It MUST be possible for the acceptance policy to support
      rejection of the subscription if the watcher is not present on a
      specified list of 'allowed watchers'.

   REQ AP-3:  It MUST be possible for the acceptance policy to support
      making a subscription pending if the watcher is present on neither
      an explicit allowed or blocked list. In that case, the watcher
      info package [5] can be used for reactive authorization.

   REQ AP-4:  It MUST be possible for the acceptance policy to check
      multiple blocked and allowed lists.

   REQ AP-5:  It SHOULD be possible for the policy to be based on the
      means by which the authenticated identity of the watcher was
      determined (digest vs. S/MIME, for example).

   REQ AP-6:  It SHOULD be possible for the policy to be based on
      whether notifications can be sent encrypted to the subscriber.

   REQ AP-7:  It MUST be possible for authorized users to create, read,
      modify and delete lists that are checked by the authorization
      policy (e.g., the allowed and blocked lists).

   REQ AP-8:  It MUST be possible for authorized users to read, add,
      remove and modify entries of the lists.

   REQ AP-9:  It MUST be possible for the lists to contain entries with
      wildcards, e.g., allow everyone in a certain domain.


6.2 Notification Requirements

   REQ N-1:  It SHOULD be possible for the user to specify that
      notifications are to be sent only when the value of a particular
      status type changes.

   REQ N-2:  It SHOULD be possible for the user to specify that the
      notifications are to be sent only when a particular status type
      changes to a specified value or set of values.

   REQ N-3:  It SHOULD be possible for the user to specify that the
      notifications are to be sent only when a particular status type
      changes from a specified value to a specified value (e.g., from



Rosenberg & Isomaki    Expires December 26, 2003                [Page 9]


Internet-Draft       Data Manipulation Requirements            June 2003


      open to closed).

   REQ N-4:  It SHOULD be possible for the user to specify that the
      notifications are to be sent only when the value of the contact
      address changes.

   REQ N-5:  It SHOULD be possible for the user to specify that the
      notifications are not, or should be sent on changes in the state
      of the subscription (as opposed to the state of the presentity).


6.3 Content Requirements

   REQ C-1:  The user MUST be able to specify that the notification
      should only contain information for particular tuples. It SHOULD
      be possible to use any presence attribute within a tuple as
      criteria for this selection.

   REQ C-2:  It MUST be possible for the user to specify that the
      notification should or should not contain a contact address.

   REQ C-3:  It MUST be possible for the user to specify that the
      notification should contain only specific status types (such as
      basic).

   REQ C-4:  The user MUST be able to specify the specific values of a
      specific status type that the notification should or should not
      contain. Values not permitted must result in the omission of that
      status type. If all status is omitted, the tuple must be omitted
      as well. As an example, a user can specify that the notification
      should include tuples with OPEN status, but suppress those with
      only CLOSED status.

   REQ C-5:  It MUST be possible for the user to specify different
      values of the semantically identical presence information, such as
      status attribute, to different watchers. It MUST be possible for
      the user to give different level of detail of information to
      different watchers.

      The assumption is that the presentity also publishes the different
      values separately (e.g. in separate tuples), so that the
      authorization rules can simply select which (level of) information
      to give to each watcher.

   REQ C-6:  It SHOULD be possible for the user to specify the specific
      presence document to send to a watcher.





Rosenberg & Isomaki    Expires December 26, 2003               [Page 10]


Internet-Draft       Data Manipulation Requirements            June 2003


   REQ C-7:  It SHOULD be possible for the user to specify that the
      notifications should be encrypted using S/MIME.

   REQ C-8:  It SHOULD be possible for the user to specify that a
      particular tuple be added, removed or modified based on the value
      of another tuple. As an example, a user might want to include
      their IM tuple when their phone is busy, but not include it when
      the phone is not busy.


6.4 General Requirements

   These requirements apply to all of the three components of the
   authorization policy.


   REQ G-1:  It MUST be possible for a client to store a cached copy of
      the policies. It MUST be possible for the client to manipulate the
      local cached copy even when there is no connectivity to the
      server. It MUST be possible to synchronize the cached copy with
      the master copy on the server, when connectivity is
      re-established.

   REQ G-2:  It MUST be possible for multiple clients to manipulate the
      same policies without knowing of each others' actions. This
      implies that it MUST be possible for the server to notify each
      client of the changes if the client has indicated the need for the
      change notifications.

   REQ G-3:  Manipulations of the data MUST exhibit the ACID property;
      that is, they MUST be atomic, be consistent, durable, and operate
      independently.

   REQ G-4:  It MUST be possible to ensure that the authorization
      policies are always consistent as a whole when transitioning from
      one policy state to another. To enable this, it MUST be possible
      for the client to batch multiple operations (remove a user from
      one list, add the same user to another list) into a single request
      that is processed atomically, or to otherwise ensure that the
      policies are never left in an inconsistent state.

   REQ G-5:  It MUST be possible for the server to authenticate the
      client.

   REQ G-6:  It SHOULD be possible to use the same database of client
      credentials used with SIP and SIMPLE, with the data manipulation
      protocol.




Rosenberg & Isomaki    Expires December 26, 2003               [Page 11]


Internet-Draft       Data Manipulation Requirements            June 2003


   REQ G-7:  It MUST be possible for the client to authenticate the
      server.

   REQ G-8:  It MUST be possible for message integrity to be ensured
      between the client and the server.

   REQ G-9:  It MUST be possible for confidentiality to be ensured
      between the client and server. As a motivating example, an
      eavesdropper on the protocol could ascertain the set of people in
      my allowed list, resulting in divulging private information.

   REQ G-10:  It MUST be possible to extend the authorization policies
      with new types of rules.

   REQ G-11:  It MUST be possible for a client to discover the types of
      authorization policies the server can handle.


7. Security Considerations

   There are many security considerations associated with the protocol
   whose requirements are defined here.

   The protocol is used to manipulate data that has a significant impact
   on the operation of a service provided to a user. In particular, if
   an attacker manipulates the data, the attacker can:

   o  convey information to subscribers that the presentity wishes to
      keep private;

   o  launch denial of service attacks by flooding a subscriber with
      more presence information than they expected;

   o  deny service to subscribers or to presentities.

   To prevent these attacks, the protocol has to ensure than only
   authorized users can manipulate the data. Requirements for
   authentication and authorization are defined above.

   Information conveyed in the protocol represents sensitive data. It
   can include the content of resource lists and lists of blocked users,
   both of which reveal personal preferences of a user that they do not
   wish to convey. As a result, it is necessary that the client
   authenticate the server, to be sure it is passing this information to
   a trusted entity. It is also necessary for the protocol to provide
   encryption services, so that eavesdroppers cannot inspect the data as
   it passes by.




Rosenberg & Isomaki    Expires December 26, 2003               [Page 12]


Internet-Draft       Data Manipulation Requirements            June 2003


8. Acknowledgements

   The authors would like to thank Paul Kyzivat, Ben Campbell, Krisztian
   Kiss and Eva Leppanen for their input.

9. Changes from version 02

   o  Conventions chapter added.

   o  To-Do list removed.

   o  Presentity collection renamed resource list.

   o  Ordering of requirements 'rationalized'.

   o  References updated.

   o  Defined the scope to be explicitly limited to only resource list
      and presence authorization policy requirements.

   o  Several requirements modified based on SIMPLE WG last call
      comments by Ben Campbell and Krisztian Kiss.

Informative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Day, M., "A model for presence and instant messaging", RFC 2778,
        February 2000.

   [3]  Rosenberg, J., "Session Initiation Protocol (SIP) Extensions for
        Presence",  draft-ietf-simple-presence-10.txt, January 2003.

   [4]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [5]  Rosenberg, J., "A Watcher Information Event Template-Package for
        the Session Initiation Protocol (SIP)",
        draft-ietf-simple-winfo-package-05.txt, January 2003.

   [6]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
        Notification Extension for Resource Lists",
        draft-ietf-simple-event-list-03.txt, May 2003.

   [7]  Peterson, J., "Common profile for presence (CPP)",
        draft-ietf-impp-pres-03.txt, May 2003.




Rosenberg & Isomaki    Expires December 26, 2003               [Page 13]


Internet-Draft       Data Manipulation Requirements            June 2003


Authors' Addresses

   Jonathan Rosenberg
   Dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   USA

   Phone:
   EMail: jdrosen@dynamicsoft.com


   Markus Isomaki
   Nokia Research Center
   Itamerenkatu 11-13
   00180 Helsinki
   Finland

   Phone:
   EMail: markus.isomaki@nokia.com






























Rosenberg & Isomaki    Expires December 26, 2003               [Page 14]


Internet-Draft       Data Manipulation Requirements            June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Rosenberg & Isomaki    Expires December 26, 2003               [Page 15]


Internet-Draft       Data Manipulation Requirements            June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Rosenberg & Isomaki    Expires December 26, 2003               [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/