Krisztian Kiss 
  Internet-Draft                                             Gabor Bajko 
  Network Working Group                                            Nokia 
  Expires: April 25, 2003                               October 25, 2002                                            
                              
                                                     


      
      
      Requirements for Presence Service based on 3GPP specifications and 
                     wireless environment characteristics 
               draft-kiss-simple-presence-wireless-reqs-01.txt 



   
   
      
      
  Status of this Memo 
      
     This document is an Internet-Draft and is in full conformance with 
     all provisions of Section 10 of RFC2026 [1]. 
      
     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. 
      
     The distribution of this memo is unlimited. 

   
  Copyright Notice

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

      
  Abstract 
      
     This Internet-Draft defines requirements for Presence Service based 
     on 3GPP specifications and wireless environment characteristics. 

                                                             


Internet-Draft          Expires: April 25, 2002                    Page 1 
  
Krisztian Kiss          3GPP Presence Requirements           October 2002 
    
    
  Table of contents 
   
     1.   Introduction.................................................3 
     2.   Conventions used in this document............................3 
     3.   General wireless requirements................................3 
     4.   Publishing requirements......................................4 
     4.1  Standardized mechanism to publish presence information.......4 
     4.2  Requirements to support multiple PUAs........................4
     4.3  Feedback on publishing.......................................4     
     4.4  Publishing efficiency........................................5 
     5.   Subscription and notification requirements...................5 
     5.1  Filtering....................................................5 
     5.2  Anonymous subscription.......................................5 
     5.3  Notification efficiency......................................6
     5.4  Content indirection..........................................6 
     6.   Requirements for the content of the Presence Document........6
     6.1  Presence information elements................................6 
     6.2  Multivalue concept...........................................7    
     6.3  Location information.........................................7 
     7.   Authorization requirements...................................7 
     7.1  Standardized setting of authorization policy.................7 
     7.2  Expressiveness of authorization rules........................7 
     8.   Watcher information requirements.............................8 
     8.1  Pending watcher notification.................................8
     8.2  Watcher information filtering................................8 
     8.3  Watcher history..............................................8 
     9.   Presencelist requirements....................................9
     10.  Security requirements........................................9
     11.  Evaluation against the SIMPLE charter items..................9 
     11.1 Publishing and Subscription/Notification requirements........9 
     11.2 Presence Document requirements...............................9 
     11.3 Authorization and Management requirements....................9 
     11.4 Watcher information requirements............................10 
     12.  Proposed next steps.........................................10 
          Normative References...łł...................................10      ł
          Informative References......................................11
          Author's addresses..........................................12
     A.   Acknowledgements............................................12 
          Full Copyright Statement....................................13   




  
                                                                         












Internet-Draft          Expires: April 25, 2002                   Page 2 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

   
   1. Introduction 
   
     This Internet-Draft defines requirements for Presence Service based 
     on 3GPP specifications [23][24] and other needs rising from 
     mobile/wireless environment characteristics. The requirements on the 
     Session Initiation Protocol (SIP) for the Release 5 of the 3GPP IP 
     Multimedia Subsystem are described in [19]. Presence Service is 
     referenced as defined in IMPP Working Group in documents [5] and 
     [6].  
     
     This document does not document requirements that have led to the 
     creation and work in progress on a number of SIMPLE WG specifications, 
     i.e. subscriptions and notifications of user presence [7], the SIP 
     presencelist event package [9], the SIP Event Template-Package for 
     Watcher Information documents [11][12], the content indirection 
     mechanism [17] and the SIMPLE Presence Publication Mechanism [15][16]. 
     Rather this document lists only requirements that are additional to 
     those that have led to the mechanisms proposed in these documents. 
     
     The document also assumes the usage of the Common Presence and 
     Instant Messaging (CPIM) Presence Information Data Format (PIDF) 
     defined in [8] as the default presence document data format, 
     however some of the requirements presented here might require 
     extensions to PIDF.  
      
     The requirements presented in this document are proposed to be 
     evaluated by the SIMPLE Working Group. The result of this evaluation 
     process would help to determine the work expected to be done in IETF 
     and identify the work which might be done in other standardization 
     bodies, such as 3GPP. Thus, a more precise work-share between 
     standardization bodies could be worked out. The overall goal of 
     these requirements is to allow the development of a fully 
     standardized presence application for wireless terminals, utilizing 
     existing IETF and 3GPP specifications.   
  

  2. Conventions used in this document 
      
     This document does not specify any protocol of any kind. Therefore, 
     the use of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
     "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
     "OPTIONAL" in this document, as described in RFC 2119 [2], does not 
     apply. 
      
        
                                                                         










