Connected Identity in the Session Initiation Protocol (SIP)
draft-ietf-sip-connected-identity-05

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: 'Connected Identity in the Session 
         Initiation Protocol (SIP)' to Proposed Standard 

The IESG has approved the following document:

- 'Connected Identity in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-connected-identity-06.txt> as a Proposed Standard

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

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-identity-06.txt

Ballot Text

Technical Summary
 
Because of retargeting of a Session Initiation Protocol (SIP)
dialog-forming  request (changing the value of the Request-URI),
 the User Agent Server (UAS) can have a different identity from 
that in the To header field. This  document provides a means 
for that  User Agent (UA) to supply its identity to  the peer UA 
by means of a request in the reverse direction and for that
 identity to be signed by an Authentication Service. The same 
mechanism can be used to indicate a change of identity during 
a dialog, e.g., because of some action in the Public Switched 
Telephone Network (PSTN) behind a gateway. 

This document normatively updates RFC 3261 (SIP). 
 

Working Group Summary
 
The document complements work already performed in RFC 4474 for
authenticated request identity, and forms an integral part of the
chartered  work in this area. There is consensus in the working group to
publish this document. 

 
Protocol Quality
 
The document has been well discussed by a significant number 
of members of the working group. 


Note to RFC Editor
 
OLD
  rendered in OpenSSL format
NEW
  rendered in PEM format
                     ^^^

OLD
   are captured between tags
NEW
   are captured betwen <allOneLine> tags
                                     ^^^^^^^^^


In section 2, last paragraph in the seciton.
OLD 
      Note that even if identity were to be conveyed somehow in a
      response, there would in general be difficulty authenticating the
      UAS except in cases where the UA is connected to its proxy by TLS
      and has already been authenticated.
NEW
      Note that even if identity were to be conveyed somehow in a
      response, there would in general be difficulty authenticating the
      UAS.

RFC Editor Note