rfc2846.txt

RFC 的详细文档！

   A pstn-mbox address in U.S.A. for fax service, using global-phone,
   with T.33 sub-addr-spec 8745, with written-sep "-" and post-dial
   sequence p1w7005393w373

      FAX=[phone]/T33S=8745/PostD=p1w7005393w373

   A pstn-mbox address in Italy for fax service, using local-phone,
   dialed from an MTA in Germany, (international access code "00", with
   ISDN subaddress 9823, with T.33 subaddress "4312" and without pause
   or written-sep:



Allocchio                   Standards Track                     [Page 9]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


      FAX=003940226338/Isub=9823/T33S=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 written-sep ".":

      FAX=9p040p22.63.38/t33s=4312

   A pstn-mbox address in North America for hypothetical service XYZ,
   using global-phone, without sub-addr-spec and written-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/T33s=3345

   A pstn-mbox address for fax service in North America, using local-
   phone, without sub-addr-spec, 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, with givenname initials
   and surname:

      /ATTN=Tom.J.Smiths

   A pstn-recipient using only recipient-name, with givenname, a
   complete set of initials (including the first name initial "C") and
   surname (where the "real life" givennames are "Carlo Maria Luis
   Santo" and the surname is "Nascimento"):

      /ATTN=Carlo.CMLS.Nascimento

   A pstn-recipient using only recipient-name, with givenname and
   surname:



Allocchio                   Standards Track                    [Page 10]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


      /ATTN=Mark.Collins

   A pstn-recipient using only recipient-name, with surname only:

      /ATTN=Smiths

   A pstn-recipient using recipient-name, and one recipient-qualifier
   element:

      /ATTN=J.Smiths/OFNA=Quaility-control

   A pstn-recipient using two recipient-qualifier extension, only:

      /OFNO=T2-33A/OFNA=Quality-Ccontrol

   A fax-recipient using some recipient-qualifier for physical delivery:

      /STR=45, Main.Street/OFNA=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=[phone]

   With pstn-recipient (XYZ service):

      XYZ=[phone]/ATTN=Mark.Collins

   With pstn-recipient made of two recipient-qualifier extensions (fax
   service):

      FAX=9p040p22.63.38/t33s=4312/ofno=T2-33A/OFNA=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=[phone]@faxgw

      FAX=[phone]/ATTN=Mark.Collins@faxgw

      FAX=9p040p226338/T33S=4312/OFNO=T2-33A/OFNA=Q-C@faxgw



Allocchio                   Standards Track                    [Page 11]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


      FAX=[phone]/ATTN=Mark.Collins/@faxgw

   NOTE: the optional "/" in front for the "@" sign can be generated by
   gateways to other services, like MIXER [3].

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.domain.com ESMTP service ready
   C: EHLO pc.mailfax.com
   S: 250 foo.domain.com says hello
   C: MAIL FROM:<[e-mail]>
   S: 250 <[e-mail]> Sender ok
   C: RCPT TO:<FAX=[e-mail]>
   S: 250 <FAX=[phone]> recipient ok
   C: DATA
   S: 354 Enter your data
   C: From: Thomas Blake <[e-mail]>
   C: To: Jim Burton <FAX=[e-mail]>
   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 fax bodypart
   C:
   C: --16820115-1435684603#2306
   C: Content-Type: image/TIFF
   C: Content-Transfer-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







Allocchio                   Standards Track                    [Page 12]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


6. Conclusion

   This proposal creates a standard set of extensions for GSTN
   addresses, enriching the existing minimal specification [1]. The
   proposal is consistent with existing e-mail standards, but allows a
   more detailed GSTN address specification, including per originator
   and/or recipient specific elements. The IANA registration mechanism
   to permit the addition of new services and qualifiers using the GSTN
   addresses is also provided.

7. Security Considerations

   This document specifies a means by which GSTN addresses and more can
   be encoded into e-mail addresses. Since e-mail routing is determined
   by Domain Name System (DNS) data, a successful attack to DNS could
   disseminate tampered information, which causes e-mail messages to be
   diverted via some MTA or Gateway where the security of the software
   has been compromised.

   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 [7] become more widely deployed, clients SHOULD
   employ those mechanisms to verify the authenticity and integrity of
   mail routing records.

   Some GSTN service require dialing of private codes, like Personal
   Identification Numbers, to dial a G3 fax recipient or 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. More over these codes might appear in some cases in the
   originator and/or recipient addresses on cover pages delivered via
   offramp gateways to G3 fax recipients. Senders SHOULD be provided
   methods to prevent this disclosure, like code encryption, or
   masquerading techniques: out-of-band communication of authorization
   information or use of encrypted data in special fields are the
   available non-standard techniques.










Allocchio                   Standards Track                    [Page 13]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


8. Appendix A: Collected ABNF Syntax

   In this section we provide a summary of ABNF specifications defining
   both the minimal [1] and the extended elements of pstn-address.

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

      mta-I-pstn = domain

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

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

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

      pstn-mbox =/ service-selector "=" gstn-phone
                   [ sub-addr-spec ] [post-sep post-dial]

      service-selector = 1*( DIGIT / ALPHA / "-" )

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

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

      string = PCHAR

      gstn-phone = ( global-phone / local-phone )

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

      local-phone = [ exit-code ] [ dial-number ]

      exit-code = phone-string

      dial-number = phone-string

      phone-string = 1*( DTMF / pause / tonewait / written-sep )

      DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )

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

      pause = "p"

      tonewait = "w"

      sub-addr-spec = [ isdn-sep isub-addr ]




Allocchio                   Standards Track                    [Page 14]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


      isdn-sep = "/ISUB="

      isub-addr = 1*( DIGIT )

      isub-addr =/ 1*( DIGIT / written-sep )

      post-sep =  "/POSTD="

      post-dial = phone-string

      pstn-recipient = [ recipient-name ]
                       [ 1*( recipient-qualifier ) ]

      recipient-name = "/ATTN=" pers-name

      pers-name = [ givenname "." ]
                  [ initials "." ]
                  surname

      surname = printablestring

      givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
                    "," / "-" / "/" / ":" / "=" / "?" )

      initials = 1*ALPHA

      recipient-qualifier = ( qualif-type1 / qualif-type2 )

      qualif-type2 = "/" qual2-label "=" string

      qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR"
                    "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"

      printablestring = 1*( DIGIT / ALPHA / SP /
                            "'" / "(" / ")" / "+" / "," / "-" /
                            "." / "/" / ":" / "=" / "?" )

