GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2846

Network Working Group C. Allocchio Request for Comments: 2846 GARR-Italy Category: Standards Track June 2000

         GSTN Address Element Extensions in E-mail Services

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 (2000).  All Rights Reserved.

Abstract

 There are numerous applications where there is a need for interaction
 between the GSTN addressing and Internet addressing.  This memo
 defines a full syntax for one specific case, where there is a need to
 represent GSTN addresses within Internet e-mail addresses. This full
 syntax is a superset of a minimal syntax which has been defined in
 [1].

1. Introduction

 The possible elements composing a "Global Switched Telephone Network
 (GSTN) address in e-mail" (also known as the Public Switched
 Telephone Network - PSTN) can vary from a minimum number up to a
 really large and complex collection. As noted the minimal format and
 general address syntax have been defined in [1], along with the
 mechanism needed to define additional address elements. This memo
 uses this extension mechanism to complete the syntax for representing
 GSTN addresses within e-mail addresses and contains the IANA
 registrations for all newly defined elements.
 In particular, the following additional address elements shall be
 defined:
  1. the detailed definition of GSTN number formats, in order to cover

various alternative standard GSTN numbering schemes, (i.e. gstn-

    phone, sub-addr-spec and post-dial)

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

  1. the message originator and/or recipient specification (pstn-

recipient)

 GSTN addresses in e-mail MAY contain additional elements defined and
 registered in other specifications (see for example "T33S" element in
 [2]), but they MUST use definitions contained in this memo for those
 elements specified here.
 In particular, "service-selector" names and "qualif-type1" elements
 MUST be registered with IANA, and published within the "ASSIGNED
 NUMBERS" document. This provides a standard mechanism for extending
 the element sets and should avoid unnecessary duplication. IANA
 Registration form templates for the purpouse of registering new
 elements are provided in Appendix B. In addition the IANA
 consideration section of this document defines the procedures
 required to proceed with new registrations.
 A collection of forms for already defined "service-selector" and
 "qualif-type1" elements is listed in appendix C and appendix D
 respectively.
 In particular, efforts have been made to maintain compatibility with
 elements defined in existing e-mail gateway services and standard
 specifications. For example, to the extent possible, compatibility
 has been maintained with the MIXER [3] gateways specifications.

1.1 Relationship with Internet addressing other than e-mail

 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 embedding GSTN addresses into other
 addresses: for example there is some work in progress about URLs
 specification which adopts similar definitions, with slight changes
 in the global syntax due to specific URL format.

1.2 Terminology and Syntax conventions

 In this document the formal definitions are described using ABNF
 syntax, as defined into [4]. 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 [5].

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

2. GSTN extended number and pstn-mbox extended format

 In reference [1], section 2, the minimal definition of pstn-mbox
 includes the global-phone element, and further details are defined in
 [1] section 2.1.
 However other non global-phone numbering schemes are also possible.
 Thus, the minimal set syntax defined in [1] shall be extended to
 enable support for local-phone elements. Therefore, the gstn-phone
 format is defined as follows:
    gstn-phone = ( global-phone / local-phone )
 The complexity of the GSTN system includes also the optional use of
 subaddresses and post dialling sequences. As a consequence, there is
 a need to extend the definition of pstn-mbox per [1] to include
 support for both the minimal set definition and an extended syntax.
 The expanded definition of pstn-mbox is as follows:
    pstn-mbox = service-selector "=" global-phone
    pstn-mbox =/ service-selector "=" gstn-phone
                 [ sub-addr-spec ] [post-sep post-dial]
 NOTE: see section 4 in the event multiple "sub-addr-spec" elements
 per pstn-mbox need to be specified.

