分享
 
 
 

RFC2303 - Minimal PSTN address format in Internet Mail

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group C. Allocchio

Request for Comments: 2303 GARR-Italy

Category: Standards Track March 1998

Minimal PSTN address format in Internet Mail

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

IESG NOTE

This memo describes a simple method of encoding PSTN addresses in the

local-part of Internet email addresses, along with an extension

mechanism to allow encoding of additional standard attributes needed

for email gateways to PSTN-based services.

As with all Internet mail addresses, the left-hand-side (local- part)

of an address generated according to this specification, is not to be

interpreted except by the MTA that is named on the right-hand-side

(domain).

1. IntrodUCtion

Since the very first e-mail to PSTN services gateway appeared, a

number of different methods to specify a PSTN address as an e-mail

address have been used by implementors. Two major objectives for this

were

- enable an e-mail user to Access these services from his/her

e-mail interface;

- enable some kind of "PSTN over e-mail service" transport, to

reduce the costs of PSTN long distance transmissions, and use the

existing e-mail infrastructure.

This memo describes the MINIMAL addressing method to encode PSTN

addresses into e-mail addresses and the standard extension mechanism

to allow definition of further standard elements. The opposite

problem, i.e. to allow a traditional numeric-only PSTN device user to

access the e-mail transport service, is not discussed here.

All implementations supporting this PSTN over e-mail service MUST

support as a minimum the specification described in this document.

The generic complex case of converting the whole PSTN addressing into

e-mail is out of scope in this minimal specification: there is some

work in progress in the field, where also a number of standard

optional extensions are being defined.

In this document the formal definitions are described using ABNF

syntax, as defined into [7]. We will also use some of the "CORE

DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The

exact meaning of the capitalised Words

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",

"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

is defined in reference [6].

2. Minimal PSTN address

The minimal specification of a PSTN address in e-mail address is as

follows:

pstn-address = pstn-mbox [ qualif-type1 ]

pstn-mbox = service-selector "=" global-phone

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.

These specifications MUST also define which minimal "qualif-type1"

extensions, if any, MUST be supported for the specified service.

Implementations confirming to these minimal requirements

specification are allowed to ingnore any other non-minimal extensions

address element which can be present in the "pstn-address". However,

conforming implementations MUST preserve all "qualif-type1" address

elements they receive.

The generic "qualif-type1" element is defined as:

qualif-type1 = "/" keyword "=" string

keyword = 1*( DIGIT / ALPHA / "-" )

; note that SP (space) is not allowed in keyword

string = PCHAR

; note that printable characters are %x20-7E

As such, all "pstn-address" extensions elements MUST be defined in

the "qualif-type1" form.

2.1 Minimal "global-phone" definition

We now define the minimal supported syntax for global-phone:

global-phone = "+" 1*( DIGIT , written-sep )

written-sep = ( "-" / "." )

The use of other dialling schemas for PSTN numbers (like private

numbering plans or local dialling conventions) is also allowed.

However, this does not preclude nor remove the minimal compulsory

requirement to support the "global-phone" syntax as defined above.

Any non "global-phone" dialling schema MUST NOT use the leading "+"

between the "=" sign and the dialling string. The "+" sign is

strictly reserved for the standard "global-phone" syntax.

Note:

The specification of these different dialling schemas is out of

scope for this minimal specification.

User specification of PSTN e-mail addresses will be facilitated if

they can insert these separators between dial elements like digits

etc. For this reason we allow them in the syntax the written-sep

element.

Implementors' note:

Use of the written-sep elements is allowed, but not recommended.

Any occurences of written-sep elements in a pstn-mbox MUST be

ignored by all conformant implementations. User Agents SHOULD

remove written-sep elements before submitting messages to the

Message Transport System.

2.2 Some examples of a minimal "pstn-address"

VOICE=+3940226338

FAX=+12027653000/T33S=6377

SMS=+33-1-88335215

3. The e-mail address of the I-pstn device: mta-I-pstn

An "I-pstn device" has 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 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

For "domain" strings used in SMTP transmissions, the string MUST

conform to the requirements of that standard's <domain>

specifications [1], [3]. For "domain" strings used in message

content headers, the string MUST conform to the requirements of the

relevant standards [2], [3].

Note: in both cases, the standards permit use of "domain names" or

"domain literals" in addresses.

4. The pstn-email

The complete structure used to transfer a minimal 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 [2] and

RFC1123 [3] "addr-spec" syntax, with some extra structure which

allows the PSTN number to be identified.

pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn

Implementors' note:

The optional "/" characters can result from other mail transport

services gateways, where it is also an optional element.

Implementations MUST accept the optional slashes but SHOULD NOT

generate them. Gateways are allowed to strip them off when

converting to Internet mail addressing.

It is essential to remind that "pstn-address" element MUST strictly

follow the "quoting rules" spcified in the relevant standards [2],

[3].

4.1 Multiple subaddresses

In case a particular service requires multiple subaddresses (in any

form defined by the specific standard specification for that

service), and these subaddresses need to be given on the same "pstn-

mbox", multiple "pstn-email" elements will be used.

Implementors' note:

The UA could accept multiple subaddress elements for the same

global-phone, but it must generate multiple "pstn-mbox" elements

when passing the message to the MTA.

4.2 Some examples of "pstn-email"

VOICE=+3940226338@worldvoice.com

FAX=+1.202.7653000/T33S=6377@faxserv.org

/SMS=+33-1-88335215/@telecom.com

5. Conclusions

This proposal creates a minimal standard encoding for PSTN addresses

within the global e-mail transport system and defines the standard

extension mechanism to be used to introduce specific new elements.

The proposal requires no changes to existing e-mail software. Each

specific PSTN service using this proposal MUST define its own

"service-selector" specification and MUST define the eventual other

"qualif-type1" elements to be supported for its minimal addressing

specification. An example is in reference [13].

6. 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 successful

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 is based only on authoritative answers. Once DNS

Security mechanisms [5] become more widely deployed, clients SHOULD

employ those mechanisms to verify the authenticity and integrity of

mail routing records.

7. 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

8. References

[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,

August 1982.

[2] Crocker, D., " Standard for the format of ARPA Internet text

messages", STD 11, RFC822, August 1982.

[3] Braden, R., "Requirements for Internet hosts - application and

support", RFC1123, October 1989.

[4] Malamud, C. and M. Rose, "Principles of Operation for the

TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC

1528, October 1993.

[5] Eastlake, D. and C. Kaufman, "Domain Name System Security

Extensions", RFC2065, January 1997.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", RFC2119, March 1997.

[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax

Specifications", RFC2234, November 1997.

[8] ITU F.401 - Message Handling Services: Naming and Addressing for

Public Message Handling Service; recommendation F.401 (August

1992)

[9] ITU F.423 - Message Handling Services: Intercommunication

Between the Interpersonal Messaging Service and the Telefax

Service; recommendation F.423 (August 1992)

[10] ITU E.164 - Numbering plan for the ISDN era; recommendation

E.164/I.331 (August 1991)

[11] ITU T.33 - Facsimile routing utilizing the subaddress;

recommendation T.33 (July, 1996)

[12] 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)

[13] Allocchio, C., " Minimal FAX address format in Internet Mail",

RFC2304, March 1998.

[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping

between X.400 and RFC822/MIME", RFC2156, January 1998.

9. Full Copyright Statement

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有