The Session Initiation Protocol (SIP) Pending Additions Event Package
RFC 5362

 
Document Type RFC - Proposed Standard (October 2008; No errata)
Last updated 2013-03-02
Replaces draft-camarillo-sipping-pending-additions
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5362 (Proposed Standard)
Telechat date
Responsible AD Jon Peterson
Send notices to sipping-chairs@ietf.org
Network Working Group                                       G. Camarillo
Request for Comments: 5362                                      Ericsson
Category: Standards Track                                   October 2008

 The Session Initiation Protocol (SIP) Pending Additions Event Package

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines the SIP Pending Additions event package.  This
   event package is used by SIP relays to inform user agents about the
   consent-related status of the entries to be added to a resource list.

Camarillo                   Standards Track                     [Page 1]
RFC 5362            Pending Additions Event Package         October 2008

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Overview of Operation ...........................................3
   4. XML Schema Definition ...........................................3
   5. Pending Additions Event Package Definition ......................5
      5.1. Event Package Name .........................................5
           5.1.1. Event Package Parameters ............................5
           5.1.2. SUBSCRIBE Bodies ....................................5
           5.1.3. Subscription Duration ...............................5
           5.1.4. NOTIFY Bodies .......................................5
           5.1.5. Notifier Processing of SUBSCRIBE Requests ...........6
           5.1.6. Notifier Generation of NOTIFY Requests ..............6
           5.1.7. Subscriber Processing of NOTIFY Requests ............6
           5.1.8. Handling of Forked Requests .........................7
           5.1.9. Rate of Notifications ...............................7
           5.1.10. State Agents .......................................7
           5.1.11. Example ............................................7
   6. Partial Notifications ...........................................8
      6.1. Generation of Partial Notifications ........................8
      6.2. Processing of Partial Notifications ........................9
      6.3. XML Schema for Partial Notifications .......................9
      6.4. Examples ..................................................11
   7. IANA Considerations ............................................11
      7.1. SIP Event Package Registration ............................11
      7.2. URN Sub-Namespace Registration: consent-status ............12
      7.3. XML Schema Registration: consent-status ...................12
      7.4. XML Schema Registration: resource-lists ...................13
      7.5. MIME Type Registration:
           application/resource-lists-diff+xml .......................13
   8. Security Considerations ........................................14
   9. Acknowledgments ................................................14
   10. Normative References ..........................................14

Camarillo                   Standards Track                     [Page 2]
RFC 5362            Pending Additions Event Package         October 2008

1.  Introduction

   The framework for consent-based communications in SIP [RFC5360]
   identifies the need for users manipulating the translation logic at a
   relay (e.g., adding a new recipient) to be informed about the
   consent-related status of the recipients of a given translation.
   That is, the user manipulating the translation logic needs to know
   which recipients have given the relay permission to send them SIP
   requests.

   This document defines a SIP event package whereby user agents can
   subscribe to the consent-related state of the resources that are
   being added to a resource list that defines a translation.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Relay:  Any SIP server, be it a proxy, B2BUA (Back-to-Back User
      Agent), or some hybrid, that receives a request, translates its
      Request-URI into one or more next-hop URIs (i.e., recipient URIs),
      and delivers the request to those URIs.

3.  Overview of Operation
Show full document text