Internet-Draft          Expires: April 25, 2002                   Page 3 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

  
  3. General wireless requirements 
      
     The radio interface is a scarce resource. As such, the number and 
     size of the messages exchanged over the radio interface between the 
     UA and the network should be minimized. All the mechanisms developed 
     should make an efficient use of the radio interface. 
      
     As terminals could be rather small devices, memory requirements, 
     power consumption, processing power, etc. should be kept to a 
     minimum. Mandating support for additional protocols and mechanisms 
     in the terminal must meet this condition.     

 
  4. Publishing requirements 
  
  4.1 Standardized mechanism to publish presence information   
  
     There must be a standardized mechanism to manage (publish) the 
     presence information. The standardized publication mechanism must 
     allow publishing from multiple Presence User Agents (PUAs) of a 
     single presentity. It must be possible for the PUAs of the same 
     presentity to add elements to the presence information as well 
     as remove or modify existing elements of the presence information. 

  4.2 Requirements to support multiple PUAs

     The Presence Server must be able to merge the information from 
     multiple sources and resolve possible conflicts in the resulting 
     presence document. 

     It must be possible for the PUA to discover the current content 
     and status of the presence document including presence information 
     published by other PUAs belonging to the same presentity. 
     Requirements in section 3 must be also taken into account When 
     fulfiling this requirement.

     The PUA must be able to manipulate already existing elements of the 
     presence information published by another PUAs.

  4.3 Feedback on publishing

     The PUA must be able to receive feedback about the result of a 
     publishing transaction, the feedback must contain enough 
     information for the principal controlling the presentity to know 
     that the published presence information was successfully composed 
     into the presence document by the Presence Server.
                                                                                









Internet-Draft          Expires: April 25, 2002                   Page 4 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

   
  4.4 Publishing efficiency 

     It must be possible for the presentity to publish multimedia 
     contents along with their communication means when publishing 
     presence information. The mechanism selected for publishing large 
     size content must make efficient use of the network resources and 
     satisfy related requirements in section 3. 
      
     One identified mechanism to fulfil this requirement is to allow the 
     PUA to update only those parts of the presence information that have 
     changed since the last publication. 
     For example if only some elements of the presence information 
     changes, then only those elements need to be updated as opposed to 
     always sending all the presence information elements within each 
     publish transaction. 
         
      
  5. Subscription and notification requirements 
      
  5.1 Filtering 
      
     It must be possible for a watcher to select certain elements from 
     the presence information that he wants (or does not want) to receive  
     in notifications for.  

     EXAMPLE: the watcher may only want to be notified when the 
     presentity becomes available for conferencing. 
      
     The Presence Server must be able to construct the presence document 
     to be delivered to the watcher according to the watcher's 
     filtering preferences. 
     NOTE: When determining the elements to be included in the presence 
     document, authorization rules are also needed to be taken into 
     account. 

     It must be possible for the Presence List Server [9] to construct 
     and store appropriate filtering rules for every URI in the 
     presencelist based on the watcher's filtering preferences.

     [14] describes more detailed filtering requirements.
   
  5.2 Anonymous subscription 
      
     It must be possible for the watcher to request an anonymous 
     subscription (i.e. the watcher's identifier will not be revealed 
     to the presentity).  
      
     This anonymous request may be accepted or rejected, depending on the 
     presentity's authorization rules as described in clause 7.  
      
     NOTE: This requirement may be met with the overall privacy solution 
     for SIP.       
  
                                                                       


