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