[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
IETF Internet fax WG                                      Graham Klyne
Internet draft                              Integralis Technology Ltd.
                                                            1 May 1998
                                              Expires: 1 November 1998


            Scenarios for Internet fax capability exchange
             <draft-ietf-fax-capability-scenarios-00.txt>

Status of this memo

  This document is an Internet-Draft.  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 made obsolete 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''.

  To view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
  (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
  (US West Coast).

  Copyright (C) 1998, The Internet Society

Abstract

  The simple mode for Internet fax described in [1] relies on
  transmission of documents using a minimum feature set to achieve
  interoperability between sender and receiver.  Proposals for
  extended Internet fax [2,3] aim to provide for transmission of
  enhanced documents (e.g. higher resolutions, colour) by employing
  mechanisms to identify recipient capabilities to the sender, in the
  same fashion as traditional Group 3 fax [4].

  This memo describes some of the scenarios for capability exchange
  in Internet fax, taking account of the particular nature and goals
  of the application [5], with a view to informing the debate over
  what mechanisms should be used for this purpose.











Klyne                                                         [Page 1]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


Table of contents

1. Introduction.............................................2
  1.1 Terminology ..........................................3
  1.2 Structure of this document ...........................3
  1.3 Discussion of this document ..........................3
  1.4 Amendment history ....................................4
  1.5 Unfinished business ..................................4
2. Capability exchange issues in Internet fax...............4
3. Scenarios................................................5
  3.1 User scenarios .......................................6
  3.2 Deployment scenarios .................................7
  3.3 Traditional facsimile scenarios ......................9
     3.3.1 Summary of T.30 DIS frame........................9
     3.3.2 Fax polling......................................9
4. Implementation notes.....................................10
  4.1 Identification of capabilities .......................10
  4.2 Denotation of capabilities ...........................10
  4.3 Mechanisms for capability exchange ...................10
5. Security considerations..................................11
6. Copyright................................................12
7. Acknowledgements.........................................12
8. References...............................................12
9. Author's address.........................................15



1. Introduction

  The simple mode for Internet fax described in [1] relies on
  transmission of documents using a minimum feature set to achieve
  interoperability between sender and receiver.  Proposals for
  extended Internet fax [2,3] aim to provide for transmission of
  enhanced documents (e.g. higher resolutions, colour) by employing
  mechanisms to identify recipient capabilities to the sender.

  Traditional facsimile employs a system of capability
  identification, built in to the underlying facsimile transmission
  protocol [4], so that documents can be transmitted with quality
  greater than is provided by the base format capability common to
  all facsimile machines.

  A number of suggestions have been made [7,9, and others not
  formally published] to provide similar facilities for facsimile
  data transmitted using Internet e-mail.  But, because Internet
  e-mail is quite different to traditional facsimile transmission
  technologies, the mechanisms used must be different.








Klyne                                                         [Page 2]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  This memo describes some of the scenarios for capability exchange
  in Internet fax, taking account of the particular nature and goals
  of the application [5], with a view to informing the debate about
  what mechanisms should be used for this purpose.

1.1 Terminology

  Terminology used in this document that is specific to Internet fax
  is taken from [5].

1.2 Structure of this document

  The main part of this memo addresses the following areas:

  Section 2 discusses some of the technical issues that make
  provision of traditional facsimile capability identification
  somewhat problematic in Internet e-mail, and contrasts the features
  of traditional fax transport mechanisms with Internet e-mail that
  make this so.

  Section 3 describes some scenarios for capability exchange in
  Internet fax, from the viewpoints of system users, deployment and
  traditional facsimile service offerings.

  Section 4 discusses some general concepts that might have a bearing
  on how capability identification might be implemented for Internet
  fax.

1.3 Discussion of this document

  Discussion of this document should take place on the Internet fax
  mailing list hosted by the Internet Mail Consortium (IMC):

  Please send comments regarding this document to:

      ietf-fax@imc.org

  To subscribe to this list, send a message with the body 'subscribe'
  to "ietf-fax-request@imc.org".

  To see what has gone on before you subscribed, please see the
  mailing list archive at:

      http://www.imc.org/ietf-fax/

  To unsubscribe from the ietf-fax mailing list, send a message to
  "ietf-fax-request@imc.org" containing the message 'unsubscribe'.








Klyne                                                         [Page 3]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


1.4 Amendment history

  00a       31-Mar-1998
            Document initially created.

  00b       01-May-1998
            Minor updates based on feedback received.  Update
            references.  Extended security considerations section.

1.5 Unfinished business

  .  Add new scenarios identified by ongoing debate and review.

  .  Complete the T.30 scenarios with input from T.30 experts.


2. Capability exchange issues in Internet fax

  Technical differences between the Internet e-mail SMTP transport
  [11] and the facsimile T.30 transmission protocol [4] that tend to
  dictate different approaches to capability exchange are:

  .  SMTP is a store-and-forward protocol, which means that the sender
     of a message is generally disengaged from the message transfer
     process at the time final delivery is accomplished.  T.30, on the
     other hand, is a session mode protocol in which the transmitter
     of a message is directly involved in the process until final
     delivery is accomplished and signalled back to the sender.

     (There is a proposal to provide a session mode capability in SMTP
     [10], but in its present form even this may be forced to fall
     back to store-and-forward mode in some circumstances.)

     Because SMTP is a store-and-forward protocol, there may be
     arbitrary delays in the transfer of a message

  .  Being a store-and-forward Internet protocol, SMTP can service
     occasionally connected correspondents;  thus there is no
     requirement or expectation for the ultimate recipient to be
     accessible at the time a message is sent.  Traditional facsimile,
     on the other hand, relies on the fact that telephone devices are
     always physically connected to the network and available to
     receive calls (except when they are busy).

     A related consideration is that SMTP senders do not have to be
     concerned with the possibility that the recipient is busy at the
     time a message is sent.  But the next-hop MTA may be unavailable
     for a variety of reasons, so some system of retries is required.







Klyne                                                         [Page 4]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  .  In T.30, the sender of a message connects directly to and
     interacts with the receiver.  Using SMTP, this is not generally
     the case and an indeterminate number of intermediate relays
     (MTAs) may be involved in the transmission process. The
     capabilities of these intermediate systems is not generally known
     or knowable.

  .  T.30 is a binary protocol;  i.e. protocol elements and data are
     represented as arbitrary bit streams.  SMTP on the other hand is
     a text-based protocol, and all protocol elements and data must be
     represented in a stream of US-ASCII text;  this imposes
     restrictions on the way that protocol elements are coded.

     (Similar restrictions also apply to the data in SMTP, but these
     restrictions are generally made transparent through the use of
     MIME transfer encoding of message data.)

  .  In general, there are significant per-message call setup and
     volume-related transmission costs associated with traditional
     facsimile.  When using SMTP, there are generally no per-message
     or volume-related transmission costs.  (This is a simplification,
     and there are exceptions in both cases, but holds widely enough
     to be a good working model.)

  .  Traditional facsimile calls are placed using a dedicated physical
     connection, and while that connection is in use for one message
     transfer it cannot be used for any other purpose.  SMTP message
     transfers can share a physical connection between several
     different activities.

     This has implications for possible concurrent use of multiple
     services or capability acquisition mechanisms.


3. Scenarios

  In this section, scenarios are presented from three different
  perspectives:

  .  User scenarios:  capability identification scenarios based on the
     resulting message transfer behaviour that would be visible to a
     user of the system.

  .  Deployment scenarios:  based on the effect that capability
     identification has on the way that messages flow through the
     network infrastructure.









Klyne                                                         [Page 5]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  .  Traditional facsimile scenarios:  based on capability exchange
     behaviours which have come to be associated with Group 3
     facsimile.  This section examines various commonly-used
     capability identification mechanisms present in T.30 [4] and
     considers their applicability to the Internet e-mail environment.

  In all cases, the goal is to provide interoperability between
  sender and receiver of a message;  i.e. to achieve a message
  transfer which can be processed by the recipient, or to advise the
  sender that a desired transfer is not possible.

3.1 User scenarios

  These scenarios focus on issues of presentation quality, as
  evidenced by media features and a recipient's capability to handle
  them.  Many of the scenarios may extend to non-media capabilities
  (e.g. encryption, language).

  .  Sender wishes to send a simple low-resolution monochrome image,
     per "simple mode" [1].  This should always be sent regardless of
     any capability exchange mechanisms available or employed.

  .  Sender wishes to send a high-resolution monochrome image, but the
     information content would still be useful if sent at a lower
     resolution.  No capability information about the receiving system
     is known or available.  The sender has two options: (a) send the
     image at reduced quality only, or (b) send a multipart/alternate
     containing full quality and reduced quality [12].

  .  Sender wishes to send a high-resolution monochrome image, but the
     information content would still be useful if sent at a lower
     resolution.  Capability information of dubious reliability about
     the receiving system available, suggesting that the recipient can
     handle the full quality.  The sender's options are the same as
     above, but there is greater reason to send both formats.  Sending
     the high-quality image only is probably not a good idea (see
     security considerations).

  .  Sender wishes to send a high-resolution monochrome image.
     Available and trusted capability information indicates that the
     receiving system is known or available to handle this format.
     The image can be sent at full quality only.

  .  Sender has a high quality colour image (e.g. promotional
     literature) which needs to be sent at full quality to be of any
     use.

     In the absence of any capability information, the sender may
     either (a) send the message and hope, or (b) take steps to
     acquire the receiver's capabilities.





Klyne                                                         [Page 6]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


     Having capability information of dubious reliability indicating
     that the recipient can handle the image, the same options are
     available but there is probably greater reason to send the image
     straight away.

     Having capability information of dubious reliability which
     indicates that the recipient cannot handle the image, the sender
     might follow either of the options suggested above, but possibly
     with greater preference for acquiring capabilities before sending
     the message.  Alternatively, he might give up and not send the
     message at all (probably not a good idea).

  .  Sender has an original document in different formats each
     requiring a different set of enhanced recipient capabilities for
     optimum display.  One of the formats would also provide usable
     information to a recipient with minimum capabilities, per [1],
     but the other would provide optimum display for a recipient with
     the required capabilities.  Depending upon available capability
     information the sender has options to send (a) the best format,
     (b) the not-so-good format which will display with minimum
     capabilities, (c) both formats.

  In all the above cases, the sender's choice may be modified by the
  cost of transmitting the message, which in turn will depend upon
  the size of the various possible message formats and the ultimate
  destination.  For example, he may decline to send a multi-Megabyte
  presentation graphic which would incur international offramp
  charges without knowing that the recipient could process that data.

3.2 Deployment scenarios

  This section discusses deployment scenarios, which have a bearing
  on the kind of negotiation or capability identification mechanisms
  that could prove useful.

  .  Corporate mail and Internet fax server with access to corporate
     address book and fax offramp systems.  Such a system might
     conduct authoritative capability identification on behalf of the
     users in its address book, with the idea that messages for users
     that might be delivered by e-mail or fax transmission can be
     handled.

  .  A combination of SMTP session mode and capability identification
     extensions [9, 10] could provide a capability identification
     mechanism that operates via the Internet to provide G3 fax like
     negotiation.

     In this scenario, security concerns about privacy and accuracy of
     information are heightened, and these would need be addressed in
     some way.





Klyne                                                         [Page 7]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  .  Capabilities can be sent with message disposition notification
     (per [7]). Some form of capability information would be available
     after a message had been sent to a given destination, but might
     become stale if messages are sent infrequently to that recipient.

     This has associated security concerns.  Addressing the security
     concerns discussed in [7] will go some way to addressing these.

  .  Capabilities can be sent with outgoing messages (e.g. per
     [13,14]), to be used in any return message.  These, too, can
     become stale.  Also, for communication between send-only and
     receive-only systems, the capability information is of little use
     (unless the receiving system can lodge it in some common area for
     use by related sending systems).

  .  Capabilities might be cached on an MTA server which is close to
     the recipient of a message and which can be made readily and
     immediately available to sending parties.  (Information held
     closer to the receiving system is likely to be more reliable than
     more remote information.)

  .  Multiple copies (multipart/alternate) could be sent to an
     intervening MTA, which could then conduct negotiation on the
     sender's behalf to select the best version to deliver.

  .  Format-converting gateways might be used to accept a variety of
     formats which the receiver does not recognize.  Declared receiver
     capabilities would also include conversion capabilities of the
     gateway.  This may introduce secondary security concerns if
     message integrity/authentication mechanisms are being employed.

  .  Capability identification can be used for Internet-to-Internet,
     Internet-to-GSTN (via an offramp gateway) and GSTN-to-Internet
     (via an onramp gateway).  In the onramp/offramp cases, capability
     information would relate to the gateway's ability to accept data
     and pass it on in a form usable by the ultimate addressee, rather
     than necessarily indicating the addressee's capabilities.

  .  Hunt groups:  a given recipient address (phine number, etc.) may
     connect to any of several receiving systems in a "hunt group".
     If different systems in the group have different capabilities, a
     possibility exists for capability identification information from
     one exchange to cause a sending system to send unusable data in a
     subsequent message transmission.











Klyne                                                         [Page 8]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


3.3 Traditional facsimile scenarios

3.3.1 Summary of T.30 DIS frame

  The following paraphrases an analysis of bits in the T.30 DIS frame
  with a view to their relevance to capability identification, which
  was posted to the IETF-FAX discussion list:

  .  The DIS bits up to about bit 45 are mainly concerned with
     resolution, compression, width and size capabilities etc.  Things
     like transmission speed and scan line time capabilities are not
     relevant in a store and forward environment, but would be dealt
     with by the off-ramp transmitter.

     Special image characteristics of the receiver cannot be so dealt
     with and are best known in advance via negotiations.

     Thus, DIS 1-45 are covered by [20], or are irrelevant to Internet
     fax capability identification.

  .  Bits 47-64 deal with polling, sub-addressing, password, non-image
     data (including BFT) and alternative negotiation methods.

     Polling is discussed in a separate section below.

     Sub-addressing can be handled by conversion to the format
     described in [16,17] at the onramp and offramp gateways.

     Non-image transfer is logically handled by MIME encapsulation
     [18,12], though there are some issues about mapping Object Ids
     (used by the Group 3 fax binary file envelope T.434 [19]

     Security presents some real problems because of the impossibility
     of passing a secured message through a gateway (which by the
     nature of T.30 and SMTP must convert the data content in some
     way) without possessing the relevant security keys.

  [[Identify T.30 capability/negotiation options in greater detail,
  and relevance to Internet fax operations]]

3.3.2 Fax polling

  Polling raises the following issues:

  (a) identifying whether or not polling is available (or, strictly
      following the Group 3 facsimile model, to determine if data is
      available to be polled),

  (b) content selection for polled data, and






Klyne                                                         [Page 9]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  (c) whether or not polling is required and appropriate in the
      context of Internet fax (given the alternate methods
      available), and the mechanisms appropriate for performing
      polling.

  It has been noted that although polling is commonly performed with
  Group 3 facsimile, it is often used for special applications and
  performed using special purpose features rather than the standard
  T.30 facilities for this purpose.


4. Implementation notes

  To define a deployable system for capability exchange in Internet
  fax, the following issues must be addressed:

4.1 Identification of capabilities

  The specific capabilities which can be exchanged must be identified
  (or at least, some initial set).

  The Group 3 facsimile protocol, T.30 [4], defines a number of such
  capabilities, identified by bits in the DIS frame and in other
  protocol frames.

  A number of features related to media type and capability are
  identified in [20]. This document has, by design, a high degree of
  overlap with media features identified by T.30.

  It may be desirable to also provide some higher-level
  identification of capabilities, such as general support for
  Internet fax.

4.2 Denotation of capabilities

  A way to represent capabilities carried within the SMTP protocol
  must be defined.  The limitations of SMTP suggest that a textual
  format should be used (as opposed to the binary formats used for
  T.30).

4.3 Mechanisms for capability exchange

  Mechanisms for capability exchange (i.e. carrying capability
  information between correspondents) fall into two broad categories:

  .  Connected, using some form of direct client/server enquiry
     protocol (e.g. LDAP [15], T.30 frames [4], SMTP capabilities
     [9]).







Klyne                                                        [Page 10]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


  .  Disconnected, carried by SMTP as message data (e.g. MDN
     extensions [7], vCard with message [13,14]).

  This does not address the ever-present possibility of using any
  kind of out-of-band mechanism to supply information about a
  recipient to the sending agent (e.g. user input).


5. Security considerations

  The following are primary security concerns for capability exchange
  mechanisms:

  .  Unintentional disclosure of private information through the
     announcement of capabilities or user preferences.

  .  Disruption to system operation caused by accidental or malicious
     provision of incorrect capability information.

  .  Use of a capability identification mechanism might be used to
     probe a network (e.g. by identifying specific hosts used, and
     exploiting their known weaknesses).

  Security considerations relevant to Internet fax are discussed
  further in [1,5].

  The most contentious security concerns are raised by mechanisms
  which automatically send capability identification data in response
  to a query from some unknown system.  Use of directory services
  (based on LDAP [15], etc.) seem to be less problematic because
  proper authentication mechanisms are available.

  Mechanisms which provide capability information when sending a
  message are less contentious, presumably because some intention on
  the part of the person whose details are disclosed to communicfate
  with the recipient of those details can be inferred.  This does
  not, however, address spoofed supply of incorrect capability
  information.

  The use of format converting gateways may prove probelmatic because
  such systems would tend to defeat any message integraty and
  authenticity checking mechanisms that are employed.













Klyne                                                        [Page 11]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


6. Copyright

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


7. Acknowledgements

  The ideas in this document came from a meeting with particular
  contributions from James Rafferty, Larry Masinter, Richard Shockey.

  Further ideas have been taken from postings to the IETF-FAX mailing
  list.


8. References

[1]  "A Simple Mode of Facsimile Using Internet Mail"
     K. Toyoda,
     H. Ohno
     J. Murai, WIDE Project
     D. Wing, Cisco
     RFC 2305
     March 1998








Klyne                                                        [Page 12]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


[2]  "Extended Facsimile Using Internet Mail"
     Larry Masinter, Xerox Corporation
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-fax-eifax-00.txt>
     Work in progress, March 1998

[3]  "Procedures for the Transfer of Facsimile Data via Internet Mail"
     D. Crocker, Internet Mail Consortium
     Internet draft: <draft-ietf-fax-itudc-00.txt>
     Work in progress, October 1997

[4]  ITU Recommendation T.30:
     "Procedures for document facsimile transmission in the General
     Switched Telephone Network"
     International Telecommunications Union, 1996

[5]  "Terminology and Goals for Internet Fax"
     Larry Masinter, Xerox Corporation
     Internet draft: <draft-ietf-fax-goals-02.txt>
     Work in progress, March 1998

[6]  "Extensions to Delivery Status Notifications for Fax"
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-fax-dsn-extensions-00.txt>
     Work in progress, November 1997.

[7]  "Using Message Disposition Notifications to Indicate Supported
     Features"
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-fax-mdn-features-01.txt>
     Work in progress, March 1998

[8]  "Operational Guidelines for Fax over SMTP"
     Larry Masinter, Xerox Corporation
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-fax-operation-00.txt>
     Work in progress, March 1998

[9]  "SMTP Service Extension for Capabilities Exchange"
     Dan Wing,
     Neil Joffe, Cisco Systems
     Internet draft: <draft-ietf-fax-smtp-capabilities-00.txt>
     Work in progress, November 1997

[10] "SMTP Service Extension for Immediate Delivery"
     Dan Wing,
     Neil Joffe, Cisco Systems
     Larry Masinter, Xerox Corporation
     Internet draft: <draft-ietf-fax-smtp-session-02.txt>
     Work in progress, February 1998





Klyne                                                        [Page 13]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


[11] RFC 821, "Simple Mail Transfer Protocol"
     J. Postel, Information Sciences Institute, University of Southern
     California
     August 1982.

[12] RFC 2046, "Multipurpose Internet Mail Extensions (MIME)
     Part 2: Media types"
     N. Freed, Innosoft
     N. Borenstein, First Virtual
     November 1996.

[13] vCard - The Electronic Business Card Version 2.1
     Internet Mail Consortium
     URL: <http://www.imc.org/pdi/vcard-21.txt>
     September 1996.

[14] vCard MIME Directory Profile
     Frank Dawson, Lotus Development Corporation
     Tim Howes, Netscape Communications
     Internet draft <draft-ietf-asid-mime-vcard-06.txt>
     Work in progress: April 1998.

[15] RFC 2251, "Lightweight Directory Access Protocol (v3)"
     M. Wahl, Critical Angle Inc.
     T. Howes, Netscape Communications Corp.
     S. Kille, Isode Limited
     December 1997.

[16] RFC 2303, "Minimal PSTN address format in Internet Mail"
     C. Allocchio, GARR-Italy
     March 1998.

[17] RFC 2304, "Minimal FAX address format in Internet Mail"
     C. Allocchio, GARR-Italy
     March 1998.

[18] RFC 2045, "Multipurpose Internet Mail Extensions (MIME)
     Part 1: Format of Internet message bodies"
     N. Freed, Innosoft
     N. Borenstein, First Virtual
     November 1996.

[19] ITU-T Recommendation T.434,
     "Binary file transfer format for the telematic services"
     International Telecommunications Union
     July 1996









Klyne                                                        [Page 14]


Internet draft                                              1 May 1998
Scenarios for Internet fax capability exchange


[20] "Media Features for Display, Print, and Fax"
     Larry Masinter, Xerox Corporation
     Koen Holtman, TUE
     Andy Mutz, Hewlett Packard
     Dan Wing, Cisco Systems
     Internet draft: <draft-ietf-conneg-media-features-00.txt>
     Work in progress, March 1998


9. Author's address

  Graham Klyne
  Content Technologies Ltd
  Forum 1
  Station Road
  Theale
  Reading, RG7 4RA
  United Kingdom

  Telephone: +44 118 930 1300

  Facsimile: +44 118 930 1301

  E-mail: GK@ACM.ORG































Klyne                                                        [Page 15]