SIP-Specific Event Notification
RFC 6665

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    sipcore mailing list <sipcore@ietf.org>,
    sipcore chair <sipcore-chairs@tools.ietf.org>
Subject: Protocol Action: 'SIP-Specific Event Notification' to Proposed Standard (draft-ietf-sipcore-rfc3265bis-09.txt)

The IESG has approved the following document:
- 'SIP-Specific Event Notification'
  (draft-ietf-sipcore-rfc3265bis-09.txt) as Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/


Technical Summary

This document describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.

This document represents a backwards-compatible improvement on the
original mechanism described by RFC 3265, taking into account several
years of implementation experience.  Accordingly, this document
obsoletes RFC 3265.  This document also updates RFC 4660 slightly to
accommodate some small changes to the mechanism that were discussed
in that document.

Working Group Summary

The shepherd reviewed all the discussion (and there was a lot) but found
nothing worthy of bringing up here - it was all resolved.

Document Quality

In the shepherd's opinion this document is a good one - accomplishing 
what it set out to accomplish. It reflects a lot of work done well.

Because this is a revision to an existing RFC, that only tweaks things,
its hard to know if there have been any implementations of *this* draft
prior to its publication as an RFC.

Judging from the number of participants in the discussions, the shepherd
does expect that this draft will rapidly become the reference for future event
implementations. This will not cause any major upheavals, because the
changes are minor.

The one place where there might be reluctance to move to the revision is
for the implicit subscription for REFER, because this version doesn't
allow REFER to be done in an existing dialog. Those who have sip
implementations that use in-dialog REFER may choose to continue doing
so. The backward compatibility requirements in this draft will allow
those things to keep working, but it may cause difficulty in claims of
conformance if such an implementation wants to claim conformance to this
draft except for that REFER case. But this is merely collateral damage
for digging out of the issues caused by the introduction of shared
dialogs in RFC 3261.

Personnel

Paul Kyzivat is the Document Shepherd
Robert Sparks is the  Responsible Area Director