Internet Draft Greg Vaudreuil
Expires in six months Lucent Technologies
July 13, 2000
Voice Message Routing Service
<draft-ietf-vpim-routing-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 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 a "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.
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
This Internet-Draft is in conformance with Section 10 of RFC2026.
Overview
Voice messaging is traditionally addressed using telephone number
addressing. This document describes two techniques for routing voice
messages based on a telephone number. The VPIM Directory service
provides a mechanism to map between a telephone number and a VPIM
email address and confirm that the address is both valid and the
assocaited with the intended recipient. However this service will
take time become widely deployed in the nearest term. This document
also describes a more limited send-and-pray service useful simply to
route and deliver message using only the existing DNS mail routing
facilies, the ENUM telephone number resolution service, and a set of
pre-defined address creation rules.
Please send comments on this document to the VPIM working group
mailing list <vpim@lists.neystadt.org>
Internet Draft VPIM Routing July 13, 2000
Working Group Summary
This is a submission to the IETF VPIM working group.
Vaudreuil Expires 1/1/01 [Page 2]
Internet Draft VPIM Routing July 13, 2000
Table of Contents
1. ABSTRACT ..........................................................4
2. DESIGN GOALS ......................................................4
3. THE COMPLETE SERVICE ..............................................5
3.1 VPIM Directory Discovery ........................................5
3.2 Address Query ...................................................5
4. THE BASIC SERVICE .................................................6
4.1 Address Construction ............................................6
4.2 Inter-domain Message Routing ....................................7
4.3 Intra-domain Message Routing ....................................7
5. SECURITY CONSIDERATIONS ...........................................9
6. REFERENCES ........................................................9
7. ACKNOWLEDGMENTS ..................................................10
8. COPYRIGHT NOTICE .................................................10
9. AUTHORS' ADDRESSES ...............................................10
Vaudreuil Expires 1/1/01 [Page 3]
Internet Draft VPIM Routing July 13, 2000
1. Abstract
2. Design Goals
This profile is intended to provide a range of functional capabilities
for message routing based on one of two mechanisms. The most complete
service should the ENUM address resolution service to determine the
VPIM directory, and then use LDAP to retreive the VPIM email address
to use for message routing.
The most basic send-and-pray message service uses only address
construction rules, the ENUM service, and MX records to route the
message to the intended recipient's domain. The intelligence to
further route the message to the intended recipient is placed within
the message routing system of the recipient's domain.
The basic mechanism may be used even when there is a VPIM directory
service avaiable. The basic service is useful when LDAP queries are
not available, such as may be the case for disconnected mobile
terminals or because of firewall or information security policies.
The basic mechanism should facilitate the routing of VPIM messages to
a suitable internal destination with a minimum of configuration. . It
is an important goal to avoid any content-processing to determine the
nature of the message and it's internal destination. It should be
possible at a minimum to establish a simple mail forwarding rule to
send all inbound VPIM message to a designated system while
facilitating the routing of FAX, SMS, or other telephone addressed
messages to other potentially different systems
It is a goal that the mechanisms outlined in this document be
extensible for all store-and-forward, telephone-number addressed
messaging services.
It is a goal that the VPIM directory discovery and VPIM Directory
query steps ocure within the timing constraints for user interfaces in
PSTN networks. In general that constraint can be generalized to be a
two second response %95 of the time.
Vaudreuil Expires 1/1/01 [Page 4]
Internet Draft VPIM Routing July 13, 2000
3. The Complete Service
For the complete VPIM message routing service, the sending client
should query the VPIM directory for the VPIM-specific email address.
The client should use the ENUM service to retrieve the identity of the
VPIM Directory to query, and then query that server for the email
address and any additional attributed desired.
3.1 VPIM Directory Discovery
The VPIM directory server is found by querying DNS for the SRV record
associated with the domain name of the recipient as found in the
address resolution step.
The DNS query name is created by appending the VPIM service request
"_VPIMDIR._TCP" to the reverse-dotted telephone number based domain
name as described by [ENUM]. The telephone number used for the
directory location SHOULD NOT contain sub-address information. See
[ENUM]
Note: There are potential interactions and an increase in
provisioning burden when using a domain name with more levels
than necessary, especially when using CNAME redirection services.
In the absence of better understanding, this is best avoided.
See [ENUMOPS]
Example:
Query: _VPIM._TCP.2.1.2.1.5.5.5.3.1.6.1.e164.arpa
Response: SRV=vpimdir1.example.com weight=10 preference=10
port=389
SRV=vpimdir2.example.com weight=20 preference=10
port=389
Given the lack of elegant client-side redundancy for LDAP, and the
real-time requirements for a response, the VPIMDIR service should be
provided on a high-availability server to ensure the service is
available on the first try.
3.2 Address Query
Once the VPIM directory is discovered, the client should issue a LDAP
query for the vPIMrFC822Address. That is the address that should be
used as the value for both the RFC822 to: field and the SMTP RCPT TO
command. See [VPIMDIR]
To facilitate higher system availability, it is recommended that
VPIMDIR servers be deployed in redundant sets. These servers should be
listed in the SRV records with various weightings. The querying
system should attempt a connection to the lowest weight VPIMDIR
server. If it is down, the second should be contacted.
Vaudreuil Expires 1/1/01 [Page 5]
Internet Draft VPIM Routing July 13, 2000
4. The Basic Service
The basic service relies upon address creation rules to mechanically
construct an address that may be routed by the existing infrastructure
to the recipient's domain. In the recipient's domain, the
machanically constructed address may be further routed using intra-
domain mail routing techniques such as those defined in [LASER].
To facilitate a full range of intra-domain routing options, the
constructed email address should contain both the recipients telephone
number and an indication that the message is a VPIM message. For ease
of processing in the recipients intra-domain mail routing system, the
indication that the message is a VPIM message should be in the domain
name portion.
Note, that no validation that the constructed address is valid, nor
that the constructed address corresponds to the intended recipient.
Because no capabilities information is provided about the recipient,
messages sent with this mechaism SHOULD be sent using only the least-
common denominator media and content types of the intended message
*type*.
4.1 Address Construction
Mechanically construct an email address using only an algorithm
specific to the messaging service. For VPIM, the algorithm is as
follows:
1) Normalize the telephone number into E.164 form. Presentation
information such as spaces, prenthesis, periods, and dashes MUST be
stripped. Sub-addresses if known and explicitly indicated should be
appended to the address using the "+" sign. Construct the local part
of the email address by prefixing a "+" sign to the E164 telephone
number.
Examples:
+19727331212 (A Dallas, US based recipient)
+441819031212+2 (A Wembly, UK based recipient)
2) Construct the domain name portion of the address from the telephone
number. The sub-address does not affect the inter-domain routing of a
message. Strip the sub-address portion of the telephone number,
reverse and dot-stuff the digits consistent with the ENUM
specification. Prefix the service selector "_VPIM" to the address and
append the suffix "e164.arpa".
Examples:
_vpim.2.1.2.1.3.3.7.2.7.9.1.e164.arpa
_vpim.2.1.2.1.3.0.9.1.8.1.4.4.e164.arpa
3) Concatentate the local part and the domain portion with the "@"
symbol to yield the recipients basic VPIM address.
Vaudreuil Expires 1/1/01 [Page 6]
Internet Draft VPIM Routing July 13, 2000
Examples:
+19727331212@_vpim.2.1.2.1.3.3.7.2.7.9.1.e164.arpa
+441819031212+2@_vpim.2.1.2.1.3.0.9.18.1.4.4.e164.arpa
This is the address that should be used as the value for both the
RFC822 to: field and the SMTP RCPT TO command.
4.2 Inter-domain Message Routing
The inter-domain routing of a constructed VPIM address is mechanically
indistinguishable from existing email routing. No changes to the
infrastructure ar required. The sending system consults the Domain
name system for a MX record corresponding to the domain name and
forwards the message to the indicated system.
It is through the ENUM service that the MX records are provisioned for
specific telephone number or whole blocks of delegated telephone
numbers. Using the longest-match algorithms of DNS, the DNS routing
system may be service-ignostic and does not need to have individual MX
records for each service-specific sub-domain. However, if it is
desired to send messages addressed with a given service to the mail
server of a different domain, a service-specific MX record may be
provisioned on a per-telephone number basis. See [ENUMOPS] for a more
complete description of the structure of the ENUM service.
4.3 Intra-domain Message Routing
Within the recipient's domain, the message may be further routed to
the appropriate messaging system. Two general mechanisms may be used
to further route the message to the intended system within a network.
Note: This section is strictly informational. The mechanisms
for intra-domain routing are an internal matter for the domain
and do not affect the protocol. However, an understanding of
common intra-domain routing techniques is essential to the
mechanical creation of a useful address.
4.3.1 LASER Powered / Directory Enabled Routing
Various proprietary directory mechanisms and the emerging LASER
standard mechanism provide a means for a inbound mail router of the
recipients domain to send a message to the appropriate internal mail
host. In many cases, the local part of the address is used to query
for an internal mail address. That internal mail address is
substituted for the RCPT TO address and used to deliver the message to
the recipient mailbox. Note that the mailbox does not need to have
any knowledge of the mechanically constructed telephone number based
address.
4.3.2 Service-based Mail Routing
Alternately, a mail gateway may simply send all voice messages into a
separate messaging system. That system may be a single voice
Vaudreuil Expires 1/1/01 [Page 7]
Internet Draft VPIM Routing July 13, 2000
messaging server or a service-specific gateway into a larger
telephone-number based voice-messaging network.
Such a mail gateway may be provisioned with a simple rule or small set
of rules to forward all messages of a given service type to a pre-
defined server. This rule would check for the service name "_VPIM" as
a prefix to the domain name to re-route messages. In many cases, such
as with SMS messaging to mobile phones, this server may external to
the customers network.
Vaudreuil Expires 1/1/01 [Page 8]
Internet Draft VPIM Routing July 13, 2000
5. Security Considerations
There is little information disclosed to the sender of a message that
is not already disclosed using standard email protocols beyond the
ability to probe via send-and-fail the existance of a reachable
account associated with a telephone number, and via the NDN, determine
in which domain the account resides.
However, the use of a simple algorithm to create routeable email
addresses from telephone numbers provides bulk-emailers the
capablities to send email to a large set of recipients where only the
telephone number is known or where telephone numbers are guessed.
6. References
[E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN
Operation, Numbering, Routing and Mobile Service - Numbering Plan for
the ISDN Era.
[VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
Mail, Version 2", Work-in-Progress, July 2000.
[VPIMDIR] A. Brown and G. Vaudreuil "VPIM Directory Schema", work-in-
progress, July 2000.
[ENUM] P. Faltstrom "E.164 number and DNS", Work-in-Progress, July 2000.
[ENUMOPS] A. Brown and G. Vaudreuil "ENUM Service Specific Provisioning:
Principles of Operation", Work-in-Progress, July 2000.
Vaudreuil Expires 1/1/01 [Page 9]
Internet Draft VPIM Routing July 13, 2000
7. Acknowledgments
8. Copyright Notice
"Copyright (C) The Internet Society (2000). 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."
9. Authors' Addresses
Gregory M. Vaudreuil
Lucent Technologies,
17080 Dallas Parkway
Dallas, TX 75248-1905
United States
Phone/Fax: +1-972-733-2722
Email: GregV@ieee.org
Vaudreuil Expires 1/1/01 [Page 10]
