W3C home > Mailing lists > Public > uri@w3.org > June 2003

temporal URI fragments

From: <Silvia.Pfeiffer@csiro.au>
Date: Sat, 07 Jun 2003 23:46:02 +1000
To: uri@w3.org
Message-ID: <3EE1EC9A.7090609@csiro.au>
Dear all,

I need to pick up the issue of temporal URI fragments again. Attached is 
another revision that addresses some of the previously stated issues. 
Now that we have sorted through all the other open issues, it is high 
time to resume the discussion on the one issue of temporal URI fragments 
that does not conform with the current URI standard specification. I 
would like to get this issue added to the issues list and sorted out 
before declaring the revision finished.

I am still hopeful that we can come to a future-proof expert agreement 
on how to standardise uniform addressing of temporal and named offsets 
into time-continuous data through URIs. It will have large implications 
on the usefulness of the Web for digital online radio & TV stations as 
well for the Web access of large volume (and I'm talking about terabytes 
of data) archives.


Let me explain the issue in a sequence of statements:

1.) There is a need to standardise a specification for temporal URIs:

- I have received comments from many different standards bodies (SMPTE, 
MPEG, Pro-MPEG) that supported this temporal addressing scheme

- in MPEG-21, several different ways of specifying temporal references 
into resources are being proposed, such as #media_time(17:30) or 
#01:00:00:00; our suggestion is another one

- all temporal Web resources share a need to identify temporal offsets 
and users should not have to learn and get confused by many different 
ways of specifying them in URIs when we can prescribe one standard way 
of doing so.


2.) Direct addressing of named highlights in time-continuous resources 
(such as audio & video) as fragment identifiers is desirable:

- time-continuous media on the Web is non-attractive because it is 
awkward and inefficient to use - one main reason being its inherent 
inaccessability: bits of interest cannot be addressed directly

- just as it is useful and sensible for html resources to be able to 
address named anchors (i.e. named objects or offsets) through fragments, 
it is also useful and sensible for time-continuous resources to be able 
to address named objects through fragments.

- many file formats of time-continuous data already have a way of 
specifying special objects/highlights by names (e.g. QuickTime chapters, 
WindowsMedia markers)

- direct access to named highlights through use of the name in fragments 
is desirable


3.) There is a requirement for time-continuous resources to perform the 
retrieval action of subparts of media server-side:

- time-continuous media has large volumes; just a 1 hour video will 
require 25 GB in DV format

- a user who requests a interval of or a time offset into such a 
resource should not need to have to be made to wait while data that he 
has not requested is getting delivered


4.) The problem of using fragments for addressing offsets into 
time-continuous resources:

- fragment identifiers are a natural and the prefered way of 
specification of temporal and named URI references by at least MPEG-21 
and ourselves because fragments imply that the original resource is 
bascially unchanged and that only a subpart is referenced (as said in 
the new I-D: "identifying information that is selective within that 
resource")

- forcing URI fragments into time-continuous resources to be interpreted 
client-side makes them nearly useless (see 3 above)

- the proposal to use the query ("?") component instead of the fragment 
identifier for the specification of temporal URI references may be a 
solution for temporal URIs, but fails for named fragments and fails to 
address the point. If fragments are useful for anything more than 
small-size resources (such as html and pdf), then addressing of subparts 
of resources also needs to result in resources that represent that subpart.

- while the current URI standard says that "fragment identifiers have a 
special role in information systems as the primary form of client-side 
indirect referencing", this is a prescription that is not technically 
necessary and only mirrors current use (as in html or pdf). Without 
limiting this current use, we can easily add the possibility to perform 
referencing on the server where needed.


==

The simple summary to my rant is that people will build systems that use 
temporal URI fragment identifiers into time-continuous media no matter 
whether we support it or not. And they will not want to be restricted by 
having to perform the offset action client-side. RTP/RTSP already offer 
a way around this problem by specifying the temporal offset or interval 
in a protocol parameter. If a temporal URI fragment is used over RTSP, 
the effect will be that the user agent strips off the fragment and puts 
it into that protocol parameter and then retrieves for its user the 
subpart of the resource that was requested. This effectively contradicts 
the prescription of the current version of the URI standard of having to 
perform the offset action on the client side.

We currently have the chance to foresee this usage and allow it under 
controlled conditions. I firmly believe that the alternative is that we 
will get back to another revision of this standard a few years down the 
track where we will have to incorporate this change under more 
uncontrolled conditions with many non-interoperable implementations 
around. Therefore, let's resolve it now.


My proposal to resolve this problem is based on the fact that the 
"retrieved representation" of the resource on which the fragment offset 
gets performed is the same on the client as the one that is available at 
the server's side just before sending it off. I'd therefore like to 
argue that we could as well allow the application of the fragment offset 
on the server side as the very final step, in cases where this is more 
appropriate to the MIME type and the user's requirements.


Best Regards,

Silvia Pfeiffer.





Network Working Group                                        S. Pfeiffer
Internet-Draft                                                 C. Parker
Expires: December 6, 2003                                          CSIRO
                                                            June 7, 2003


             Syntax of temporal URI fragment specifications
                  draft-pfeiffer-temporal-fragments-01

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 6, 2003.

Copyright Notice

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

Abstract

   This document specifies a syntax for temporal offsets and intervals
   as URI fragments.  Such fragment identifiers are useful to directly
   access temporal offset points and intervals in time-continuous
   resources such as audio and video.  The URI fragment syntax specified
   in this document is comformant to the Generic URI Syntax as specified
   in RFC 2396 [2].

   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].




