Subject: proposal for a fax number - email address database

From: John Perkins <[email-masked]>
Date: Sat, 30 Oct 1999 16:47:24 +1000

Greetings.

I would like to raise the proposal as outlined below, in this forum, as it
may or could have standards implications. It is certainly related to
Internet and to fax and would benefit from a standard global solution. I
also apologise for my ignorance in advance of any relevant preceeding
discussion. 

What I propose may be naive and idealistic, but I have little doubt it is
technically feasible. I believe it would have wide benefits, however I do
acknowlegde that as a vendor who could make use of it, I would also have a
benficial interest. If for this reason I am out of order, or the posting is
not relevant here, I apologise for that.

Proposal
--------
I would like to propose a universally accessible database or lookup
procedure whereby individuals may validly and voluntarily nominate an email
address to be associated with their fax telephone number. Database entries
could be set up at a web site administered by a suitable authority or in
conjuction with telephone companies. The email address would be for use as
an alternative destination to the fax number under certain conditions. The
email address would be retrieved by suitable URL reference which would
include the phone number. The alternative email address could be used when
for example the fax line was busy or unavailable, and would receive the fax
as a TIFF attachment. The database facility would enable automatic
contingency routing. The database may reside on a server accessed by cgi
scripts or may take some other form compatible with the infrastructure.

Background
----------
A large number of phone lines which are used as dial-up lines for Internet
access are also used at other times for voice or fax traffic. There now
exist schemes such as Internet call diversion whereby an incoming voice
call to a PSTN number can be converted to an IP voice call in the event
that the number is currenty busy with an IP connection. This requires that
the user pre-register for the service with the telco and have certain
software loaded and running in the event that a call is received.

It may increasingly be the case that phone lines previously dedicated to
fax may similarly be used for occasional dial-up Internet access. A scheme
similar to Internet call diversion could be implemented whereby the dial-up
subscriber installs suitable software to receive a real time fax, converted
to IP by the telco. An easier alternative would be for the fax message to
be encapsulated as a TIFF and forwarded by email. Various parties may wish
to perform this service. The availbility of a universal database to
facilitate this would be of benefit to consumers. vendors and (possibly)
telcos alike.

Security issues
---------------
The possibility of mis-use may be the most serious implementation obstacle.
Certain users may wish to partake of this service, in co-operation with
their telco, in a such a way that the email address is not divulged. In
that case they may have to pay for a service which may otherwise be free.
(It is always a free call to find out if a number is busy).

Some security would be afforded by operator fax receipt confirmation. After
registration, the email address would not become operational before
validation by the fax line owner. This could be done by the registation
process sending a fax message to the desinated fax number containing a code
which must be correctly entered into a confirmation message sent from the
designated email address.

--------------------------------------------------------
John Perkins	
Exfax Technologies Pty Ltd
PO Box 6004    Melbourne    Australia  3004
Tel +61 3 9534 5495	Fax +61 3 9534 8994
http://www.exfax.com
--------------------------------------------------------

---

From: Richard Shockey <[email-masked]>
Date: Sat, 30 Oct 1999 10:29:38 -0500

>scripts or may take some other form compatible with the infrastructure.

Well ...you're not too far off from reality its just that the database is 
DNS.... the following new work has just been chartered in the IETF.  It has 
additional implications for discovering the capabilities of a IFAX machine 
in advance of sending a document.

Telephone Number Mapping (enum)
-------------------------------

  Current Status: Proposed Working Group

  Chair(s):
      Scott Petrack <[email-masked]>

  Transport Area Director(s):
      Scott Bradner  <[email-masked]>
      Vern Paxson  <[email-masked]>

  Transport Area Advisor:
      Vern Paxson  <[email-masked]>

  Mailing Lists:
      General Discussion:[email-masked]
      To Subscribe:      [email-masked]
          In Body:       subscribe

      OR, subscribe via the web at
         http://www.ietf.org/mailman/listinfo/enum

      Archive:           ftp://ftp.ietf.org/ietf-mail-archive/enum/

Description of Working Group:

This working group will define a DNS-based architecture and protocols
for mapping a telephone number to a set of attributes (e.g. URLs) which
can be used to contact a resource associated with that number.

Background:

Telephone numbers now identify many different types of end terminals,
supporting many different services and protocols. Telephone numbers
are used to identify ordinary phones, fax machines, pagers, data
modems, email clients, text terminals for the hearing impaired, etc.

A prospective caller may wish to discover which services and
protocols are supported by the terminal named by a given telephone
number. The caller may also require more information than just the
telephone number to communicate with the terminal.

As an example, certain telephones can receive short email messages.
The telephone number is not enough information to be able to send
email; the sender must have more information (equivalent to the
information in a mailto: URL).

 From the callee's perspective, the owner of the telephone number
or device may wish to control the information which prospective
callers may receive.

The architecture must allow for different service providers competing
openly to furnish the directory information required by clients to
reach the desired telephone numbers.

Working Group Goals and Scope:

The working group will specify a DNS-based architecture and protocols
which fulfill at least the following requirements:

1. The system must enable resolving input telephone numbers into a set
    of URLs which represent different ways to start communication with a
    device associated to the input phone number.

2. The system must scale to handle quantities of telephone numbers and
    queries comparable to current PSTN usage. It is highly desireable
    that the system respond to queries with speed comparable to current
    PSTN queries, including in the case of a query failure.

3. The system must have some means to insert the information needed
    to answer queries into the servers via the Internet. The source of
    this information may be individual owners of telephone numbers (or
    the devices associated to the number), or it may be service providers
    which own servers that can answer service-specific queries. The
    system shall not preclude the insertion of information by competing
    service providers (in such a way which allows for the source of the
    information to be authenticated).

4. The system shall enable the authorization of requests and of updates.

5. The Working Group will carefully consider and document the security
    and performance requirements for the proposed system and its use.

6. The Working Group will understand the impact of developments in the
    area of local number portability on the proposed system.

The Working Group will take into consideration how number resolution
using the ENUM system is affected by the PSTN infrastructure for
telephone numbering plans, such as the ITU-T E.164 standard.

The area directors will consider chartering an additional working group
to pursue a non-DNS-based approach, if there's a constituency for the
approach and a viable charter.

Non-goals:

1. ENUM shall not develop any protocols or system for routing calls of a
    specific service or for locating gateways to a specific service.  One
    example of such a service is mobile telephony, and one example of
    such gateways is IP telephony gateways.

2. ENUM shall not develop protocols for the "intelligent" resolution of
    these queries. That is, the updates to the ENUM data are limited to
    the insertion, update, and removal of URL information, and will not
    include inserting "logic" into the servers (to be used to respond to
    queries in an "intelligent" manner).  (Of course, servers are free to
    support such intelligent services, but the insertion of such logic is
    not the object of ENUM standardization).

Document deliverables:

1. Telephone Number to IP Mapping Service Requirements (Informational)

2. Telephone Number to IP Mapping Service Architecture and
    Protocols (Standards Track)

    These documents will specify the architecture and protocols
    (query, update) of the ENUM system.

3. A MIB for managing the service

4. The Working Group may decide to deliver a document which describes
    the relation between ENUM and E.164 or other PSTN telephone number
    infrastructure.

  Goals and Milestones:

    Nov 99       Initial draft of Service ENUM 
Requirements

    Jan 00       Initial draft of ENUM 
Protocol

    Mar 00       Revised draft of ENUM Service 
Requirements

    Mar 00       Revised draft of ENUM 
Protocol

    Mar 00       Possible draft on relation between ENUM and E.164 or other 
PSTN
                 infrastructure