Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
RFC 4485

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 09

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