Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
draft-ietf-sip-refer-feature-param-01

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sip mailing list <sip@ietf.org>, 
    sip chair <sip-chairs@tools.ietf.org>
Subject: Protocol Action: 'Conveying Feature Tags with Session 
         Initiation Protocol REFER Method' to Proposed Standard 

The IESG has approved the following document:

- 'Conveying Feature Tags with Session Initiation Protocol REFER Method '
   <draft-ietf-sip-refer-feature-param-02.txt> as a Proposed Standard

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

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-feature-param-02.txt

Ballot Text

Technical Summary
 
 The SIP "Caller Preferences" extension defined in RFC 3840 provides a
mechanism that allows a SIP request to convey information relating
to the originator's capabilities and preferences for handling of that
request. The SIP REFER method defined in RFC 3515 provides a
mechanism that allows one party to induce another to initiate a SIP
request. This document extends the REFER method to use the
mechanism of RFC 3840. By doing so, the originator of a REFER may
inform the recipient as to the characteristics of the target that the
induced request is expected to reach.

Working Group Summary
 
This specification is the result of several months of discussion in
the SIP working group. The key issue resolved was around the scope of
capabilities to be expressed, with agreement on the capabilities
expression of RFC 3840 developing during a break-out session at IETF
63. This compromise position received broad support.

 
Protocol Quality
 
The specification was reviewed for quality by the SIP working group
and by SIP Chair Dean Willis. It includes only a very small extension
to the REFER method of RFC 3515. 


Dean is the working group chair shepherd.  Allison Mankin is the
Responsible Area Director.

Note to RFC Editor
 
[provide a full abstract]
Abstract
OLD:
This document extends the REFER method, defined in RFC 3515, to
   convey feature parameters defined in RFC 3840.

NEW:
 The SIP "Caller Preferences" extension defined in RFC 3840 provides a
 mechanism that allows a SIP request to convey information relating
 to the originator's capabilities and preferences for handling of that
 request. The SIP REFER method defined in RFC 3515 provides a
 mechanism that allows one party to induce another to initiate a SIP
 request. This document extends the REFER method to use the
 mechanism of RFC 3840. By doing so, the originator of a REFER may
 inform the recipient as to the characteristics of the target that the
 induced request is expected to reach.

Section 3, Definitions:

OLD:
   Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                     * (SEMI generic-param)

   is extended to:

   Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                     * (SEMI refer-param)

NEW:
   Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                     *(SEMI generic-param)

   is extended to:

   Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
                     *(SEMI refer-param)


[eliminate the spaces after the *]

--------

Also in Section 3:

OLD:
 Note that if any URI parameters are present, the entire URI must be
 enclosed in "&lt" and "&gt".  If no "&lt" and "&gt" are
 present, all parameters after the URI are header parameters,
 not URI parameters.

NEW:
 Note that if any URI parameters are present, the entire URI must be
 enclosed in "<" and ">".  If the "<" and ">" are not present, all
 parameters after the URI are header parameters, not URI parameters.

RFC Editor Note