7. References

   [1]  Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [2]  Handley, M. and  V. Jacobsen, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [3]  Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

   [5]  The Unicode Consortium, "The Unicode Standard -- Version 2.0",
        Addison-Wesley, 1996.

   [6]  ITU-T Study Group 2, "E.164 - The International Public Network
        Numbering Plan", ITU-T, June 1997.

   [7]  Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F.,
        DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K.
        Vishwanathan "Toward the PSTN/Internet Inter-Networking--Pre-
        PINT Implementations", RFC 2458, November 1998.

   [8]  ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN
        User Part of SS No7" ITU-T, August 1994.

   [9]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [10] Crocker, D., "Standard for the format of ARPA Internet text
        messages", STD 11, RFC 822, August 1982.

   [11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane
        Architecture", ITU-T, February 1994.

   [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [13] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and CRL Profile", RFC
        2459, January 1999.

   [15] Crocker, D. and P. Overall, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [16] Mills, D., "Network Time Protocol (version 3) specification and
        implementation", RFC 1305, March 1992.

   [17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

   [18] Mockapetris, P., "Domain Names - Implementation and
        Specification", STD 13, RFC 1035, November 1987.

   [19] Levinson, E., "The MIME Multipart/Related Content-type" RFC
        2387, August 1998.

8. Acknowledgements

   The authors wish to thank the members of the PINT working group for
   comments that were helpful to the preparation of this specification.
   Ian Elz's comments were extremely useful to our understanding of
   internal PSTN operations. The SUBSCRIBE and NOTIFY requests were
   first suggested by Henning Schulzrinne and Jonathan Rosenberg. The
   suggestion to use an audio port of 0 to express that the phone is "on
   hold" (i.e. not receiving voice) is due to Ray Zibman. Finally,
   thanks to Bernie Hoeneisen for his close proofreading.

Appendix A: Collected ABNF for PINT Extensions

;; --(ABNF is specified in RFC 2234 [15])

;; --Variations on SDP definitions

connection-field    = ["c=" nettype space addrtype space
                        connection-address CRLF]
; -- this is the original definition from SDP, included for completeness
; -- the following are PINT interpretations and modifications

nettype = ("IN"/"TN")
; -- redefined as a superset of the SDP definition

addrtype = (INAddrType / TNAddrType)
; -- redefined as a superset of the SDP definition

INAddrType = ("IP4"/"IP6")
; -- this non-terminal added to hold original SDP address types

TNAddrType = ("RFC2543"/OtherAddrType)

OtherAddrType = (<X-Token>)
; -- X-token is as defined in RFC2045

addr = (<FQDN> / <unicast-address> / TNAddr)
; -- redefined as a superset of the original SDP definition
; -- FQDN and unicast address as specified in SDP

TNAddr = (RFC2543Addr/OtherAddr)
; -- TNAddr defined only in context of nettype == "TN"

RFC2543Addr = (INPAddr/LDPAddr)

INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP

LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)

OtherAddr = 1*<uric>
; -- OtherAdd defined in the context of OtherAddrType
; -- uric is as defined in RFC2396

media-field = "m=" media <space> port <space> proto
                   1*(<space> fmt) <CRLF>
; -- NOTE redefined as subset/relaxation of original SDP definition
; -- space and CRLF as defined in SDP

media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are
; --  used in PINT 1.0

port = ("0" / "1")
; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold")
; -- (1 means there is media)

proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition

INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP
TNProto = ("voice"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN"

fmt = (<subtype> / "-")
; -- NOTE redefined as a subset of the original SDP definition
; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type
held
; --  in associated media sub-field or the special value "-".

attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP

attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP

PINT-attribute = (clir-attribute / q763-nature-attribute /
                   q763plan-attribute / q763-INN-attribute /
                   phone-context-attribute / tsp-attribute /
                   pint-fmtp-attribute / strict-attribute)

clir-attribute = clir-tag ":" ("true" / "false")

clir-tag = "clir"

q763-nature-attribute = Q763-nature-tag ":" q763-natures

q763-nature-tag = "Q763-nature"

q763-natures = ("1" / "2" / "3" / "4")

q763-plan-attribute = Q763-plan-tag ":" q763-plans

q763-plan-tag = "Q763-plan"

q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text

q763-INN-attribute = Q763-INN-tag ":" q763-INNs

q763-INN-tag = "Q763-INN"

q763-INNs = ("0" / "1")

phone-context-attribute = phone-context-tag ":" phone-context-ident

phone-context-tag = "phone-context"

phone-context-ident = network-prefix / private-prefix

network-prefix = intl-network-prefix / local-network-prefix

intl-network-prefix = "+" 1*<DIGIT>

local-network-prefix = 1*<DIGIT>

private-prefix = 1*excldigandplus 0*<uric>

excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
tsp-attribute = tsp-tag "=" provider-domainname

tsp-tag = "tsp"

provider-domainname = <domain>
; -- domain is defined in RFC1035

; -- NOTE the following is redefined relative to the normal use in SDP
pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution
                      *(<space> resolution)
                      (<space> ";" 1(<attribute>) *(<space>
<attribute>))
; -- subtype as defined in RFC2046.
; -- NOTE that this value MUST match a fmt on the ultimately preceeding
; --  media-field
; -- attribute is as defined in SDP

resolution = (uri-ref / opaque-ref / sub-part-ref)

uri-ref = uri-tag ":" <URI-Reference>

; -- URI-Reference defined in RFC2396

uritag = "uri"

opaque-ref = opr-tag ":" 0*<uric>

opr-tag = "opr"

sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822

spr-tag = "spr"

strict-attribute = "require:" att-tag-list

att-tag-list = 1(PINT-att-tag-list / <att-field> /
                    pint-fmtp-tag-list)
                  *(","
                    (PINT-att-tag-list / <att-field> /
                      pint-fmtp-tag-list)
                   )
; -- att-field as defined in SDP

PINT-att-tag-list = (phone-context-tag / clir-tag /
                       q763-nature-tag / q763-plan-tag /
                       q763-INN-tag)

pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)

;; --Variations on SIP definitions

clir-parameter = clir-tag "=" ("true" / "false")

q763-nature-parameter = Q763-nature-tag "=" Q763-natures

q763plan-parameter = Q763-plan-tag "=" q763plans

q763-INN-parameter = Q763-INN-tag "=" q763-INNs

tsp-parameter = tsp-tag "=" provider-domainname

phone-context-parameter = phone-context-tag "=" phone-context-ident

SIP-param = ( <transport-param> / <user-param> / <method-param> /
                <ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP

PINT-param = ( clir-parameter / q763-nature-parameter /

                q763plan-parameter / q763-INN-parameter/
                tsp-parameter / phone-context-parameter )

URL-parameter = (SIP-param / PINT-param)
; -- redefined SIP's URL-parameter to include ones defined in PINT

Require-header = "require:" 1(required-extensions)
                             *("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30)

required-extensions = ("org.ietf.sip.subscribe" /
                       "org.ietf.sdp.require")

Appendix B: IANA Considerations

   There are three kinds of identifier used in PINT extensions that
   SHOULD be registered with IANA, if a new value is specified. These
   are:

   *  Media Format sub-types, as described in section 3.4.2 of this
      document.
   *  Private Attributes as mentioned in section 3.4.3
   *  Private Phone Context values, as described in section 3.4.3.1.

   It should be noted that private Address Types (in section 3.4.1) have
   been explicitly excluded from this process, as they must be in the
   form of an X-Token.

B.1. Media Format Sub-types

   Taking these in turn, the media format sub-types are used within the
   PINT extensions to SDP to specify the attribute line that holds the
   data source definitions. In normal use, the values in this field are
   sub-types of MIME discrete types[4]. If a value other than an IANA-
   registered sub-type is to be used, then it should either be an X-
   Token (i.e. start with "X-") or it should be registered with IANA. if
   the intention is to describe a new MIME sub-type, then the procedures
   specified in RFC 2048 should be used. It is ASSUMED that any new MIME
   sub-type would follow the syntactic rules for interpretation of
   associated PINT fmtp lines defined in this document.

   Note that, in keeping with the SDP description, such registrations
   SHOULD include the "proto" field values within which they are
   defined; however, it is appropriate to specify only that they can be
   used with "all values of TNProto".

   Conversely, if the intent is to define a new way of including data
   source definitions within PINT, then it will be necessary to specify,
   in the documentation supporting any such new "PINT Media Format Sub-
   type" registration, the syntax of the associated "fmtp" attribute
   line, as the identifier serves to indicate the interpretation that
   should be made of format specific attribute lines "tagged" with such
   a sub-type.

   If the fmtp interpretation follows the PINT default, then it is
   adequate to mention this in the defining document rather than
   repeating the syntax definition given here (although, in this case,
   it is unclear why such a new registration would be required). As
   before, the Media Format sub-type SHOULD specify the values of
   "proto" field within which it is defined, but this can be "all values
   of TNProto".

B.2. Private Attributes

   Any proprietary attribute lines that are added may be registered with
   IANA using the procedures mentioned in [2]; the mechanism is the same
   as that used in SDP. If the attribute is defined for use only within
   PINT, then it may be appropriate to mention this in the supporting
   documentation. Note that, in the PINT 1.0 specification covered here,
   there is no mechanism to add such freshly registered attribute lines
   to a "require:" clause.

B.3. Private phone-contexts

   Within the session description used for PINT requests, a phone-
   context attribute may be used to specify the prefix or context within
   which an associated telephone-number (in a connection line) should be
   interpreted.

   For "public" phone contexts the prefix to be used MUST start with
   either a DIGIT or a "+". Private phone contexts may be registered
   with IANA that do NOT start with either of these characters. Such a
   prefix may be useful to identify a private network, potentially with
   an associated numeric ID (see example 4 in section 3.4.3.1). In the
   example, the prefix acts as the context for X-acme.com's private
   network numbering plan.

   It is recommended that any private context to be registered have the
   general form of a token including a domain name, optionally followed
   by a digit string or other token. The appropriate form of the initial
   token name space will be similar to that used for private or vendor
   registrations for sub-types (e.g. vnd.acme.com). However, note that
   the registration will be used to specify a customer's private network
   numbering plan format rather than being used generally for all of

   their equipment vendor's customer's; thus, fbi.gov would be
   appropriate, but lucent.com would not (unless the private network
   were to be that used by Lucent internally).

   In addition, the supporting documentation MUST either declare that
   there is no associated token, or define the syntax by which that
   token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the
   registration describes a format, not a value range; it is sufficient
   that the private context can be parsed, without the value being
   interpreted.

   In detail, the registration request SHOULD include:

   *  Kind of registration (i.e. private phone-context attribute to be
      used within the service description of PINT service requests)
   *  Contact details for the person responsible for the registration
      request (name, organisation, e-mail address, public telephone
      number)
   *  Private Prefix initial token name (e.g. vnd.fbi.gov)
   *  syntax for private context (e.g. "vnd.fbi.gov" <space> 1*DIGIT, or
      "vnd.gtn.gov.uk")
   *  Description of use (e.g. "This phone context declares an
      associated telephone number to be within the 'government
      telecommunications network'; the number is in an internal or
      private number plan form)
   *  Network Type and Address Type with which this private context is
      associated; If the "normal" telephone types (as specified in this
      document) are used, then the values would be shown as:
      "nettype=TN" , addrtype="RFC2543Addr". If, however, this context
      were to be used with another address type, then a reference to
      that address type name and the syntax of that address value would
      be required.

   In short, this context is the telephone equivalent of a "Net 10"
   address space behind a NAT, and the initial name (and contact
   information) shows the context within which that address is valid. It
   also specifies the format for the network and address types (and
   address value syntax) with which this context is associated.

   Of course, IANA may refer the requested registration to the IESG or
   an appropriate IETF working group for review, and may require
   revisions to be made before the registration is accepted.

Authors' Addresses

   Scott Petrack
   MetaTel, Inc.
   45 Rumford Ave.
   Waltham MA 02453-3844

   Phone: +1 (781)-891-9000
   EMail: scott.petrack@metatel.com


   Lawrence Conroy
   Siemens Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey, Hampshire
   U.K.    SO51 0ZN

   Phone: +44 (1794) 833666
   EMail: lwc@roke.co.uk

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.