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

Versions: 00 01

SIMPLE                                                  A. Roychowdhury
Internet Draft                                    Hughes Systique Corp.
Intended status: Informational                             July 18, 2007
Expires January 18, 2008


                  Motivation for feed for Presence State
                    draft-roy-simple-presencerss-01.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   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 January 18, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Web feeds (hereby referred to as 'feed') have always played an
   important role in providing users content related updates of Websites
   without having to visit those websites manually. Typical examples of
   feed usage include users 'subscribing' to the feed of a website
   (example, CNN.com) and thereby automatically receiving 'news
   headlines' when the content changes. Recently, there have been



Roychowdhury           Expires January 18, 2008                [Page 1]


Internet-Draft      Motivation for feed for Presence State



   significant innovations (example [13][12]) where feeds from different
   sources have been combined to produce new services in a 'Web Based
   Service Creation Environment' model allowing users to create
   interesting services building on top of 'primitives' that can be
   represented on the Web.

   This document describes the motivation for a feed for Presence
   information, which the authors believe would be useful to create new
   services using a similar environment described above.

   NOTE 1:  Architecturally, it is also possible that the reverse
   situation, i.e. feed converted to a Presence state is also useful,
   typically for services that could be triggered at the Presentity
   based on certain conditions. However, this document focuses on the
   former, i.e. Presence state to feed.

   NOTE 2: It is not necessary that each PUA support the capability of
   generating feeds. It is possible that a central aggregation server
   generates the required feed on behalf of the PUAs.

Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].




















Roychowdhury           Expires January 18, 2008                [Page 2]


Internet-Draft      Motivation for feed for Presence State





Table of Contents


   1. Terminology....................................................4
   2. Introduction to feeds and Web based Mash-ups...................4
   3. Use Cases for Presence State represented as feed...............7
   4. Examples.......................................................8
      4.1. 'Track-it' service........................................8
            4.1.1.1. Assumptions for this service...................10
            4.1.1.2. Creation of the Mash-Up........................10
            4.1.1.3. Example of Trackit Server receiving Presence
            information.............................................11
            4.1.1.4. Example of Trackit Server publishing feed......12
   5. Working Example...............................................13
   6. Security Considerations.......................................13
   7. IANA Considerations...........................................13
   8. Conclusions & Future work.....................................14
   9. Acknowledgments...............................................14
   10. References...................................................15
      10.1. Normative...............................................15
      10.2. Informative.............................................15
   Author's Addresses...............................................16
   Intellectual Property Statement..................................16
   Disclaimer of Validity...........................................17






















Roychowdhury           Expires January 18, 2008                [Page 3]


Internet-Draft      Motivation for feed for Presence State




1. Terminology

   o  The following terminology has been used in the document:

   o  For the scope of this document the term 'Web' refers to an
      environment where the 'Server' is any entity which is accessible
      on the Internet that can communicate with the User Agent using
      standards such as URIs, HTTP, HTML, XML and similar. 'User Agent'
      is any entity capable of rendering the information provided by the
      server (for example, a Browser)

   o  The term 'feed' describes syndicated feed and includes feed format
      as specified by both RSS([9]) and ATOM([10]). In future, the
      'feed' format could also be extended to other formats including
      [11]

   o  The terms 'feature provider', 'provider', 'service provider' refer
      to any individual user or entity that is/are capable of hosting
      the mentioned feature or service



2. Introduction to feeds and Web based Mash-ups

   This section may be useful to readers not familiar with Web based
   Mash-ups in general. Readers well versed with this may directly skip
   to the next section.

   Simply put, a 'feed' is a data format which describes content of any
   data source. Content distributors syndicate a web feed, thereby
   allowing users to subscribe to the feed (source:[15]). There are two
   commonly used feed formats as specified in. When this document refers
   to the term 'feed' it implies feed in either format.

   The fundamental concept behind a 'Mash-up' is to be able to create a
   set of primitives and make it available on the Web in a way that
   those primitives could be used by any third party developer to extend
   and build upon the provided functionality. In concept, this is
   similar to creating a set of 'C (or any other programming language)-
   based libraries' and offering APIs on top of those libraries to
   others to create new functionality, but has significant differences:

   o  A 'Web' based Mash-up re-uses well known protocols for accessing
      sources (example HTTP, REST)



Roychowdhury           Expires January 18, 2008                [Page 4]