2.1 The local-phone syntax

 The local-phone element is intended to represent the set of possible
 cases where the global-phone numbering schema does not apply. Given
 the different and complex conventions currently being used in the
 GSTN system, the local-phone definition supports a large number of
 elements.
 The detailed syntax for local-phone elements follows:
    local-phone = [ exit-code ] [ dial-number ]
    exit-code = phone-string
                ; this will include elements such as the digit to
                ; access outside line, the long distance carrier
                ; access code, the access password to the service,
                ; etc...

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

    dial-number = phone-string
                ; this is in many cases composed of different elements
                ; such as the local phone number, the area code
                ; (if needed), the international country code
                ; (if needed), etc...
 Note:
    the "+" character is reserved for use in global-phone addresses
    per [7] and MUST NOT be used as the starting character in a
    local-phone string.
    phone-string = 1*( DTMF / pause / tonewait / written-sep )
    DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
                   ; special DTMF codes like "*", "#", "A", "B",
                   ; "C", "D" are defined in [6]
                   ; Important Note: these elements only apply for
                   ; alphabetic strings used in DTMF operations.
                   ; They are NOT applicable for the alphabetic
                   ; characters that are mapped to digits on phone
                   ; keypads in some countries.
    pause = "p"
    tonewait = "w"
 The written-sep element is defined in [1], section 2.1.
 Note:
    "pause" and "tonewait" character interpretation in local-phone
    numbers depends on the specific MTA implementation. Thus its exact
    meaning is not defined here. Both "pause" and "tonewait" are case
    insensitive.
 Important Note:
    A local-phone specification is a sequence which should be used
    only by the destination  MTA specified by mta-I-pstn (see [1],
    section 3). Per [12], other MTAs should transfer the message
    without modifying the LHS.

2.2 The sub-addr-spec element

 In GSTN service there are cases where a sub-addr-spec is required to
 specify the final destination. In particular there are ISDN
 subaddresses [7], which apply for various  services, whereas other
 subaddress types may be service specific (see the fax service T.33
 subaddress [8], [2]).

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

 Within actual telephone operations there may be cases where different
 types of subaddresses are used as part of a single complete address.
 Therefore, the sub-addr-spec syntax definition which follows defines
 the subaddress element for the context of ISDN use; the T.33
 subaddress element is defined in [2], section 2.
 The definition of sub-addr-spec is:
    sub-addr-spec = [ isdn-sep isub-addr ]
 In detail:
    isdn-sep = "/ISUB="
               ; note that "/ISUB=" is case INSENSITIVE
    isub-addr = 1*( DIGIT )
    isub-addr =/ 1*( DIGIT / written-sep )
 The IANA registration form for sub-addr-spec is given in appendix D.2

2.3 The post-sep and post-dial elements

 In some cases, after the connection with the destination GSTN device
 has been established, a further dialling sequence is required to
 access further services. A typical example is an automated menu-
 driven service using DTMF sequences. These cases may be handled using
 "post-sep" and "post-dial" elements as defined below:
    post-sep =  "/POSTD="
                ; note that "/POSTD=" is case INSENSITIVE
    post-dial = phone-string
 The IANA registration form for post-sep and post-dial are given in
 appendix D.3

3. The pstn-recipient

 There are some application where it is valuable to supplement the
 pstn-mbox element with additional details. Common examples include
 the use of originator and/or recipient names and physical addresses,
 particularly in the context of onramp and/or offramp gateways.
 The optional pstn-recipient element provides support for such
 details.

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

 As an example, when an offramp fax gateway is involved, the
 pstn-recipient element could be used to specify the intended
 recipient on a fax cover page, and the fax cover page headers could
 be qualified using the originator pstn-recipient information.
 In the interest of a compact syntax, the pstn-recipient element may
 be used to support both originator and recipient addresses. For all
 cases within the ABNF definitions to follow, the elements labelled
 with "recipient" may also be used for originator information.
 The pstn-recipient is a sequence of qualif-type1 elements as defined
 below:
    pstn-recipient = [ recipient-name ]
                     [ 1*( recipient-qualifier ) ]
 As a consequence, the extended definition of pstn-address becomes:
    pstn-address = pstn-mbox  [ qualif-type1 ]
    pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
 The definition for  qualif-type1 elements is contained in [1] section
 2.

3.1 The recipient-name

 The recipient-name specifies the personal name of the originator
 and/or recipient:
    recipient-name = "/ATTN=" pers-name
    pers-name = [ givenname "." ]
                [ initials "." ]
                surname
 The following definitions come directly from the MIXER specification
 [3]:
    surname = printablestring
    givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
                  "," / "-" / "/" / ":" / "=" / "?" )
    initials = 1*ALPHA

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

 Note:
    the "initials" element can specify the middle initial which is
    common in some countries; however it is also possible to support
    multiple initials, which may be commonly used in other countries.
    This allows the complete set of givennames initials in any
    possible combination. See examples at section 5.2
 It is essential to remember that the "pstn-address" element (in all
 its components and extensions) MUST strictly follow the "quoting
 rules" specified in the relevant e-mail standards [11], [12].
 The IANA registration form for recipient-name is given in appendix
 D.4.

3.2 The extensible recipient-qualifier

 The recipient-name is sometimes not enough to specify completely the
 originator and/or recipient. An additional set of optional elements,
 whose specific definition is in most cases application dependent, is
 thus defined:
    recipient-qualifier = ( qualif-type1 / qualif-type2 )
 The recipient-qualifier is a qualif-type1 element, and contains a
 qualif-type1 element in a recursive definition which allows an
 extensible format. The purpouse of qualif-type2 element is to permit
 additional extensibility for items which go beyond the scope of those
 defined for use with the qualif-type1 element.
 A series of qualif-type2 elements are defined below:
    qualif-type2 = "/" qual2-label "=" string
    qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR"
                  "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"
    string = PCHAR
             ; note that printable characters are %x20-7E
    printablestring = 1*( DIGIT / ALPHA / SP /
                          "'" / "(" / ")" / "+" / "," / "-" /
                          "." / "/" / ":" / "=" / "?" )
                      ; this definition comes from ITU F.401 [9]
                      ; and MIXER [3]

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

 Table 1 includes short definition of qual2-label fields:
                      Table 1 - qual2-label
 qual2-label  Description
 -----------------------------------------------------------------
   "ORG"      Organization Name for Physical Delivery (example: ACME
              Inc)
   "OFNO"     Office Number for physical delivery (example: BLD2-44)
   "OFNA"     Office Name for physical delivery (example: Sales)
    "STR"     Street address for physical delivery (example:
              45, Main Street)
   "ADDR"     Unformatted postal address for physical delivery
              (example: HWY 14, Km 94.5 - Loc. Redhill)
   "ADDU"     Unique postal name for physical delivery (example:
              ACMETELEX)
   "ADDL"     Local postal attributes for physical delivery (example:
              Entrance 3, 3rd floor, Suite 296)
    "POB"     Post Office Box for physical delivery
    "ZIP"     Postal ZIP code for physical delivery
     "CO"     Country Name for physical delivery
 -----------------------------------------------------------------
 One or a combination of some of the above elements is usually enough
 to exactly specify the originator and/or recipient of the message.
 The use of a large number of these elements could in fact create a
 very long recipient-qualifier. Thus, only the strictly needed
 elements SHOULD be used. The maximum total length of the pstn-email
 MUST in fact not exceed the limits specified in the relevant e-mail
 standards [11] [12].
 IMPORTANT NOTE: Although the meaning of the above elements is derived
 directly from similar elements available in F.401 specification [9],
 the naming convention used in this document is explicitly different.
 In this way a conflict is avoided with related X.400 addressing
 rules.  Other specification which use the extension mechanism of this
 document to define new qualif-type1 elements which overlap with F.401
 are cautioned to create new labels which are different than those
 used in F.401.

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

 The IANA registration form for these elements is given in appendix
 D.5 to D.14.

4. Multiple sub-addr-spec cases

 There are some instances in GSTN applications where multiple
 subaddresses are used: T.33 subaddresses in fax service are one of
 these cases. In e-mail practice a separate and unique e-mail address
 is always used for each recipient; as such, if multiple subaddresses
 are present, the use of multiple "pstn-email" elements [1] is
 REQUIRED.
 Implementors' note:
    The UA MAY accept multiple subaddress elements for the same
    global-phone, but it MUST generate multiple "pstn-mbox" elements
    when submitting the message to the MTA.

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. Check also the examples in
 [1] and [2] for additional information. Please note that all the
 examples are for illustration purpouses, only.