Pfeiffer & Parker       Expires December 6, 2003                [Page 1]

Internet-Draft           Temporal URI Fragments                June 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Temporal fragment specification  . . . . . . . . . . . . . . .  4
   3.  Time schemes . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Intended usage . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Disucssion points to be resolved . . . . . . . . . . . . . . . 10
   6.1 Interpretation of temporal fragments on server . . . . . . . . 10
   7.  ChangeLog  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14





































Pfeiffer & Parker       Expires December 6, 2003                [Page 2]

Internet-Draft           Temporal URI Fragments                June 2003


1. Introduction

   Many resources on the Internet are time-continuous data such as audio
   or video files or streams.  This document describes a standard way of
   addressing temporal offsets into and temporal intervals of such
   resources through a temporal URI fragment syntax.  In this way,
   points of interest and intervals in time-continuous files or streams
   can be directly accessed.  The aim is to make it simple to
   incorporate infrastructure into the Web which supports the browsing
   and searching of time-continuous media.  The interpretation of the
   temporal fragment is however dependent on the URI scheme in use and
   the content type of the resource referenced.







































Pfeiffer & Parker       Expires December 6, 2003                [Page 3]

Internet-Draft           Temporal URI Fragments                June 2003


2. Temporal fragment specification

   Fragments are generally specified in a URI after the crosshatch ("#")
   character.  The format of fragment identifiers specified in this
   document is conformant to the URI RFC 2396 [2] for fragment
   identifiers, but retricts their use to an interpretation on the user
   agent only.  See section 5 for a proposed alternative usage.

   Temporal fragments start with the reserved character "@",
   representing the time-continuous resource "at" a certain temporal
   offset.  The "@" character is reserved and this specification is
   giving it a reserved purpose.  Having the "@" character at the start
   simplifies parsing of a temporal fragment specification, helping to
   e.g.  distinguish between a fragment given by name as "#smpte-25" and
   a fragment given as a temporal offset as "#@smpte-25=01:01:01:01".

   The specification of a temporal fragment offset itself is given as a
   name-value pair, where the name specifies a time scheme to use and
   the value is the time specification itself.  The syntax is closely
   related to the specification of relative timestamps of the RTSP
   protocol parameters as given in RFC 2326 [3].

   Temporal intervals can be specified as well.  This is achieved by
   adding the reserved character "-" and another time specification that
   adheres to the time scheme used for the specification of the first
   time point.

   The BNF for temporal fragment offsets and temporal intervals is:

   temporal-fragment = "@" [ timescheme "=" ] timespec ["-" timespec]

   timescheme     = *unreserved

   timespec       = *uric

   There are several time schemes that can be used.  The default time
   scheme is "npt" (normal play time).  The available time schemes and
   their specifications are described in the next section.













Pfeiffer & Parker       Expires December 6, 2003                [Page 4]

Internet-Draft           Temporal URI Fragments                June 2003


3. Time schemes

   A time scheme is a short identifier for a type of time specification.
   The following general time schemes are specified in this document.
   Further time schemes are expected to emerge and should probably be
   registered through IANA (XXX this needs to be discussed XXX).

   o  "npt" (Normal Play Time; base of seconds as used in the RTSTP
      standard [3])

   o  "smpte" (Society of Motion Picture and Television Engineers time
      codes as specified in the SMPTE time and control code standard
      [4])

   o  "utc" (Universal Time Code giving wall-clock time as specified in
      the ISO 8601 standard [5]).

   Thus, the available time schemes are:

      NPT time has a second or subsecond resolution.  It is specified as
      H:M:S.h (npt-hhmmss) or S.h (npt-sec), where H=hours, M=minutes,
      S=second and h=fractions of a second.  Negative values are not
      allowed.

      Specification as BNF:

   npt-spec    =  "npt=" npt-time
   npt-time    =  npt-sec | npt-hhmmss
   npt-sec     =   1*DIGIT [ "." *DIGIT ]
   npt-hhmmss  =   npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
   npt-hh      =   1*DIGIT
   npt-mm      =   1*2DIGIT
   npt-ss      =   1*2DIGIT

      SMPTE time codes [4] are optimized for frame level accuracy.
      SMPTE is specified as HH:MM:SS:FF, where HH=hours, MM=minutes,
      SS=second, FF=frames.  The drop-frame algorithms for calculating
      the exact times can be found in the references SMPTE standard.
      Negative values are not allowed.

      "smpte-24=" SMPTE time with a 24 fps basis

      "smpte-24-drop=" SMPTE time with a 24/1.001 fps basis

      "smpte-25=" SMPTE time with a 25 fps basis

      "smpte-30=" SMPTE time with a 30 fps basis




Pfeiffer & Parker       Expires December 6, 2003                [Page 5]

Internet-Draft           Temporal URI Fragments                June 2003


      "smpte-30-drop=" SMPTE time with a 30/1.001 fps basis

      "smpte-50=" SMPTE time with a 50 fps basis

      "smpte-60=" SMPTE time with a 60 fps basis

      "smpte-60-drop=" SMPTE time with a 60/1.001 fps basis

      Specification as BNF:

   smpte-spec  = smpte-type "=" smpte-time
   smpte-type  = "smpte-24" | "smpte-24-drop" | "smpte-25" |
                 "smpte-30" | "smpte-30-drop" | "smpte-50" |
                 "smpte-60" | "smpte-60-drop"
   smpte-time  =  smpte-hh ":" smpte-mm ":" smpte-ss [ ":" *2DIGIT ]
   smpte-hh    = 1*2DIGIT
   smpte-mm    = 1*2DIGIT
   smpte-ss    = 1*2DIGIT

      UTC time has a second or subsecond resolution.  It is given as
      YYYYMMDDTHHmmss.hhZ, where Y=year, M=month, D=day, H=hour,
      m=minute, s=second, h=subseconds (one-hundredth of a second).

      Specification as BNF:

   utc-spec    = "clock=" utc-time
   utc-time    =   utc-date "T" utc-hhmmss "Z"
   utc-date    =   8DIGIT
   utc-hhmmss  =   6DIGIT [ "." *DIGIT ]

   Examples for specifications of temporal fragment offsets are:

   http://www.foo.bar/matrix.au#@smpte-25=10:07:33:06
   http://www.foo.bar/matrix.au#@npt=10:7:33.25
   http://www.foo.bar/matrix.au#@10:7:33.25
   http://www.foo.bar/matrix.au#@npt=36453.25
     (all four specify the same time point)

   rtp://www.foo.bar/matrix.mpg#@clock=20021107T173045.25Z
     (for Thu Jul 11 05:30:45 UTC 2002 and a quarter seconds)

   The semantic interpretation of time specifications given with any of
   the schemes depends on the resource.  With every resource there are
   two associated timebases: a UTC timebase which may e.g.  specify the
   creation time of the resource, and a playback timebase used for
   display in a user agent while viewing the resource.

   The playback timebase of a resource defaults to 0 seconds if the



Pfeiffer & Parker       Expires December 6, 2003                [Page 6]