Internet-Draft          Expires: April 25, 2002                   Page 5 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 
   

  5.3 Notification efficiency

     It must be possible for the watcher to determine what presence 
     information is available for a particular presentity before 
     fetching or subscribing to the presence information elements with 
     actual values.

     It must be possible for the watcher to receive notification of  
     multimedia contents along with the presentityĆs communication means. 
     The mechanism selected for notifying large size content must make 
     efficient use of the network resources and satisfy related 
     requirements in section 3.

     One identified mechanism to fulfil this requirement is to allow the 
     Presence Server to generate partial notifications to the watcher 
     containing only those elements of the presence information, which 
     have changed value compared to the previous notification to the 
     watcher. 
     NOTE: When using this mechanism the watcher must be able to indicate 
     its support for partial notification when subscribing to the 
     presentity's presence information.            
     
  5.4 Content indirection 
      
     Requirements for content indirection are described in [13]. In 
     connection to presence the following requirements have been 
     identified: 
      
     The Presence Server should be able to perform content indirection. 
     Watchers should have the capability to indicate the support of 
     content indirection. The Presence Server must honor watcher's 
     preferences whether to perform content indirection or not when it 
     detects a situation where content indirection should be performed. 
      
      
  6. Requirements for the content of the presence document         
      
  6.1 Presence information elements 
      
     The presence document must contain presence information elements. 
     Each presence information element must contain a unique identity 
     which makes the presence information element distinguishable from 
     other presence information elements inside the presence document.

     RFC 2778 [6] defines the presence information element to consist
     of a STATUS marker, an optional COMMUNICATION ADDRESS, and optional 
     OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS includes a 
     COMMUNICATION MEANS and a CONTACT ADDRESS. 
     As a further requirement for this definition, it must be possible 
     to define semantics to the content of an element (e.g. for the 
     communication means: voice, video, instant messaging, application).
     The presence document must be able to contain multiple types of 
     presence information elements. As an example, a presence information
     element could be user specific, device specific or network specific.
                                                                             

Internet-Draft          Expires: April 25, 2002                   Page 6 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

   
  6.2 Multivalue concept

     It must be possible to include multiple instances of the semantically 
     same presence information in the presence document. The different 
     instances should contain different values of the same presence 
     information and used to be shown for different watchers. The 
     different watchers must only receive those instances of the 
     presence information they are authorized to by the presentity.
      
     EXAMPLE: One group of watchers is shown a different value for the 
     status of presentity than the other. 

     The Presence Server must be able to distinguish whether two presence 
     information elements contain semantically different presence 
     information or they are different instances of the semantically same 
     presence information.
  
  6.3 Geographic location information 
      
     There must be a standardized mechanism to express geographic location 
     information within the presence document. 

          
  7. Authorization requirements 
      
     This chapter defines the requirements for how presentity is able to 
     authorize the presence subscriptions. 

  7.1 Standardized setting of authorization policy 
      
     There must be a standardized mechanism for the presentity (Presence 
     User Agent) to control the authorization policy related to his own 
     presence information. 
      
     This means that the authorization policy document format and a set 
     of manipulation operations upon that format must be standardized. 
     Such manipulation operations should be aligned with the ones used 
     for other similar purposes (such as conferencing). 
      
     It should be possible for network operators to extend the format of 
     the authorization policy document and the operations upon that 
     format based on local policy. 
   
  7.2 Expressiveness of authorization rules 
      
     It must be possible for the presentity to set separate authorization 
     rules for different watchers and groups of watchers. With these rules 
     the presentity must be able to override the default behaviour of the 
     presence server for the generation of notifications and content of 
     the notifications.
                
     EXAMPLE: Only watchers belonging to a particular group are 
     allowed to receive information related to presentity's location.    
                                                                          


Internet-Draft          Expires: April 25, 2002                   Page 7 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 
   

     
     It must be possible for the presentity to manage the authorization 
     rules from multiple sources (e.g. from different terminals of the 
     presentity or by the service provider on behalf of the presentity.)
     It must be possible for the presentity from one source to learn the 
     changes in the authorization rules changed by other sources belonging 
     to the same presentity.      
      
     It must be possible for the presentity to grant access rights 
     separately for all elements of the presence information. 
      
     RFC 2778 [6] defines a model for presence information. Based on this 
     model more specific requirements can be stated:
     It must be possible for the Presence Server to decide based on 
     authorization rules whether to include a certain tuple in the 
     notification. It must be possible to base that decision on any 
     element in the tuple. In the default case these must include at least 
     TUPLE ID, CONTACT ADDRESS, COMMUNICATION MEANS and STATUS attributes. 
     As a special case, it must be possible for the Presence Server to 
     provide different status values for same COMMUNICATION ADDRESS or 
     combination of COMMUNICATION ADDRESS and OTHER PRESENCE MARKUPs.

     It must be possible to grant access rights with an expiry time to a 
     particular watcher or group. 
      
     As groups are seen as an important concept in the authorization 
     policy definition, the solution should be aligned with the 
     operations used for similar purposes (such as conferencing).  


  8. Watcher information requirements 
      
  8.1 Pending watcher notification

     It must be possible for a presentity to be informed of a pending 
     watcher subscription from a currently unauthorized and/or unknown
     watcher.
  
  8.2 Watcher information filtering 

     It should be possible for the presentity to monitor the watcher 
     status of certain watchers.  
      
     NOTE: This requirement may be fulfilled if the watcher information 
     subpackage defined in [11] could be extended with filtering 
     mechanisms. 
      
  8.3 Watcher history 
      
     It must be possible for the presentity to fetch the list of the 
     watchers who have accessed (by subscription or fetch) his 
     presence information during a well-defined time-period (e.g. last 7 
     days). 

      
                                                                                