5.1 pstn-mbox examples

 A pstn-mbox address in Italy for the fax service, dialled from
 U.S.A., using local-phone, without sub-addr-spec and without
 written-sep:
    FAX=0103940226338
 A pstn-mbox address in Germany for an hypothetical XYZ service, using
 global-phone, with ISDN sub-addr-spec 1234 and written-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-spec 8745, with written-sep "-" and post-dial
 sequence p1w7005393w373
    FAX=+1-202-455-7622/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=+12023445723
 With pstn-recipient (XYZ service):
    XYZ=+3940226338/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=+12023445723@faxgw
    FAX=+39-40-226338/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=+39040226338/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:<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: Jim Burton <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 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: IANA@isi.edu
 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: IANA@isi.edu
 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: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          service-selector specifier "FAX"
 service-selector name:
    FAX
 Description of Use:
    FAX - specify that the GSTN address refers either to an
    Internet Fax device, or an onramp/offramp Fax gateway.
    For a complete description refer to RFC 2304 and RFC 2303
 Security Considerations:
    See the Security Consideration section of RFC 2304.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o Sincrotrone Trieste
    SS 14 Km 163.5 Basovizza
    I 34012 Trieste
    Italy

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

    RFC822: Claudio.Allocchio@elettra.trieste.it
    X.400:  C=it;A=garr;P=Trieste;O=Elettra;
            S=Allocchio;G=Claudio;
    Phone:  +39 040 3758523
    Fax:    +39 040 3758565