Internet-Draft           Temporal URI Fragments                June 2003


   resource has no other timebase associated with it.  For example, with
   professional video production, the first frame of video of a program
   normally refers to a SMPTE timebase of 01:00:00:00, not 00:00:00:00.
   This practice arose from the requirements of program production and
   analog videotape recording technology, and it has subsequently become
   a uniform, almost ironclad practice worldwide.  Associating such a
   practice to a digital video resource requires a way to store that
   timebase with the resource, which may or may not be possible,
   depending on the content type of the resource.

   Examples: If a resource has an associated timebase of 3600 seconds,
   and the given temporal fragment offset is 4000 sec, a seek time 400
   sec into the resource is requested.  If the timebase is given as
   clock time 20001010T142211.23Z and the temporal offset specified is
   20001010T145511.23Z, the time 33 minutes into the resource is
   requested.

   The UTC timebase of a resource defaults to non-specified.
   Associating such a UTC timebase with a resource requires a way to
   store that timebase with the resource.  For example, for a resource
   that is a file on a server, it may be chosen to be the time of
   storage of that resource.

   Examples for specifications of temporal intervals are:

   http://www.foo.bar/matrix.au#@smpte-25=10:07:33:05-10:07:37:21
   http://www.foo.bar/matrix.au#@npt=10:7:33.25-10:7:37.8
   http://www.foo.bar/matrix.au#@10:7:33.25-10:7:37.8
   http://www.foo.bar/matrix.au#@npt=36453.25-36457.8
     (all four specify the same temporal interval)

   rtp://www.foo.bar/matrix.mpg#@clock=20021107T173045.25Z-20021107T173049.80Z

   The semantic interpretation of these temporal intervals depends on
   the time scheme.  Unless specified differently, the temporal
   intervals given are closed intervals, i.e.  they start at the first
   time point and finish at the second time point: [time_from;time_to].
   For SMPTE timecodes, however, it is conventional to express such
   temporal intervals as IN and OUT times for editing.  Thus, the IN
   time specifies the first frame that is included in the interval and
   the OUT time specifies the first frame that is not included in the
   interval.  Therefore, a SMPTE interval is specified as
   [time_from;time_to[, which explains the additional frame in the above
   example.







Pfeiffer & Parker       Expires December 6, 2003                [Page 7]

Internet-Draft           Temporal URI Fragments                June 2003


4. Intended usage

   The temporal fragment specification scheme is intended to be used on
   time-continuous resources.  An example of such resources are all
   resources of MIME types "audio/*" and "video/*".  The protocol
   through which these resources are accessed are expected to be mainly
   http or rtp/rtsp, which are especially suited for such resources.

   It is RECOMMENDED that user agents do not strip off the temporal
   fragment from a given URI before forwarding it to a server.  [XXX:
   This is contrary to the current prescription in the URI standard and
   needs to get resolved -> see Section 6.]

   A retrieval action on a URI that includes a temporal fragment SHOULD
   result in a time-continuous resource that starts at the given
   temporal offset.  As time-continuous resources often come with high
   bandwidth requirements, this avoids unnecessary network load.  For
   example, a 1 hour Digital Video (DV format) requires about 25 GB
   (MPEG-2 reduces that to about 3 GB, but this format must be prepared
   for addressing high-quality, high-resolution time-continuous
   bitstreams of the future).  Serving out only the requested interval
   of a resource also significantly reduces the delay for the user agent
   for receiving relevant data.  Alternatively, the user agent MAY wait
   until the retrieval action has failed, then resend the URI with the
   fragment stripped off and perform the offset action locally on the
   retrieved resource.

   Servers that support the temporal fragment offset MUST implement a
   retrieval action of time-continuous resources with such fragment
   specifications by serving the requested resource from the temporal
   offset onwards.  For many time-continuous resources - especially when
   in compressed format - this means that the server has to parse the
   structure of the resource and construct another valid resource from
   the original resource's header information and data frames.  If a
   server cannot perform the fragment offset, it MUST return an error as
   otherwise the user agent cannot identify if the offset action was
   performed or not.

   It is expected that over time more servers and client applications
   understand and handle the temporal fragment offset and thus enable
   direct networked access to content in time-continuous resources.
   Also network proxies may begin to understand such temporal offsets
   and can exploit them for caching.








Pfeiffer & Parker       Expires December 6, 2003                [Page 8]

Internet-Draft           Temporal URI Fragments                June 2003


5. Security considerations

   This specification does not create any new security issues beyond the
   ones already specified for URIs in RFC 2396 [2].















































Pfeiffer & Parker       Expires December 6, 2003                [Page 9]

Internet-Draft           Temporal URI Fragments                June 2003


6. Disucssion points to be resolved

6.1 Interpretation of temporal fragments on server

   In the current version of the URI standard [2], it is prescribed that
   fragment specifications get interpreted by the user agent.
   Therefore, the intended use of fragments to retrieve only a temporal
   interval of the time-continuous data or the data from a certain
   offset point onwards is not generally allowed.  However, there are
   ways to effectively get around this restriction by using (mis-using?)
   communication protocols.

   When using http, we can invent a new protocol parameter that gets
   filled by the user agent with the temporal fragment specification and
   that gets interpreted by the server.  If we don't do that, we
   seriously defect http from being usable for time-continuous media in
   the future.

   When using rtp/rtsp, a client can strip off the fragment
   specification and map it onto the Range header field of the rtsp
   protocol, which will then tell the server which subpart of the
   time-continuous data bistream to serve out.

   A much cleaner way to resolve this problem would be to change the URI
   standard to allow for a server-side interpretation of fragment
   offsets after all other actions have been performed on the resource.
   This will make it independent of the protocol in use and it will
   enable intermediate proxies to store and forward parts of a media
   resource.  It is then the user agent's choice whether or not to strip
   off the fragment offset and interpret it locally after the retrieval
   action or to forward it to the server with an expectation to receive
   only that subpart of the resource.  Servers are not forced to
   implement that specification.  It is however necessary to return an
   error if they cannot handle temporal fragment specifications to avoid
   a double offset action by both server and client.
















Pfeiffer & Parker       Expires December 6, 2003               [Page 10]

Internet-Draft           Temporal URI Fragments                June 2003


7. ChangeLog

   draft-pfeiffer-temporal-fragments-01:

      Extension of the number of available SMPTE time-schemes.  Many
      thanks to Bill Miller and Oliver Morgan of the SMPTE for their
      input on these changes.

      Deleted "start" and "now" as time specification values.

      Extension of the temporal fragment addressing to also address
      temporal intervals, not only time points.

      Added section that includes some key points of discussion where
      the existing URI standard contradicts the use of fragments for
      time-continuous data.



































Pfeiffer & Parker       Expires December 6, 2003               [Page 11]

Internet-Draft           Temporal URI Fragments                June 2003


References

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

   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [3]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [4]  The Society of Motion Picture and Television Engineers, "SMPTE
        STANDARD for Television, Audio and Film - Time and Control
        Code", ANSI 12M-1999, September 1999.

   [5]  ISO, TC154., "Data elements and interchange formats --
        Information interchange -- Representation of dates and times",
        ISO 8601, 2000.


Authors' Addresses

   Silvia Pfeiffer
   Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
   Locked Bag 17
   North Ryde, NSW  2113
   Australia

   Phone: +61 2 9325 3141
   EMail: Silvia.Pfeiffer@csiro.au
   URI:   http://www.cmis.csiro.au/Silvia.Pfeiffer/


   Conrad D. Parker
   Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
   Locked Bag 17
   North Ryde, NSW  2113
   Australia

   Phone: +61 2 9325 3133
   EMail: Conrad.Parker@csiro.au
   URI:   http://www.cmis.csiro.au/Conrad.Parker/









Pfeiffer & Parker       Expires December 6, 2003               [Page 12]

Internet-Draft           Temporal URI Fragments                June 2003


Appendix A. Acknowledgements

   The authors greatly acknowledge the contributions of Andre Pang and
   Andrew Nesbit in developing this syntax.  We also thank the SMPTE for
   their contributions and the URI discussion group at the W3C
   (uri@w3.org) for their many comments on this document.













































Pfeiffer & Parker       Expires December 6, 2003               [Page 13]

Internet-Draft           Temporal URI Fragments                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



Pfeiffer & Parker       Expires December 6, 2003               [Page 14]

Internet-Draft           Temporal URI Fragments                June 2003


   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.











































Pfeiffer & Parker       Expires December 6, 2003               [Page 15]

Received on Saturday, 7 June 2003 09:49:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT