I'm forwarding this message from the IFAX list.... it does have some
implications for the work at hand. There is no reason the DNS database
could not point to a IPP URL as well
For those of you going to Washington DC next week ENUM is definitely a WG
to track.
>X-Sender: rshockey at popd.ix.netcom.com>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
>Date: Sat, 30 Oct 1999 10:29:38 -0500
>To: John Perkins <jperkins at exfax.com>, ietf-fax at imc.org>From: Richard Shockey <rshockey at ix.netcom.com>
>Subject: Re: proposal for a fax number - email address database
>Sender: owner-ietf-fax at imc.org>List-Archive: <http://www.imc.org/ietf-fax/mail-archive/>
>List-ID: <ietf-fax.imc.org>
>List-Unsubscribe: <mailto:ietf-fax-request at imc.org?body=unsubscribe>
>>>>>>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.
>>>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 <scott.petrack at metatel.com>
>> Transport Area Director(s):
> Scott Bradner <sob at harvard.edu>
> Vern Paxson <vern at aciri.org>
>> Transport Area Advisor:
> Vern Paxson <vern at aciri.org>
>> Mailing Lists:
> General Discussion:enum at ietf.org> To Subscribe: enum-request at ietf.org> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : rshockey at ix.netcom.com
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<