12. Appendix D: IANA Registration forms for new values of GSTN

     address qualit-type1 keyword and value
 D.1 - T33S
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "T33S"
 qualif-type1 "keyword" name:
    T33S
 qualif-type1 "value" ABNF definition:
    sub-addr = 1*( DIGIT )
 Description of Use:
    T33S is used to specify the numeric only optional fax sub-address
    element described in "ITU T.33 - Facsimile routing utilizing the
    subaddress; recommendation T.33 (July, 1996)". Further detailed
    description is available in RFC 2304.
 Use Restriction:
    The use of "T33S" is restricted to "FAX" service-selector, is it
    has no meaning outside the fax service.
 Security Considerations:
    See the Security Consideration section of RFC 2304.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o Sincrotrone Trieste
    SS 14 Km 163.5 Basovizza
    I 34012 Trieste
    Italy

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

    RFC822: Claudio.Allocchio@elettra.trieste.it
    X.400:  C=it;A=garr;P=Trieste;O=Elettra;
            S=Allocchio;G=Claudio;
    Phone:  +39 040 3758523
    Fax:    +39 040 3758565
 D.2 - ISUB
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ISUB"
 qualif-type1 "keyword" name:
    ISUB
 qualif-type1 "value" ABNF definition:
    isub-addr = 1*( DIGIT )
    isub-addr =/ 1*( DIGIT / written-sep )
    written-sep = ( "-" / "." )
 Description of Use:
    "ISUB" is used to specify the optional ISDN sub-address elements used
    in ISDN service to reach specific objects on the ISDN service. It can
    eventually embed written separator elements for the only scope to
    enhance human readability. See RFC 2846 for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.3 - POSTD
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "POSTD"
 qualif-type1 "keyword" name:
    POSTD
 qualif-type1 "value" ABNF definition:
    phone-string = 1*( DTMF / pause / tonewait / written-sep )
    DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
    pause = "p"
    tonewait = "w"
    written-sep = ( "-" / "." )
 Description of Use:
    POSTD is the optional further dialling sequence needed to access
    additional services (for example a menu' driven interface)
    available after the service site has been accessed using
    gstn-phone. See RFC 2846 for further details.

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

 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.4 - ATTN
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ATTN"
 qualif-type1 "keyword" name:
    ATTN
 qualif-type1 "value" ABNF definition:
    pers-name = [ givenname "." ] [ initials "." ] surname
    surname = printablestring
    givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
                  "," / "-" / "/" / ":" / "=" / "?" )
    initials = 1*ALPHA
    printablestring = 1*( DIGIT / ALPHA / SP /
                          "'" / "(" / ")" / "+" / "," / "-" /
                          "." / "/" / ":" / "=" / "?" )

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

 Description of Use:
    To specify the personal name of the individual intended as the
    originator or the recipient of the message. See RFC 2846 for
    further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.5 - ORG
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ORG"
 qualif-type1 "keyword" name:
    ORG
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Organization Name (example: ACME Inc.) See RFC 2846
    for further details.

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

 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.6 - OFNO
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "OFNO"
 qualif-type1 "keyword" name:
    OFNO
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Office Number (example: BLD2-44) See RFC 2846
    for further details.
 Use Restriction:
    none.

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

 Security Considerations:
    See the Security Consideration section of RFC 2846.
 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.7 - OFNA
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "OFNA"
 qualif-type1 "keyword" name:
    OFNA
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Office Name (example: Sales) See RFC 2846
    for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.8 - STR
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "STR"
 qualif-type1 "keyword" name:
    STR
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Street Address (example: 45, Main Street).
    See RFC 2846 for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.9 - ADDR
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ADDR"
 qualif-type1 "keyword" name:
    ADDR
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Unformatted Postal Address (example: HWY 14,
    Km 94.5 - Loc. Redhill). See RFC 2846 for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.10 - ADDU
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ADDU"
 qualif-type1 "keyword" name:
    ADDU
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Unique Postal Name (example: ACMETELEX). See
    RFC 2846 for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.11 - ADDL
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ADDL"
 qualif-type1 "keyword" name:
    ADDL
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Local Postal Attributes (example: Entrance 3,
    3rd floor, Suite 296). See RFC 2846 for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.12 - POB
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "POB"
 qualif-type1 "keyword" name:
    POB
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Post Office Box (example: CP 1374). See RFC 2846
    for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.13 - ZIP
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "ZIP"
 qualif-type1 "keyword" name:
    ZIP
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify Postal ZIP code (example: I 34012). See RFC 2846
    for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565
 D.14 - CO
 To: IANA@isi.edu
 Subject: Registration of new values for the GSTN address
          qualif-type1 element "CO"
 qualif-type1 "keyword" name:
    CO
 qualif-type1 "value" ABNF definition:
    string = PCHAR
 Description of Use:
    To specify the Country Name (example: Belgium) See RFC 2846
    for further details.
 Use Restriction:
    none.
 Security Considerations:
    See the Security Consideration section of RFC 2846.

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

 Person & email address to contact for further information:
    Claudio Allocchio
    INFN-GARR
    c/o 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 040 3758523
    Fax:    +39 040 3758565

13. Author's Address

 Claudio Allocchio
 INFN-GARR
 c/o 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 040 3758523
 Fax:    +39 040 3758565

14. References

 [1]  Allocchio, C., "Minimal PSTN address format in Internet Mail",
      RFC 2303, March 1998.
 [2]  Allocchio, C., "Minimal FAX address format in Internet Mail",
      RFC 2304, March 1998.
 [3]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
      between X.400 and RFC 822/MIME", RFC 2156, January 1998.
 [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
      Specifications", RFC 2234, November 1997.
 [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

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

 [6]  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)
 [7]  ITU E.164 - The International Public Telecommunication Numbering
      Plan E.164/I.331 (May 1997)
 [8]  ITU T.33 - Facsimile routing utilizing the subaddress;
      recommendation T.33 (July, 1996)
 [9]  ITU F.401 - Message Handling Services: Naming and Addressing for
      Public Massage Handling Service; recommendation F.401 (August
      1992)
 [10] ITU F.423 - Message Handling Services: Intercommunication
      Between the Interpersonal Messaging Service and the Telefax
      Service; recommendation F.423 (August 1992)
 [11] Crocker, D., "Standard for the format of ARPA Internet text
      messages", STD 11, RFC 822, August 1982.
 [12] Braden, R., "Requirements for Internet hosts - application and
      support", STD 3, RFC 1123, October 1989.
 [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

15. Full Copyright Statement

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Allocchio Standards Track [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2846.txt · Last modified: 2000/06/06 20:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki