draft-ietf-sip-guidelines-02.txt   draft-ietf-sip-guidelines-03.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,H.Schulzrinne Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-guidelines-02.txt dynamicsoft,Columbia U. draft-ietf-sip-guidelines-03.txt dynamicsoft,Columbia U.
March 5, 2001 November 17, 2001
Expires: September 2001 Expires: May 2002
Guidelines for Authors of SIP Extensions Guidelines for Authors of SIP Extensions
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress. material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Session Initiation Protocol (SIP) is a flexible, yet simple tool The Session Initiation Protocol (SIP) is a flexible, yet simple tool
for establishing interactive connections across the Internet. Part of for establishing interactive connections across the Internet. Part of
this flexibility is the ease with which it can be extended. In order this flexibility is the ease with which it can be extended. In order
to facilitate effective and interoperable extensions to SIP, some to facilitate effective and interoperable extensions to SIP, some
guidelines need to be followed when developing SIP extensions. This guidelines need to be followed when developing SIP extensions. This
document outlines a set of such guidelines for authors of SIP document outlines a set of such guidelines for authors of SIP
skipping to change at page 2, line 10 skipping to change at page 2, line 10
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP guidelines indicate requirement levels for compliant SIP guidelines
implementations. implementations.
2 Introduction 2 Introduction
The Session Initiation Protocol (SIP) [2] is a flexible, yet simple The Session Initiation Protocol (SIP) [2] is a flexible, yet simple
tool for establishing interactive connections across the Internet. tool for establishing interactive connections across the Internet.
Part of this flexibility is the ease with which it can be extended. Part of this flexibility is the ease with which it can be extended
SIP can be extended in numerous ways. New methods, headers, body (with new methods, new headers, new body types, and new parameters),
types and parameters for existing headers can be defined. This and there have been countless proposals that have been made to do
flexibility also means that caution should be exercised when defining just that. An IETF process has been put into place which defines how
extensions, in order to ensure interoperability. extensions are to be made to the SIP protocol [3]. That process is
designed to ensure that extensions are made which are appropriate for
SIP (as opposed to being done in some other protocol), that these
extensions fit within the model and framework provided by SIP, and
are consistent with its operation, and that these extensions solve
problems generically rather than for a specific use case. However,
[3] does not provide the technical guidelines needed to assist that
process. This draft helps to meet that need.
In order to facilitate interoperability, this document serves as a This draft first provides a set of guidelines to help decide whether
set of guidelines for authors of SIP extensions. It points out issues a certain piece of functionality is appropriately done in SIP.
to consider when deciding whether a SIP extension is the right answer Assuming the functionality is appropriate, it then points out issues
for a specific problem. It then points out issues which extensions which extensions should deal with from within their specification.
should deal with from within their specification. Finally, it Finally, it discusses common interactions with existing SIP features
discusses common interactions with existing SIP features which often which often cause difficulties in extensions.
cause difficulties in extensions.
3 Should I define a SIP Extension? 3 Should I define a SIP Extension?
The first question to be addressed when defining a SIP extension is: The first question to be addressed when defining a SIP extension is:
is a SIP extension the best solution to my problem? SIP has been is a SIP extension the best solution to my problem? SIP has been
proposed as a solution for numerous problems, including mobility, proposed as a solution for numerous problems, including mobility,
configuration and management, QoS control, call control, caller configuration and management, QoS control, call control, caller
preferences, device control, third party call control, and MPLS path preferences, device control, third party call control, and MPLS path
setup, to name a few. Clearly, not every problem can be solved by a setup, to name a few. Clearly, not every problem can be solved by a
SIP extension. More importantly, some problems that could be solved SIP extension. More importantly, some problems that could be solved
skipping to change at page 2, line 46 skipping to change at page 3, line 4
appropriate solution to their problem, we present two broad criteria. appropriate solution to their problem, we present two broad criteria.
First, the problem SHOULD fit into the general purvey of SIPs First, the problem SHOULD fit into the general purvey of SIPs
solution space. Secondly, the solution MUST conform to the general solution space. Secondly, the solution MUST conform to the general
SIP architectural model. SIP architectural model.
While the first criteria might seem obvious, we have observed that While the first criteria might seem obvious, we have observed that
numerous extensions to SIP have been proposed because some function numerous extensions to SIP have been proposed because some function
is needed in a device which also speaks SIP. The argument is is needed in a device which also speaks SIP. The argument is
generally given that "I'd rather implement one protocol than many". generally given that "I'd rather implement one protocol than many".
As an example, user agents, like all other IP hosts, need some way to As an example, user agents, like all other IP hosts, need some way to
obtain their IP address. This is generally done through DHCP [3]. obtain their IP address. This is generally done through DHCP [4].
SIPs multicast registration mechanisms might supply an alternate way SIPs multicast registration mechanisms might supply an alternate way
to obtain an IP address. This would eliminate the need for DHCP in to obtain an IP address. This would eliminate the need for DHCP in
clients. However, we do not believe such extensions are appropriate. clients. However, we do not believe such extensions are appropriate.
We believe that protocols should be defined to provide specific, We believe that protocols should be defined to provide specific,
narrow functions, rather than being defined based on all narrow functions, rather than being defined based on all
communications requirements between a pair of devices. The latter communications requirements between a pair of devices. The latter
approach to protocol design yields modular protocols with broad approach to protocol design yields modular protocols with broad
application. It also facilitates extensibility and growth; single application. It also facilitates extensibility and growth; single
protocols can be removed and changed without affecting the entire protocols can be removed and changed without affecting the entire
system. We observe that this approach to protocol engineering mirrors system. We observe that this approach to protocol engineering mirrors
skipping to change at page 7, line 26 skipping to change at page 7, line 31
4 Issues to be Addressed 4 Issues to be Addressed
Given an extension has met the litmus tests in the previous section, Given an extension has met the litmus tests in the previous section,
there are several issues that all extensions should take into there are several issues that all extensions should take into
consideration. consideration.
4.1 Backwards Compatibility 4.1 Backwards Compatibility
One of the most important issues to consider is whether the new One of the most important issues to consider is whether the new
extension is backwards compatible with baseline SIP. This is tightly extension is backwards compatible with baseline SIP. This is tightly
coupled with how the Require, Proxy-Require, and Supported [4] coupled with how the Require, Proxy-Require, and Supported [5]
headers are used. headers are used.
If an extension consists of new headers inserted by a user agent in a If an extension consists of new headers inserted by a user agent in a
request with an existing method, and the request cannot be processed request with an existing method, and the request cannot be processed
reasonably by a proxy and/or user agent without understanding the reasonably by a proxy and/or user agent without understanding the
headers, the extension MUST mandate the usage of the Require and/or headers, the extension MUST mandate the usage of the Require and/or
Proxy-Require headers in the request. These extensions are not Proxy-Require headers in the request. These extensions are not
backwards compatible with SIP. The result of mandating usage of these backwards compatible with SIP. The result of mandating usage of these
headers means that requests cannot be serviced unless the entities headers means that requests cannot be serviced unless the entities
being communicated with also understand the extension. If some entity being communicated with also understand the extension. If some entity
skipping to change at page 8, line 52 skipping to change at page 9, line 7
insert headers into a response. For some extensions, if the UAC or insert headers into a response. For some extensions, if the UAC or
UAS does not understand these headers, the message can still be UAS does not understand these headers, the message can still be
processed correctly. These extensions are completely backwards processed correctly. These extensions are completely backwards
compatible. compatible.
Most other extensions of this type require that the server only Most other extensions of this type require that the server only
insert the header if it is sure the client understands it. In this insert the header if it is sure the client understands it. In this
case, these extensions will need to make use of the Supported request case, these extensions will need to make use of the Supported request
header mechanism. This mechanism allows a server to determine if the header mechanism. This mechanism allows a server to determine if the
client can understand some extension, so that it can apply the client can understand some extension, so that it can apply the
extension to the response [4]. By their nature, these extensions may extension to the response [5]. By their nature, these extensions may
not always be able to be applied to every response. not always be able to be applied to every response.
If an extension requires a proxy to insert a header into a request, If an extension requires a proxy to insert a header into a request,
and this header needs to be understood by both UAC and UAS to be and this header needs to be understood by both UAC and UAS to be
executed correctly, a combination of the Require and the Supported executed correctly, a combination of the Require and the Supported
mechanism will need to be used. The proxy can insert a Require header mechanism will need to be used. The proxy can insert a Require header
into the request, given the Supported header is present. An example into the request, given the Supported header is present. An example
of such an extension is the SIP Session Timer [5]. of such an extension is the SIP Session Timer [6].
Yet another type of extension is that which defines new body types to Yet another type of extension is that which defines new body types to
be carried in SIP messages. According to the SIP specification, be carried in SIP messages. According to the SIP specification,
bodies must be understood in order to process a request. As such, the bodies must be understood in order to process a request. As such, the
interoperability issues are similar to new methods. However, a new interoperability issues are similar to new methods. However, a new
header, Content-Disposition, has been defined that allows a client or header, Content-Disposition, has been defined that allows a client or
server to indicate that the message body is optional [6]. Usage of server to indicate that the message body is optional [7]. Usage of
optional bodies, as opposed to mandatory ones, is RECOMMENDED optional bodies, as opposed to mandatory ones, is RECOMMENDED
wherever possible. wherever possible.
When a body must be understood to properly process a request or When a body must be understood to properly process a request or
response, it is preferred that the sending entity know ahead of time response, it is preferred that the sending entity know ahead of time
whether the new body is understood by the recipient. For requests whether the new body is understood by the recipient. For requests
that are the first in a sequence of exchanges between user agents that are the first in a sequence of exchanges between user agents
(such as INVITE), inclusion of Accept in the request and its success (such as INVITE), inclusion of Accept in the request and its success
responses is RECOMMENDED. This will allow both parties to determine responses is RECOMMENDED. This will allow both parties to determine
what body types are supported by their peers. Subsequent messaging what body types are supported by their peers. Subsequent messaging
skipping to change at page 10, line 26 skipping to change at page 10, line 30
always case insensitive. Header values are generally case sensitive, always case insensitive. Header values are generally case sensitive,
with the exception of domain names which MUST be case insensitive. with the exception of domain names which MUST be case insensitive.
Case sensitivity of parameters and values is a constant source of Case sensitivity of parameters and values is a constant source of
confusion. SIP extensions MUST clearly indicate the case sensitivity confusion. SIP extensions MUST clearly indicate the case sensitivity
or insensitivity of every parameter, value or field they define. In or insensitivity of every parameter, value or field they define. In
general, case sensitivity is preferred because of the reduced general, case sensitivity is preferred because of the reduced
processing requirements. processing requirements.
Extensions which contain freeform text MUST allow that text to be Extensions which contain freeform text MUST allow that text to be
UTF-8, as per the IETF policies on character set usage [7]. This UTF-8, as per the IETF policies on character set usage [8]. This
ensures that SIP remains an internationalized standard. As a general ensures that SIP remains an internationalized standard. As a general
guideline, freeform text is never needed by programs in order to guideline, freeform text is never needed by programs in order to
perform protocol processing. It is usually entered by and displayed perform protocol processing. It is usually entered by and displayed
to the user. If an extension uses a parameter which can contain UTF-8 to the user. If an extension uses a parameter which can contain UTF-8
encoded characters, and that extension requires a comparison to be encoded characters, and that extension requires a comparison to be
made of this parameter to other parameters, the comparison SHOULD be made of this parameter to other parameters, the comparison SHOULD be
case sensitive. Case insensitive comparison rules for UTF-8 text are case sensitive. Case insensitive comparison rules for UTF-8 text are
extremely complicated and are to be avoided. extremely complicated and are to be avoided.
Extensions which make use of dates and times MUST use the SIP-Date Extensions which make use of dates and times MUST use the SIP-Date
BNF defined in RFC 2543. No other date formats are allowed. BNF defined in RFC 2543. No other date formats are allowed.
Extensions which include network layer addresses SHOULD permit dotted Extensions which include network layer addresses SHOULD permit dotted
quad IPv4 addresses, IPv6 addresses in the format described in [8], quad IPv4 addresses, IPv6 addresses in the format described in [9],
and domain names. and domain names.
Extensions which have headers containing URLs SHOULD allow any URI, Extensions which have headers containing URLs SHOULD allow any URI,
not just SIP URLs. not just SIP URLs.
Headers SHOULD follow the standard formatting for SIP, defined as: Headers SHOULD follow the standard formatting for SIP, defined as:
header-name ":" # (value *( ";" parameter-name ["=" token] ) | header-name ":" # (value *( ";" parameter-name ["=" token] ) |
";" parameter-name ["=" quoted-string] )) ";" parameter-name ["=" quoted-string] ))
Developers of extensions SHOULD allow for extension parameters in Developers of extensions SHOULD allow for extension parameters in
their headers. their headers.
Headers that contain a list of URIs SHOULD follow the same syntax as Headers that contain a list of URIs SHOULD follow the same syntax as
the Contact header in SIP. Implementors are also encouraged to always the Contact header in SIP. Implementors are also encouraged to always
wrap these URI in angle brackets "<" and ">". We have found this to wrap these URI in angle brackets "<" and ">". We have found this to
be a frequently misimplemented feature. be a frequently misimplemented feature.
Beyond compact form, there is no need to define compressed versions Beyond compact form, there is no need to define compressed versions
of header values. Compression of SIP messages SHOULD be handled at of header values. Compression of SIP messages SHOULD be handled at
skipping to change at page 11, line 14 skipping to change at page 11, line 18
Developers of extensions SHOULD allow for extension parameters in Developers of extensions SHOULD allow for extension parameters in
their headers. their headers.
Headers that contain a list of URIs SHOULD follow the same syntax as Headers that contain a list of URIs SHOULD follow the same syntax as
the Contact header in SIP. Implementors are also encouraged to always the Contact header in SIP. Implementors are also encouraged to always
wrap these URI in angle brackets "<" and ">". We have found this to wrap these URI in angle brackets "<" and ">". We have found this to
be a frequently misimplemented feature. be a frequently misimplemented feature.
Beyond compact form, there is no need to define compressed versions Beyond compact form, there is no need to define compressed versions
of header values. Compression of SIP messages SHOULD be handled at of header values. Compression of SIP messages SHOULD be handled at
lower layers, for example, using IP payload compression [9] or link lower layers, for example, using IP payload compression [10] or link
layer compression. layer compression.
Syntax for headers is expressed in Augmented Backus-Naur Form. Syntax for headers is expressed in Augmented Backus-Naur Form.
Extensions MUST make use of the primitive components defined in Extensions MUST make use of the primitive components defined in
RFC2543 [2]. If the construction for a BNF element is defined in RFC2543 [2]. If the construction for a BNF element is defined in
another specification, it is RECOMMENDED that the construction be another specification, it is RECOMMENDED that the construction be
referenced rather than copied. The reference SHOULD include both the referenced rather than copied. The reference SHOULD include both the
document and section number. All BNF elements must be either defined document and section number. All BNF elements must be either defined
or referenced. or referenced.
skipping to change at page 12, line 15 skipping to change at page 12, line 20
4.6 Examples Section 4.6 Examples Section
Presence of sections in the extension giving examples of call flows Presence of sections in the extension giving examples of call flows
and message formatting is RECOMMENDED. Extensions which define and message formatting is RECOMMENDED. Extensions which define
substantial new syntax SHOULD include examples of messages containing substantial new syntax SHOULD include examples of messages containing
that syntax. Examples of message flows should be given to cover that syntax. Examples of message flows should be given to cover
common cases and at least one failure or unusual case. common cases and at least one failure or unusual case.
For an example of how to construct a good examples section, see the For an example of how to construct a good examples section, see the
message flows and message formatting defined in the Call Flows message flows and message formatting defined in the Call Flows
Example specification [10]. Note that complete messages SHOULD be Example specification [11]. Note that complete messages SHOULD be
used. Be careful to include tags, Via headers, Content-Lengths, used. Be careful to include tags, Via headers, Content-Lengths,
Record-Route and Route headers. Record-Route and Route headers.
4.7 Overview Section 4.7 Overview Section
Too often, extension documents dive into detailed syntax and Too often, extension documents dive into detailed syntax and
semantics without giving a general overview of operation. This makes semantics without giving a general overview of operation. This makes
understanding of the extension harder. It is RECOMMENDED that understanding of the extension harder. It is RECOMMENDED that
extensions have a protocol overview section which discusses the basic extensions have a protocol overview section which discusses the basic
operation of the extension. Basic operation usually consists of the operation of the extension. Basic operation usually consists of the
skipping to change at page 14, line 37 skipping to change at page 14, line 42
proxies are unable to retransmit messages and cannot proxies are unable to retransmit messages and cannot
execute certain services. Extensions which depend on some execute certain services. Extensions which depend on some
kind of proxy processing SHOULD consider how stateless kind of proxy processing SHOULD consider how stateless
proxies affect that processing. proxies affect that processing.
6 Security Considerations 6 Security Considerations
The nature of this document is such that it does not introduce any The nature of this document is such that it does not introduce any
new security considerations. new security considerations.
7 Changes since -01 7 Changes since -02
o Return to rfc2119 strength wording. o Rewrote introduction to discuss draft-tsvarea-sipchange
8 Authors Addresses 8 Changes since -01
o Return to rfc2119 strength wording.
9 Authors Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu email: schulzrinne@cs.columbia.edu
9 Bibliography 10 Bibliography
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997. Mar. 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[3] R. Droms, "Dynamic host configuration protocol," Request for [3] S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, and D. Willis,
"Sip change process," Internet Draft, Internet Engineering Task
Force, Nov. 2001. Work in progress.
[4] R. Droms, "Dynamic host configuration protocol," Request for
Comments 2131, Internet Engineering Task Force, Mar. 1997. Comments 2131, Internet Engineering Task Force, Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "The SIP supported header," [5] J. Rosenberg and H. Schulzrinne, "The SIP supported header,"
Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress. progress.
[5] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft, [6] S. Donovan and J. Rosenberg, "SIP session timer," Internet Draft,
Internet Engineering Task Force, Oct. 2000. Work in progress. Internet Engineering Task Force, Oct. 2001. Work in progress.
[6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [7] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
Session initiation protocol," Internet Draft, Internet Engineering protocol," Internet Draft, Internet Engineering Task Force, Oct.
Task Force, Aug. 2000. Work in progress. 2001. Work in progress.
[7] H. Alvestrand, "IETF policy on character sets and languages," [8] H. Alvestrand, "IETF policy on character sets and languages,"
Request for Comments 2277, Internet Engineering Task Force, Jan. Request for Comments 2277, Internet Engineering Task Force, Jan.
1998. 1998.
[8] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal [9] R. Hinden, B. Carpenter, and L. Masinter, "Format for literal
IPv6 addresses in URL's," Request for Comments 2732, Internet IPv6 addresses in URL's," Request for Comments 2732, Internet
Engineering Task Force, Dec. 1999. Engineering Task Force, Dec. 1999.
[9] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload [10] A. Shacham, R. Monsour, R. Pereira, and M. Thomas, "IP payload
compression protocol (ipcomp)," Request for Comments 2393, Internet compression protocol (ipcomp)," Request for Comments 2393, Internet
Engineering Task Force, Dec. 1998. Engineering Task Force, Dec. 1998.
[10] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. [11] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J.
Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow Rosenberg, K. Summers, and H. Schulzrinne, "SIP telephony call flow
examples," Internet Draft, Internet Engineering Task Force, July examples," Internet Draft, Internet Engineering Task Force, Apr.
2000. Work in progress. 2001. Work in progress.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/