10. Appendix B: IANA Considerations

   As the service-selector and qualif-type1 elements values are
   extensible ones, they MUST be registered with IANA.

   To register a service-selector or a qualif-type1 element, the
   registration form templates given in B.1 and B.2 MUST be used. Any
   new registration MUST fulfill the "Specification Required" criterion,
   as defined in RFC 2434, section 2 [13]:





Allocchio                   Standards Track                    [Page 15]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


      "Specification Required - Values and their meaning MUST be
       documented in an RFC or other permanent and readily available
       reference, in sufficient detail so that interoperability
       between independent implementations is possible."

   IANA MUST NOT accept registrations which are not supplemented by a
   Specification as defined above and which are not fully specified
   according to the template forms given in B.1 and B.2. In case of need
   for further consultation about accepting a new registration, IANA
   SHOULD refer to the Application Area Director to be directed to the
   appropriate "expert" individual or IETF Working Group.

   After successful registration, IANA should publish the registered new
   element in the appropriate on-line IANA WEB site, and include it into
   the updates of the "Assigned Numbers" RFC series.

   B.1: IANA Registration form template for new values of GSTN address
   service-selector

   To: [e-mail]
   Subject: Registration of new values for the GSTN address
            service-selector specifier "foo"

   service-selector name:

      foo

   Description of Use:

      foo - ("foo" is a fictional new service-selector used in this
      template as an example, it is to be replaced with the new value
      being registered. Include a short description of the use of the
      new value here. This MUST include reference to Standard Track RFCs
      and eventually to other Standard Bodies documents for the complete
      description;  the use of the value must be defined completely
      enough for independent implementation).

   Security Considerations:

      (Any additional security considerations that may be introduced by
      use of the new service-selector parameter should be defined here
      or in the reference Standards Track RFCs)

   Person & email address to contact for further information:

      (fill in contact information)





Allocchio                   Standards Track                    [Page 16]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


   INFORMATION TO THE SUBMITTER:

   The accepted registrations will be listed in the "Assigned Numbers"
   series of RFCs.  The information in the registration form is freely
   distributable.

   B.2: IANA Registration form template for new values of GSTN
   address qualif-type1 keyword and value

   To: [e-mail]
   Subject: Registration of new values for the GSTN address
            qualif-type1 element "bar"

   qualif-type1 "keyword" name:

      bar

   qualif-type1 "value" ABNF definition:

      abnf - ("abnf" MUST define the ABNF form of the qualif-type1 value.
      The ABNF specification MUST be self-contained, using as basic
      elements the tokens given in specification [4]. To avoid any
      duplication (when appropriate), it MUST also use as building
      non-basic tokens any already registered non-basic token from other
      qualif-type1 elements, i.e. it MUST use the same non-basic token
      name and then repeat its identical ABNF definition from basic
      tokens; see appendix E for examples).

   Description of Use:

      bar - ("bar" is a fictional description for a new qualif-type1
      element used in this template as an example. It is to be replaced
      by the real description of qualif-type1 element being registered.
      Include a short description of the use of the new qualif-type1
      here. This MUST include reference to Standards Track RFCs and
      eventually to other Standard Bodies documents for the complete
      description; the use of the value MUST be defined completely
      enough for independent implementation.)

   Use Restriction:

      (If the new qualif-type1 elements is meaningful only for a
      specific set of service-element, you MUST specify here the list of
      allowed service-element types. If there is no restriction, then
      specify the keyword "none")






Allocchio                   Standards Track                    [Page 17]

RFC 2846       GSTN Address Extensions in E-mail Services      June 2000


   Security Considerations:

      (Any additional security considerations that may be introduced by
      use of the new service-selector parameter should be defined here
      or in the reference Standards Track RFCs)

   Person & email address to contact for further information:

      (fill in contact information)

   INFORMATION TO THE SUBMITTER:

   The accepted registrations will be listed in the "Assigned Numbers"
   series of RFCs.  The information in the registration form is freely
   distributable.

11. Appendix C: IANA Registration form for new value of GSTN
    address service-selector "FAX"

   To: [e-mail]
   Subject: Registration of new values for the GSTN address
            service-selector specifier "FAX"

   service-selector name: