One document matched: draft-ietf-fax-addressing-01.txt
Differences from draft-ietf-fax-addressing-00.txt
Network Working C. Allocchio
Group GARR-Italy
INTERNET-DRAFT November 1997
Expires: May 1998
File: draft-ietf-fax-addressing-01.txt
PSTN and fax address format in e-mail services
v3.4
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. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It is
not appropriate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
1. Introduction
Since the very first e-mail to fax gateway objects appeared, a
number of different methods to specify a fax address into an
e-mail address have been used by implementors. Two major objectives
for this were
- enable an e-mail user to send faxes from his/her e-mail
interface;
- enable some kind of "fax over e-mail service" transport, to
reduce the costs of fax transmissions, and use the existing
e-mail infrastructure.
The definition of other services wich somehow interact with the
Public Switched Telephone Network (PSTN), like voice mail service
or GSM Short Messages Service (SMS), added other fields where a
PSTN address needs to be integrated into an e-mail address.
This memo describes a method to encode generic PSTN addresses
(including thus fax addresses) into e-mail addresses. The opposite
problem, i.e. to allow a traditional numeric-only telephone or fax
device user to access the e-mail transport service is not discussed
here.
This memo focuses on a generic e-mail service, being mainly
composed by the two major standard interconnected e-mail services,
Internet Mail and X.400, surrounded by a variety of non standard
(mainly LAN-based) e-mail serivces with their gateways to one or
both of the standard services.
The TPC.INT experiment already proposes a method to encode into the
Internet DNS the fax PSTN addresses. However TPC.INT approach is more
oriented towards a "fax routing strategy", i.e. to create a public
fax routing service that uses the Internet e-mail service, where the
Internet DNS service provides embedded fax routing information.
Such an approach, however, does not scale to closed users' group,
or to LAN-based fax services. TPC.INT approach is not in competition
with this proposal, though. In fact the TPC.INT addressing schema is
one of the many possible methods to address a so called "I-fax device"
in the Internet.
Even if in this memo we focus on e-mail addresses, a number of elements
defined in this specification can also be used for other specifications
dealing with PSTN addresses: for example URLs specification could adopt
similar definitions, with slight changes in the global syntax due to
specific URL format.
Finally, in this proposal we try to obtain maximum compatibility
with existing e-mail gateway services and standard specifications.
In particular it allows tunneling of the Internet e-mail fax and
other PSTN related messages across X.400 services (via MIXER
gateways), and also facilitate access to existing fax gateway
services over different e-mail transport systems with minimal or
null modifications to existing installed base.
In this document the formal definitions are described using ABNF
sintax, as defined into [referenceABNF]. We will also use some of
the "CORE DEFINITIONS" defined in "APPENDIX A - CORE" of that document.
2. PSTN address and Fax address
In order to create a flexible and extensible set of definitions, we
need to define uniquely the meaning of the diffrerent tokens composing
what is commonly called "PSTN address". Then we will also define a
specific subset of "PSTN addresses", i.e. the so called "fax address".
A pstn-address is composed of two main parts:
- a global or local PSTN telephone number (possibly supplemented
by a subaddress), called pstn-mbox
- an optional set of additional items, useful to add information
about the recipient or the message, called pstn-recipient.
If the message being transported is a fax message over e-mail service,
then the pstn-mbox telephone number should in common cases point to a
"fax aware" device, i.e. a fax machine, a fax gateway or any equivalent
one which is able to correctly process a fax message received via the
PSTN service.
The pstn-mbox element is sometimes not enough to specify additional
details, like intended recipient name, physical address, etc.
The optional pstn-recipient element provides information which can
also be used by the offramp gateway to specify exactly the recipient:
in case an offramp fax gateway is involved, the pstn-recipient element
can be used to compose a fax cover page.
NOTE: The pstn-address is the "local" (also known as "Left Hand
Side" or LHS) section of an e-mail address, i.e. the
element on the left of the "@" sign.
We define:
pstn-address = pstn-mbox
[ pstn-recipient ]
pstn-mbox = service-selector "=" ( global-phone / local-phone )
[ sub-sep sub-addr ] [post-sep post-dial]
NOTE: see section 4 in case multiple sub-addr need to be
specified.
service-selector = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in
; service-selector.
; service-selector MUST be handled as a case
; INSENSITIVE string by implementations.
Specifications adopting the pstn-address definition must define a
unique case insensitive service-selector element to identify the
specific messaging service involved.
For the fax over e-mail service the service-selector element is
predefined as
fax-service-selector = "FAX"
The resultant fax-address and fax-mbox are
fax-address = fax-mbox
[ pstn-recipient ]
fax-mbox = "FAX=" ( global-phone / local-phone )
[ sub-sep sub-addr ] [post-sep post-dial]
We define now in details the global-phone and local-phone elements:
global-phone = "+" int-country-code
[ area-code ]
local-number
; This is in agreement with ITU E.164 specification.
; area-code can be omitted only for countries
; which do not use an area-code system.
; This is a globally unique identifier on the PSTN
; and it must be reachable from anywhere.
NOTE: the pause character is not allowed in global-phone. If the User
Agent (UA) allow insertion of the pause character also into
the global-phone object, then this must be removed before
submission to the MTA.
local-phone = ( local-type1 / local-type2 / local-type3 )
NOTE: a local-phone specification is a sequence of digits and pauses
which should be dialled by the MTA specified by mta-I-pstn (see
section 3) to reach the destination device. Other MTAs should
only transfer the message around without modification until then
given destination MTA is reached. However the implementation
scenario is complex and its full discussion is out of scope in
this document.
local-type1 = [ exit-code ]
int-access-code
int-country-code
[ [ pause ] area-code ]
[ pause ] local-number
; this is the usual number dialed on traditional
; PSTN devices for an international call.
; area-code can be omitted only for countries
; which do not use an area-code system.
local-type2 = [ exit-code ]
long-distance-access area-code
[ pause ] local-number
; this is the usual number dialed on traditional
; PSTN devices for a national long distance call.
local-type3 = [ exit-code ]
[ local-number ]
; this is the usual number dialed on traditional
; PSTN devices for a local call or in countries
; where the area-code is not in use.
; Note that it could also be totally missing for
; cases where the local dialling device rely on
; local post-dial sequences only.
In common practice PSTN numbers are often written, for users
readability, using separators like SP, ".", "-" and others.
There elements do not actually belong to the number itself and
cannot be dialled on the PSTN services. However user specifying
a PSTN e-mail address will be facilitated if they can insert
these separators between dial elements like digits etc.
For this reason we allow in the syntax the write-sep element as
defined below.
The write-sep element MUST be ignored by all involved e-mail to
external service devices. The MTAs are also allowed to remove
the write-sep elements from pstn-mbox addresses. The use of the
write-sep is allowed, but not reccommended.
write-sep = ( "-" / "." )
int-country-code = 1*( DIGIT / write-sep )
; without the local international access
; prefix
int-access-code = 1*( DIGIT / write-sep )
; examples: "00", "010", "19"
long-distance-access = 1*( DIGIT / write-sep )
; in many countries this code is "0" or "1"
exit-code = phone-string
; this include anything needed to enable dialling, like
; the digit to access outside line, the long distance
; carrier access code, the access password to the service
; and also allows special DTMF "#", "*", "A", "B", "C"
; and "D" codes
area-code = 1*( DIGIT / write-sep )
; without the eventual leading long-distance-access code.
; NOTE: some countries do not use an internal area-code
; structure
local-number = 1*( DIGIT / pause / write-sep )
; this is the usual number dialed on traditional
; devices for a local call
IMPORTANT NOTE: the description of local-phone is complex due to a large
number of possible variants in the existing phone systems. However its own
structure can also be described as a 'sequence of DIGIT, pause, tonewait,
"#" and "*" appropriate to the local dialling environment in order to
reach the final destination device'.
phone-string = 1*( DIGIT / pause / tonewait / "#" / "*" /
"A" / "B" / "C" / "D" / write-sep )
; this includes also special DTMF codes like "*",
; "#", "A", "B", "C", "D" defined in [reference ETSI]
; Important Note: this is NOT the alpha to digit
; convention in use in some countries.
In PSTN service there are cases where a sub-addr is required to specify
the final destination. In particular there are ISDN subaddresses, which
are common to all possible services, including fax service, and T.33
subaddresses which are limited to the fax service only. We must thus
be able to distinguish the two possible cases, remembering that using
a T.33 subaddress outside the fax service makes absolutely no sense.
As a consequence, for all possible services we define:
sub-sep = isdn-sep
while for the fax over e-mail service only we allow the alternate choice
of:
sub-sep = ( isdn-sep / t33-sep )
In details:
isdn-sep = "/ISUB="
; note that "/ISUB=" is case INSENSITIVE
t33-sep = "/TSUB="
; note that "/TSUB=" is case INSENSITIVE and can be used
; within fax service only.
sub-addr = 1*( DIGIT / write-sep )
pause = ( "p" / "P" )
tonewait = ( "w" / "W" )
NOTE: "pause" and "tonewait" character interpretation in local-phone numbers
depends on the specific MTA implementation. Thus its exact meaning
need not to be defined here.
post-sep = "/POSTD="
; note that "/POSTD=" is case INSENSITIVE
post-dial = phone-string
; this include anything needed to access the final device
; on the PSTN, like further dialing sequenes
; and also allows special DTMF "#", "*", "A", "B", "C"
; and "D" codes
A number of pstn-mbox examples are listed in section 5.1
We define now the optional and extensible pstn-recipient item:
pstn-recipient = [ recipient-name ]
[ 1*( recipient-qualifier ) ]
recipient-name = ( personal-type1 / personal-type2 )
personal-type1 = "/PN="
[ givenname [ "." ] ]
[ initials [ "." ] ]
surname
; this is compatible with ITU F.401
personal-type2 = [ "/G=" givenname ]
[ "/I=" initials ]
"/S=" surname
; this is compatible with ITU F.401
The following definitions come directly from MIXER specification:
surname = printablestring
givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" /
"," / "-" / "/" / ":" / "=" / "?" )
initials = 1*ALPHA
NOTE: the two possible formats of recipient-name are both in
common use. Implementations should accept both, but
generate personal-type1 only.
And also the extensible recipient-qualifier:
recipient-qualifier :== ( qualif-type1 / qualif-type2 )
qualif-type1 = "/" keyword "=" string
keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in keyword
qualif-type2 = "/" x400-label "=" printablestring
x400-label = ( "GQ" / "O" / "OU1" / "OU2" / "OU3" / "OU4" /
"P" / "A" / "C" / "PD-PN" / "PD-EA" / "PD-ED" /
"PD-OFN" / "PD-OF" / "PD-O" / "PD-S" / "PD-A" /
"PD-U" / "PD-L" / "PD-R" / "PD-B" / "PD-PC" /
"PD-SN" / "PD-C" / "X121" / "E164" / "PSAP" /
"N-ID" / "T-ID" / "T-TY" / "DD." dd-key )
; this is the full list of existing text labels
; according to ITU F.401. "PD-x" labels provide
; a set of predefined attributes for physical
; delivery which can be also useful for message
; recipient identification.
dd-key = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in dd-key
string = PCHAR
; note that printable characters are %x20-7E
printablestring = 1*( DIGIT / ALPHA / SP /
"'" / "(" / ")" / "+" / "," / "-" /
"." / "/" / ":" / "=" / "?" )
; this definition comes from ITU F.401 and
; [MIXER].
NOTE: if we use WSP and other specials in string, the obtained
pstn-address will result in quoted-string; this could create
problems to some existing broken MTA and UA implementations.
WSP and specials are defined in [rfc822bis].
The specific use of extension keywords, and the eventual registration
of extension keyword is out of the scope of this specification. Specific
qualif-type1 and qualif-type2 use is an implementation issue.
The pstn-recipient object is intended to specify per-recipient elements to
be used to identify the exact recipient. In the specific case of fax over
e-mail service, the pstn-recipient object is intended to be used to
identify the fax recipient on the fax cover page generated by the MTA
given in mta-I-pstn. For specific fax cover generation issues see also
appendix A.
See section 5.2 for pstn-recipient examples.
3. The e-mail address of the I-pstn device: mta-I-pstn
An "I-pstn device" owns an e-mail address, or to be more exact, a
name which enables a mail system to identify it on the e-mail
global system. In the specific case of the fax service, the I-pstn
device is known as "I-fax device".
In Internet mail, this is the Right Hand Side (RHS) part of the
address, i.e. the part on the right of the "@" sign. We will call
this mta-I-pstn.
mta-I-pstn = domain
where domain SHALL be a fully-qualified canonical domain name as
defined in RFC 1035 and the SMTP specification syntax production
for <domain> as defined in RFC 821.
4. The pstn-email
The complete structure used to transfer a PSTN address over the Internet
e-mail transport system is called pstn-email. This object is a an e-mail
address which conforms to RFC822 addr-spec syntax, with extra structure
which allows the PSTN number to be identified.
pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn
NOTE: the optional "/" characters can result from other mail transport
services gateways, where it is also an optional element.
Implementations should accept it, but should not generate such
element. Gateways are allowed to strip them off when converting
to Internet mail addressing.
In case there are multiple sub-addr to be given on the same pstn-mbox
then multiple pstn-email elements will be used. The UA could accept
multiple sub-addr elements for the same global-phone / local-phone,
but it must generate multiple pstn-mbox, when passing the message to
the MTA.
4.1 The fax-email
The fax-email element is just a specific version of pstn-email for the
fax over the Internet e-mail transport system, where the distinction
element is just the fixed "FAX" service-selector.
fax-email = ["/"] fax-address ["/"] "@" mta-I-pstn
In this case the mta-I-pstn will usually point to an "I-fax" device
where the fax message is handled properly.
5. Examples
In order to clarify the specification we present here a limited
set of examples. Many of the examples refer to the fax service,
but also additional possible services are included.
5.1 pstn-mbox examples
A pstn-mbox address in Italy for the fax service, using global-phone,
without sub-addr and without write-sep:
FAX=+3940226338
A pstn-mbox address in Germany for an hypotetical XYZ service, using
global-phone, with ISDN sub-addr 1234 and write-sep ".":
XYZ=+49.81.7856345/ISUB=1234
A pstn-mbox address in U.S.A. for fax service, using global-phone,
with T.33 sub-addr 8745, with write-sep "-" and post-dial sequence
p1w7005393w373
FAX=+1-202-455-7622/TSUB=8745/PostD=p1w7005393w373
A pstn-mbox address in Italy for fax service, using local-phone,
dialed from an MTA in Germany, with int-access-code "00", with T.33
subaddress "4312" and without pause or write-sep:
FAX=003940226338/Tsub=4312
The same pstn-mbox address in Italy, using local-phone dialed from
an MTA in Italy (long distance call), with long-distant-access "0",
with exit-code "9", T.33 subaddress "4312", pause "p" and write-sep
".":
FAX=9p040p22.63.38/tsub=4312
A pstn-mbox address in North America for hypotetical service XYZ,
using global-phone, without sub-addr and write-sep "-" and ".":
XYZ=+1.202.344-5723
A pstn-mbox address for fax service in France, using local-phone
dialed from an MTA in France (long distance call), with exit-code
"0", T.33 subaddress "3345" and pause "p":
FAX=0p0134782289/TSUB=3345
A pstn-mbox address for fax service in North America, using local-phone,
without sub-addr, without local-number, using only post-dial sequences to
reach numbers stored in a locally defined short-dial numbers database,
where 6743 is an access password, and 99p51 is the sequence to access
the local short-dial number:
FAX=/postd=w6743w99p51
5.2 pstn-recipient examples
Here are a number of pstn-recipient examples. Please note that
pstn-recipient is just an optional element, and thus a pstn-mbox
element also is required in a pstn-address.
A pstn-recipient using only recipient-name of personal-type1,
with givenname initials and surname:
/PN=Tom.J.Smiths
A pstn-recipient using only recipient-name of personal-type1,
with givenname and surname:
/PN=Mark.Collins
A pstn-recipient using only recipient-name of personal-type2,
with surname only:
/S=Smiths
A pstn-recipient using recipient-name of personal-type1, and
one recipient-qualifier extension:
/PN=J.Smiths/dept=Quaility-control
A pstn-recipient using two recipient-qualifier extension, only:
/office=T2-33A/dept=Q-C
A fax-reciepint using some recipient-quelifier extension derived from
ITU F.401 physical delivery label set:
/PD-S=Main.Street/PD-SN=45/PD-OF=Sales.dept
5.3 pstn-address examples
Some pstn-address examples, obtained combining elements from
previous examples. There are complete addresses which can
be used as "local part" (LHS) element of an e-mail address.
Without optional pstn-recipient (fax service):
FAX=+12023445723
With pstn-recipient of personal-type1 (XYZ service):
XYZ=+3940226338/PN=Mark.Collins
With pstn-recipient made of two recipient-qualifier extensions
(fax service):
FAX=9p040p22.63.38/tsub=4312/office=T2-33A/dept=Q-C
5.4 pstn-email examples
Here are the same addresses as before, where "faxgw" is the
mta-I-pstn field for the fax service.
FAX=+12023445723@faxgw
FAX=+39-40-226338/PN=Mark.Collins@faxgw
FAX=9p040p226338/TSUB=4312/office=T2-33A/dept=Q-C@faxgw
FAX=+3940226338/PN=Mark.Collins/@faxgw
NOTE: the optional "/" in front for the "@" sign can be generated
by gateways to other services, like MIXER.
5.5 A complete SMTP transaction example:
Here is an example of complete SMTP transaction.
S: <listening on SMTP port>
C: <opens connection to SMTP port>
S: 220 foo.mailfax.com ESMTP service ready
C: EHLO pc.mailfax.com
S: 250 foo.mailfax.com says hello
C: MAIL FROM:<tom@mailfax.com>
S: 250 <tom@mailfax.com> Sender ok
C: RCPT TO:<FAX=+3940226338@foo.mailfax.com>
S: 250 <FAX=+3940226338> recipient ok
C: DATA
S: 354 Enter your data
C: From: Thomas Blake <tom@mailfax.com>
C: To: <FAX=+3940226338@foo.mailfax.com>
C: Subject: Hello there
C: MIME-version: 1.0
C: Date: Mon, 01 Sep 1997 18:14:23 -0700
C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306
C:
C: This is a MIME message. It contains a
C: TIFF-F fax bodypart
C:
C: --16820115-1435684603#2306
C: Content-Type: image/TIFF-F
C: Content-Tranfer-Encoding: BASE64
C: Content-Description: FAX
C:
C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA
C: 87AASS2999499ASDANASDF0000ASDFASDFNANN
C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0
C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8==
C: --16820115-1435684603#2306--
C: .
S: 250 Okay
C: QUIT
S: 221 Goodbye
6. Conclusion
With this proposal we try to create a standard encoding for PSTN
addresses within global e-mail transport system. The proposal
requires no changes to existing e-mail software. An update to
existing MIXER gateways specification is envisaged, to extend
accessibility also to X.400 fax gateway services in a transparent
way.
7. Security Considerations
This document specifies a means by which PSTN addresses can be
encoded into e-mail addresses. As routing of e-mail messages is
determined by Domain Name System (DNS) information, a succesful
attack on this service could force the mail path via some particular
gateway or message transfer agent where mail security can be
affected by compromised software.
There are several means by which an attacker might be able to
deliver incorrect mail routing information to a client. These
include: (a) compromise of a DNS server, (b) generating a
counterfeit response to a client's DNS query, (c) returning
incorrect "additional information" in response to an unrelated
query. Clients SHOULD ensure that mail routing are based only
on authoritative answers. Once DNS Security mechanisms [RFC 2065]
become more widely deployed, clients SHOULD employ those mechanisms
to verify the authenticity and integrity of mail routing records.
Some PSTN service require dialing of private codes, like Personal
Identification Numbers, to access special services. As e-mail
addresses are transmitted without encoding over the MTAs transport
service, this could allow unauthorized people to gain access to
these codes when used inside local-phone. Use of double key
encryption techniques for local-phone can solve these security
problem.
8. Author's Address
Claudio Allocchio
Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy
RFC822: Claudio.Allocchio@elettra.trieste.it
X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio;
Phone: +39 40 3758523
Fax: +39 40 3758565
A. Fax cover generation issues
In electronic mail world, messages contain an header which gives
information about different items: some of them are intended for
message identification, while others contain information usable by
the recipient.
The equivalent of the message headers for faxes is the fax cover, as
it also conveys similar information. Moreover for faxes there are
sometimes legal and official requirements which makes compulsory the
generation of certain information of the fax cover.
The fax cover generation is a complex topic and needs a detailed
study. In this appendix we only define some methods and equivalences
for fax cover generation starting from RFC822 message headers and we
suggest some examples on how pstn-recipient optional fields can be used
on the fax cover. For the complete description of fax cover generation
methods, please refer to [document in preparation].
A.1 Use of message header fields for cover generation
In this section we define a set of message headers which should be
included in fax message cover. These headers will be included for all
recipients of the fax message.
The following header fields, when present, must be included into the
generated fax cover page:
Date Message-Id Reply-To Sensitivity
From Importance Subject
To Cc Bcc
NOTE: if fax message is generated from a Bcc destination address, "blind
carbon copy" rules apply, i.e. other recipients must not be present
on fax cover.
Any other header field may be included, when present, into the generated
fax cover page.
A.2 Cover page elements generated from pstn-recipient information
Using the optional pstn-recipient information, the sender can specify
further detailed information to be used (also for) fax cover generation.
This information will be included only on the fax cover page being
generated for the specific pstn-mbox.
A.2.1 recipient-name
The recipient-name field, if present, must be included on the fax cover
page. The field must be used to specify the name of the intended fax
recipient.
A.2.2 recipient-qualifier
The recipient-qualifier field, if present, should be included on the fax
cover page. Due to its "label" = "value" format, it is suggested to
generate fax cover fields in a consistent syntax, for example:
label: value
A set of "label" human readable descriptions for x400-label is given
in ITU F.401, tables B-1/F.401, B-2/F.401, B-3/F.401; they could suggest
a consistent method for some fax cover fields representation.
B. Recipient identification for non fax services.
The same set of suggestions given in the above appendix A can also be
easily applied to other services which could use this addressing
specification. In particular the pstn-recipient information could
be used by voice-related service to identify the real recipient of
the voice message, or to specify the recipient of a GSM SMS memo.
As specific cases are strictly related to specific services, we cannot
define here additional details. However the guidelines of appendix A
should be adopted as a basis.
C. References
RFC821 Simple Mail Transfer Protocol. J. Postel. (August 1982)
RFC822 Standard for the format of ARPA Internet text messages. D.
Crocker. (August 1982)
RFCxxxx (DRAFT-IETF-DRUMS-MSG-FMT-xx.TXT) Message Format Standard.
P. Resnick. (xxxx 199x)
RFCxxxx (DRAFT-IETF-DRUMS-SMTPUPD-xx.TXT) Simple Mail Transfer
Protocol. J. C. Klensin, D. P. Mann. (xxxx 199x)
RFCxxxx (DRAFT-KILLE-MIXER-RFC1327BIS-xx.TXT) MIXER (Mime Internet
X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME.
S.E. Kille. (xxxx 199x)
RFC1035 Domain names - implementation and specification. P.V.
Mockapetris. (November 1987)
RFC2065 Domain Name System Security Extensions. D. Eastlake, 3rd, C.
Kaufman. (January 1997)
RFCxxxx (DRAFT-IETF-DRUMS-ABNF-xx.TXT) Augmented BNF for Syntax
Specifications: ABNF. D.Crocker, P. Overell (xxxx 199x)
RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote
Printing -- Technical Procedures. C. Malamud & M. Rose. (October 1993)
ITU F.401 - Message Handling Services: Naming and Addressing for Public
Massage Handling Service; reccommendation F.401 (August 1992)
ITU F.423 - Message Handling Services: Intercommunication Between the
Interpersonal Messaging Service and the Telefax Service; reccommendation
F.423 (August 1992)
ITU E.164 - Numbering plan for the ISDN era; recommendation E.164/I.331
(August 1991)
ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT): Access
Devices Dual Tone Multi Frequency (DTMF) sender for acoustical coupling
to the microphone of a handset telephone (March 1995)
| PAFTECH AB 2003-2026 | 2026-04-23 11:25:58 |