Internet-Draft      Motivation for feed for Presence State



   o  A 'Web' based Mash-up re-uses well known formats for accessing
      data contained within sources (example JSON [11], XML [6], RSS
      [9])

   o  A 'Web' based Mash-up may have multiple hosting environments. In
      other words, if feature provider 'B' were build a new application
      on top of a feature provided by 'A', B would only access content
      from A using well known Web Standards and would not need to host
      A's content in its own domain. Similarly, A does not need to
      access any more data in B's domain beyond what is needed to make
      the service work.

   o  A 'Web' based Mash-up leverages the vast content that is already
      accessible across the Internet in a well defined manner and does
      not require duplication or local availability of data in different
      domains

   o  As a derivative difference, a 'Web' bashed Mash-up is therefore
      accessible by any common browser and does not need special
      libraries or downloads beyond what the browser already supports.

   As an example of how services can be created rapidly using the Web
      Model:

   o  Consider an example, where a subscriber using a 'triple play'
      service  (one that offers Voice, TV and Data over a single IP
      pipe) is listening to a radio stream of their favorite song. The
      provider wants to be able to tap into this by showing a list of
      locations where the artist of that song may be performing in the
      coming months as well as show a preview video of the song he is
      listening to (in the  hope that the subscriber might purchase one
      of these offerings). Such as combined solution can be easily
      provided leveraging the Web and the Internet:

       o Let us assume the radio service itself publishes the currently
          playing information (such as Artist, Title, etc.)

       o The provider can fetch the name of the artist and provide it as
          an input to common ticketing sites (like TicketMaster) which
          in turn returns the list of locations where this group is
          performing

       o  At the same time, the provider can fetch the name of the radio
          song & title and feed it to a video service, which generates a
          response feed with the URI of the preview video which is then
          displayed as a small window on the subscriber's display


Roychowdhury           Expires January 18, 2008                [Page 5]


Internet-Draft      Motivation for feed for Presence State



       o The provider also taps into e-commerce sites with the same
          input parameters and receives a feed response on links to 'Buy
          it now' for the subscriber to place an order for this album

The above example describes rapid creation of a combined service where
the provider is re-using already existing data sources & technologies in
a standard way to create this value addition. Creating such services is
not just theory today. Consider for example, solutions like [12]and [13]
that provide such environments for regular users to create such
combinations.

Note that the above is possible only if the output of each component is
understood by other components. Feed formats as defined [9] and [10] are
dialects of XML and are a popularly supported content syndication format
and is therefore a common 'data formats' that are often used to exchange
information between different modules hosted by different providers.
Feeds therefore, provide easy to understand "tags" under which
information is classified and can be extracted by standard XML parsers.
In addition, feed formats allow for easy implementation of 'Filters' as
services are combined (For example, 'Show me all movies from Youtube
that do not have rating=Mature' may translate to parsing the feed and
deleting feed entries that have a <rating> tag of Mature)

In each of these examples, the following important characteristics
emerge:

   o  Adopting a 'Web based' approach to create incremental services
      (referred to as 'Mash-Ups') significantly reduces service creation
      time (since the interfaces are well known and do not require a
      steep learning curve)

   o  Adopting a 'Web based Mash-up' approach significantly reduces the
      infrastructure and technology requirement from a single provider



   Thus, this model works well when:

   o  The effectiveness of what can be achieved is directly related to
      the nature of data and access each domain is willing to expose to
      build upon.

   o  The feed based model of constructing combined services is a simple
      chain of output of one module serving as an input to another and
      does not provide complex flow control logic



Roychowdhury           Expires January 18, 2008                [Page 6]


Internet-Draft      Motivation for feed for Presence State





   This therefore leads us to why we believe exposing certain SIP
      related data in such a standard format would benefit more value
      added service creation.