Internet-Draft          Expires: April 25, 2002                   Page 8 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

   
      
     Additionally to the list of watchers, the details of the presence 
     information provided to different watchers should be available 
     for the presentity when fetching the watcher history. 


  9. Presencelist requirements

     Requirements for creating a presencelist, adding new URIs to an 
     existing presencelist, modifying or removing existing URIs from an 
     existing presencelist, or deleting a presencelist are described 
     in [10].


  10. Security requirements

     Security requirements assume requirements that have led to existing 
     security mechanism described in [18]. Further security requirements 
     over and above this have not yet been identified.
      
      
  11. Evaluation against the SIMPLE charter items 
   
     SIMPLE Working Group charter may contain solution space for some of 
     the requirements presented in this document. This chapter will 
     present a proposal how these requirements could be mapped into 
     SIMPLE Working Group work items. 

  11.1 Publishing and Subscription/Notification requirements   

     The most appropriate place to implement all publishing and 
     subscription/notification related requirements is the SIMPLE Working 
     Group, as SIP based presence extensions have been specified in this 
     Working Group. At the moment there is no appropriate work item for 
     these requirements.   
      
  11.2 Presence Document requirements 
   
     New SIMPLE charter has a work item for SIMPLE PIDF profile. Scope of 
     this work item could be defined to include presence document 
     requirements presented in this document. 

  11.3 Authorization and Management requirements 
   
     New SIMPLE charter has a work item for user's presencelist management 
     and authorization operations. This work item could be used to define 
     generic approach how user's presence service related information 
     could be managed and how to implement authorization requirements 
     presented in this document.  
      
                                                                          





Internet-Draft          Expires: April 25, 2002                   Page 9 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 
   
      
  11.4 Watcher information requirements 
   
     Watcher information format and event-template has been specified in 
     SIMPLE Working Group. It would be beneficial if this group's 
     expertise could be utilized to generate required extensions to 
     support watcher information filtering and history information.  
   
   
  12. Proposed next steps 
      
     It is proposed that SIMPLE Working Group should evaluate these 
     requirements. The requirements for which a consensus is found within 
     the Working Group should be incorporated into the presence 
     requirements Working Group draft. It is also expected for the 
     Working Group to point out any requirements that fall out of its 
     scope, so that other standardization bodies, such as 3GPP are able 
     to start working on those without the risk of overlapping work. The 
     results of such work can be brought back to IETF as Informational 
     documents. 
      
      
Normative References 

     1. S. Bradner, "The Internet Standards Process -- Revision 3", BCP 
       9, RFC 2026, October 1996. 
      
     2. S. Bradner, "Key words for use in RFCs to Indicate Requirement 
       Levels", BCP 14, RFC 2119, March 1997.    

     3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 
       Peterson, R. Sparks, M. Handley, E. Schooler: "SIP, Session 
       Initiation Protocol", RFC 3261, June 2002
      
     4. A. Roach, "ession Initiation Protocol (SIP)-Specific Event
       Notification", RFC 3265, June 2002 
   
     5. M. Day, S. Aggarwal, G. Mohr, J. Vincent "Instant Messaging / 
       Presence Protocol Requirements", RFC 2779 
   
     6. M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 
       Instant Messaging", RFC 2778 
   
     7. J. Rosenberg et al., "SIP Extensions for Presence", draft-ietf-
       simple-presence-07.txt, May 2002, work in progress 
                                                                         
     8. H. Sugano, S. Fujimoto, G. Klyne, A. Bateman: "CPIM Presence 
       Information Data Format", draft-ietf-impp-cpim-pidf-05.txt, May 
       2002, work in progress 
   
     9. J. Rosenberg, B. Campbell, "SIP Event Package for List Presence", 
      draft-ietf-simple-presencelist-package-00.txt, June 2002, work in 
      progress 




Internet-Draft          Expires: April 25, 2002                  Page 10 
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 

      
      
     10. J. Rosenberg, M. Isomaki, "Requirements for Manipulation of 
       Data Elements in SIMPLE Systems", 
       draft-ietf-simple-data-req-00.txt, October 2002, work in progress 

     11. J. Rosenberg, "A Session Initiation Protocol (SIP) Event 
       Template-Package for Watcher Information", draft-ietf-simple-
       winfo-package-02.txt, May 2002, work in progress 
      
     12. J. Rosenberg, "An Extensible Markup Language (XML) Based Format 
       for Watcher Information", draft-ietf-simple-winfo-format-02.txt, 
       May 2002, work in progress 
   
     13. S. Olson, "Requirements for Content Indirection in SIP 
       Messages", draft-ietf-sipping-content-indirect-02.txt, September 
       2002, work in progress     

     14. T. Moran, S. Addagatla, "Requirements for Event Notification 
       Filters", draft-moran-sipping-filter-reqs-00.txt, October 2002,
       work in progress

     15. B. Campbell, S. Olson, J. Peterson, J. Rosenberg, B. Stucker, 
       "SIMPLE Presence Publication Mechanism", 
        draft-olson-simple-publish-00, June 2002, work in progress  

     16. A. Niemi, "SIP Specific Data Publication Framework", 
        draft-niemi-simple-publish-framework-00, September2002, work in 
        progress
     
     17. S. Olson, "A Mechanism for Content Indirection in SIP Messages",
       draft-olson-sip-content-indirect-mech-01, August 2002, work in
       progress

     18. J. Arkko, V. Torvinen, G. Camarillo, T. Haukka, S. Sen, "Security 
       Mechanism Agreement for SIP Sessions", 
       draft-ietf-sip-sec-agree-04.txt, June 2002, work in progress

     19. M. Garcia-Martin, "3rd-Generation Partnership Project (3GPP) 
       Release 5 requirements on the Session Initiation Protocol (SIP),
       draft-ietf-sipping-3gpp-r5-requirements-00.txt, October 2002, work
       in progress


Informative References

     20. 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release 
       5", Version 5.6.0 available at 
       ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/ 
      
     21. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call 
       control based on SIP and SDP", Version 5.2.0 available at 
       ftp://ftp.3gpp.org/specs/archive/24_series/24.228/ 




Internet-Draft          Expires: April 25, 2002                  Page 11
  
Krisztian Kiss          3GPP Presence Requirements          October 2002 


       
     22. 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP 
       and SDP, stage 3", Version 5.2.0 available at 
       ftp://ftp.3gpp.org/specs/archive/24_series/24.229/ 
       
     23. 3GPP TS 22.141: "Presence Service, Stage 1", Version 5.2.0 
       available at ftp://ftp.3gpp.org/specs/archive/22_series/22.141/ 
      
     24. 3GPP TS 23.141: "Presence Service, Architecture and Functional 
       Description, Stage 2", Version 0.2.1 available at 
       ftp://ftp.3gpp.org/specs/archive/23_series/23.141/ 

  
Authors' addresses

      
     Krisztian Kiss 
     Nokia 
     P.O. Box 100 
     FIN-33721 Tampere, Finland 
     Tel: +358 50 4835363 
     e-mail: krisztian.kiss@nokia.com 

      
     Gabor Bajko 
     Nokia 
     HU-1092 Budapest, Koztelek 6 
     Hungary 
     Tel: +36 20 9849259 
     e-mail: gabor.bajko@nokia.com 


Appendix A. Acknowledgements
      
     The authors would like to thank the following people for their interest, 
     support and efforts when writing this Internet-Draft:
      
          Markus Isomaki (Nokia), Mikko Lonnfors (Nokia), Juha Kalliokulju 
          (Nokia), Eva-Maria Leppanen (Nokia), Georg Mayer (Siemens), 
          Mark Beckmann (Siemens), Sonia Garapaty (Nortel), Jayshree 
          Bharatia (Nortel), Keith Drage (Lucent), Andrew Allen 
          (DynamicSoft), Kevan Hobbis (H3G), Harmand Alexandre (mmO2), Duncan 
          Mills (Vodafone), Miguel A. Garcia (Ericsson), Milo Orsic (Lucent). 

     Although not an official communication of the 3GPP, this document has
     been discussed and commented by a number of delegates in the relevant
     3GPP working groups.



          




Internet-Draft          Expires: April 25, 2002                  Page 12
  
Krisztian Kiss          3GPP Presence Requirements          October 2002


      
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 assigns.

   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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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






















Internet-Draft          Expires: April 25, 2002                  Page 13