Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
RFC 4485
| Document | Type | RFC - Informational (May 2006; No errata) | |
|---|---|---|---|
| Authors | Henning Schulzrinne , Jonathan Rosenberg | ||
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4485 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Allison Mankin | ||
| Send notices to | <rohan@ekabal.com> | ||
Network Working Group J. Rosenberg
Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
Guidelines for Authors of Extensions to
the Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) is a flexible yet simple tool
for establishing interactive communications sessions across the
Internet. Part of this flexibility is the ease with which it can be
extended. In order to facilitate effective and interoperable
extensions to SIP, some guidelines need to be followed when
developing SIP extensions. This document outlines a set of such
guidelines for authors of SIP extensions.
Rosenberg & Schulzrinne Informational [Page 1]
RFC 4485 SIP Guidelines May 2006
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP's Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
1. Introduction
The Session Initiation Protocol (SIP) [2] is a flexible yet simple
tool for establishing interactive communications sessions across the
Internet. Part of this flexibility is the ease with which it can be
extended (with new methods, new header fields, new body types, and
new parameters), and there have been countless proposals that have
been made to do just that. An IETF process has been put into place
that defines how extensions are to be made to the SIP protocol [10].
That process is designed to ensure that extensions are made that 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, [10] does not provide the technical guidelines needed
to assist that process. This specification helps to meet that need.
This specification first provides a set of guidelines to help decide
whether a certain piece of functionality is appropriately done in
SIP. Assuming the functionality is appropriate, it then points out
Rosenberg & Schulzrinne Informational [Page 2]
RFC 4485 SIP Guidelines May 2006
issues that extensions should deal with from within their
specification. Finally, it discusses common interactions with
existing SIP features that often cause difficulties in extensions.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
Show full document text