3. Use Cases for Presence State represented as feed.

   In all the use-cases below, publishing the information in feed format
   enables third party developers to create new combined services
   without requiring any other specialized tools or protocols beyond
   free Mash-up editors [12][13] that already exist today.

   Use-Case-1: Consider a user Bob, who subscribes to an ad-supported
   live traffic service that provides him with up to date traffic
   information for one of his selected highway routes on I-270N. This is
   provided to him as a feed to see a live traffic map update. However,
   it would be useful if the traffic service could ask for Bob's current
   Presence state and provide information accordingly. For example, if
   Bob's <activities> element shows a value of 'in-transit', then the
   provider can choose to filter out or reduce the sidebar ads so that
   it is simpler for Bob to convert the feed to speech using free tools
   available such as [14]

   o  Use-Case-2: Consider another example where user Alice is in a
      community chat room, and has her mood (via the <mood> element) set
      to <hungry> with a child element <note> set to "would love a
      burger". The Chat provider can create a sidebar customized service
      by putting the following elements together:

       o Get the Presence feed from Alice's UA and parse the hungry
          element

       o Assuming Alice's presence feed also publishes location,
          retrieve current location

       o Pass on the note text and the location to Yahoo Local Maps and
          obtain a list of burger places and display that feed on the
          sidebar

       o (One could continue to combine more attributes to make this
          more specific)




Roychowdhury           Expires January 18, 2008                [Page 7]


Internet-Draft      Motivation for feed for Presence State



   o  Use-Case-3: 'Trackit' is a presence publishing system that allows
   different Presentities to update their presence state periodically.
   Presentities that publish their state also specify access rules which
   govern who can read this presence data (example "all", "none", or
   explicit list of identities, domains etc.). Bob is a subscriber to
   'Trackit' and decides to offer a 'Map & Track' service on top of
   Trackit like so:

       o users, who publish their state in Trackit create ad-hoc groups
          of friends, co-workers and publish an additional attribute in
          their presence information, such as <mnt:mapandtrack-
          group>AlumniMeet</mnt:mapandtrack-group>

       o Members of the group called AlumniMeet can now log into a
          specific webpage provided by Bob which provides a movable map
          with 'presence markers' of where each user currently is and
          what they are doing (subject to what each presentity agrees to
          publish).

       o Bob creates the above page by accessing the feed provided by
          Trackit for the group members, extracts the location and
          activities elements, passes the location information to an
          appropriate mapping service and then overlays the map with
          placepoint information showing their presence status.

       o  Now, if the users are all supposed to meet at 6PM for the
          alumni meeting at Palo Alto, the co-ordinator knows where
          everyone is, how long they would take to arrive and other
          information.

4. Examples

   This section provides examples on how some of the services described
   in Section 3.

   The author has chosen to use Google Mash-up Editor (GME) [13] as a
   platform for demonstrating how some of the use cases can be
   implemented. The same examples Readers can translate these examples
   to other Mash-up environments based on feeds.

4.1. 'Track-it' service

   In this example, we describe how the 'Track-it' service can be
   implemented as a Mash-up based on GME. The overall architecture
   depicts all the entities participating in this service:



Roychowdhury           Expires January 18, 2008                [Page 8]


Internet-Draft      Motivation for feed for Presence State



    ....................................................................
    .    +---+  +---+      +---+                         domain A      .
    .    |   |  |   |......|   +--------------------+                  .
    .    |   |  |   |      |   |                    |                  .
    .    +---+  +---+      +---+                    |                  .
    .     PUA1   PUA2       PUAn                    |                  .
    ....................................................................
            \     |        //                       |
           SIP   SIP    SIP                         |HTTP
              \   |    //                           |(management
    ..........................................      |/list creation
    .           \ |//              domain B  .      |etc.)
    .       +---------+                      .      |
    .       |         |                      .      |
    .       |         |                      .      |
    .       | Trackit |                      .      |
    .       |         |                      .      |
    .       |         |                      .      |
    .       |         |                      .      |
    .       +---------+                      .      |
    .       Presence                         .      |
    .       Aggregation                      .      |
    .       server                           .      |
    ..........................................      |
                |                                   |
         .............................................................
         .      |                                   |       domain C .
         .      |         +---------------+   +-----+--------+       .
         .      |         |               |   |              |       .
         .      |         |               |   |              |       .
         .      +---------+               |   | Map&Track    |       .
         .       HTTP     | Map & Track   |   |  WebServer   |       .
         .         (Feed) |   App Server  |   |              |       .
         .                |               |   |              |       .
         .        +-------+               |   |              |       .
         .        |       +----------+----+   +-----+--------+       .
         .        |                  |              |                .
         .        |HTTP              +--------------+                .
         .        |(Map Data)        RPC/Api                         .
         .............................................................
         .............................................................
         .        |                                     domain D     .
         .     +--+------------+                                     .
         .     |               |                                     .
         .     |  Maps         |                                     .
         .     |  Server       |                                     .


Roychowdhury           Expires January 18, 2008                [Page 9]


Internet-Draft      Motivation for feed for Presence State



         .     +-----+---------+                                     .
         ............|................................................
         ............|. . . . . .....................................
         .       +---+----------+                     domain E      .
         .       |              |                                   .
         .       | Map Data     |                                   .
         .       |              |                                   .
         .       +--------------+                                   .
         ............................................................


   We will focus on the data exchange and call flow for "domain C" which
   is the domain where the Mash-up is being implemented.

4.1.1.1. Assumptions for this service

   PUAs alice@example1.com, bob@example2.com, joe@example3.com are
   subscribers who participate in publishing their presence state to the
   Trackit server. The presence document published by the PUAs are
   compliant to the document format specified in [2][3][4]. The PUAs are
   further assumed to have capability to publish location information
   compliant to the GEOPRIV location object format specified in [7](The
   location information may be provided to the PUAs via an installed GPS
   chip, or by  network assisted GPS etc.)

   It is further assumed Bob, Alice and Joe have already registered with
   the Map&Track web-server and have created a group called
   'AlumniParty' for which they would like to track their location and
   presence. Furthermore, all the above mentioned UAs have a local
   client capable of receving the image slices overlayed with presence
   information that Map&Track creates.

4.1.1.2. Creation of the Mash-Up

   The template for the Mash-UP in GME can be as follows:

   (Readers are encouraged to refer to documentation of [13] for
   complete details. However, for the sake of completeness, a brief
   description is provided below each code segment.



   <div style="float:left;width="50%">





Roychowdhury           Expires January 18, 2008               [Page 10]


Internet-Draft      Motivation for feed for Presence State



     <gm:list id="PresenceFeed"
   data="http://www.mapandtrack.com/group0aE952.xml"
   pagesize="25"/></div>

   Explanation: The above lines create a list which will be populated
   with the presence feed from Alice, Bob and Joe. The URL
   http://www.mapandtrack.com/group0aE952.xml represents a URL generated
   by MapandTrack when the users created their Alumni Group, and will
   contain the aggregated presence documents from each PUA.



   <div style="float:left;width="50%">

   <gm:map id="PresenceFeedMapMarkers" data="${PresenceFeed}"
   latref="geo:lat" lngref="geo:long">

       <gm:handleEvent src="PresenceFeed"/>

     </gm:map></div>

   Explanation: The above lines create an association between the map
   object and the PresenceFeed xml list shown earlier. Specifically, the
   handleEvent tag creates an association where the map object 'listens'
   to the PresenceFeed list. When the user clicks on an item in the
   PresenceFeed list (an item could be the presence state of one of the
   users), the Lattitude (geo:lat) and Longitude (geo:long) is extracted
   and sent to the map object as input.

4.1.1.3. Example of Trackit Server receiving Presence information

   Alice's PUA publishes the following Presence document (only relevant
   excerpts shown)to the Trackit server possibly by a SIP NOTIFY message

   <status>

      <gp:geopriv>

         <gp:location-info>

           <gml:location>

             <gml:Point gml:id="point1" srsName="epsg:4326">

               <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>



Roychowdhury           Expires January 18, 2008               [Page 11]


Internet-Draft      Motivation for feed for Presence State



             </gml:Point>

            </gml:location>

         </gp:location-info>

         <gp:usage-rules>

           <gp:retransmission-allowed>no</gp:retransmission-allowed>

           <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-
   expiry>

         </gp:usage-rules>

       </gp:geopriv>

         <basic>open</basic>

      </status>

   This in turn could be translated to the following feed generated by
   the Trackit



4.1.1.4. Example of Trackit Server publishing feed

   This section is illustrative only. The exact mapping between the
   presence document and the feed format may be addressed in a future
   Internet Draft.

   After Alice's PUA updates Trackit with a recent presence information,
   the TrackitServer could expose the following format when Map&Track
   server (the third party Mash-up) requests the Presence feed using the
   URI specified (in this case
   http://www.mapandtrack.com/group0aE952.xml)

      (only relevant portions of feed shown)

      <?xml version="1.0" encoding="UTF-8"?>

      <rss version="2.0" xmlns:presrss="http://www.example.com/rsspres"
   xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" >

      <channel>


Roychowdhury           Expires January 18, 2008               [Page 12]


Internet-Draft      Motivation for feed for Presence State



      <title> Presence Feed for AlumniParty </title>

      <item>

      <rsspres:id-name>Alice</rsspres:id-name>

      <rsspres:id-uri> sip:alice@example1.com </rsspres:id-uri>

      <rsspres:presence>online</rsspres:presence>

      <geo:long>-123.618334</geo:long>

      <geo:lat>41.12505189</geo:lat>

      </item>

   </channel>

   </rss>



5. Working Example

   As a working example of a proof-of-concept Mash-up development using
   these concepts, readers are encouraged to visit [16]



6. Security Considerations

   Security conditions that apply to publishing of Presence Information
   as specified in [2][3][4] also apply here. In addition, a Web based
   Mash-up model involves interaction of data from multiple,
   disconnected domains. By only enabling HTTP GET to retrieve a feed
   across domains reduces the potential attacks, but it is critical for
   the domains participating in a mash-up service to secure their data
   appropriately.

   Furthermore, it is assumed that all presence authorization rules are
   applied to the Presence Information before they are published as a
   feed.

7. IANA Considerations

   None identified


Roychowdhury           Expires January 18, 2008               [Page 13]


Internet-Draft      Motivation for feed for Presence State



8. Conclusions & Future work

   This draft describes the motivation for providing Presence related
   data as a feed. The primary advantage that has been described is that
   this allows third party developers to rapidly & incrementally create
   new services using standard web-tools.

   As further work, it may be possible that non-presence related SIP
   data is also identified as potentially useful in created services
   chained by feeds.

   A possible next step is to work on a specification that describes a
   feed format for Presence tags that could be adhered to by
   Presentities wanting to publish such attributes.

9. Acknowledgments

   Thanks to Henry Sinnreich, Eric Burger for providing detailed review
   comments on the initial version of this draft. Walter Goix's comments
   are appreciated.




























Roychowdhury           Expires January 18, 2008               [Page 14]


Internet-Draft      Motivation for feed for Presence State





10. References

10.1. Normative

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

   [2]   Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006

   [3]   Schulzrinne, H., "CIPID:Contact information for the Presence
         Information Data Format", RFC 4482, July 2006

   [4]   Schulzrinne,H., Gurbani,V., Kyzviat,P., Rosenberg,J. "RPID:Rich
         Presence Extensions to the Presence Information Data Format
         (PIDF)", RFC 4480, July 2006

   [5]   Fielding,R., Taylor,R. "Principled design of the modern Web
         architecture", ACM Transactions on Internet Technology (TOIT),
         Volume 2, Issue 2 (May 2002), ACM Press, ISSN:1533-5399

   [6]   Bray,T., Paoli,J., Sperberg-McQueen,C.M., Maler,E., Yergeau,F.,
         "Extensible Markup Language (XML) 1.0 (Fourth Edition)",
         September 2006

   [7]   Peterson, T., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005

   [8]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002



10.2. Informative

   [9]   RSS Advisory Board, "RSS 2.0 Specification",
         http://www.rssboard.org/rss-specification

   [10]  Nottingham,N., Sayre,R. "The Atom Syndication Format", RFC
         4287, December 2005

   [11]  Javascript Object Notation (JSON), http://www.json.org/

   [12]  Yahoo Pipes, http://pipes.yahoo.com


Roychowdhury           Expires January 18, 2008               [Page 15]


Internet-Draft      Motivation for feed for Presence State



   [13]  Google Mash-up Editor, http://code.google.com/gme/index.html

   [14]  RSS to Speech Gadget,
         http://desktop.google.com/plugins/i/rsstospeech.html

   [15]  Definition of Web Feed, http://en.wikipedia.org/wiki/Web_feed

   [16]  Prototype of Mapit-N-trackit,
         http://rsspresence.googlemashups.com/



Author's Addresses

   Arjun Roychowdhury
   Hughes Systique Corp.
   15245 Shady Grove Rd, Suite 330
   Rockville MD 20850
   USA

   Email: arjun@hsc.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Roychowdhury           Expires January 18, 2008               [Page 16]


Internet-Draft      Motivation for feed for Presence State



Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

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


























Roychowdhury           Expires January 18, 2008               [Page 17]


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