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] andShow full document text