Subject: [Sipping] Document Action: 'Updates to Asserted Identity in the Session Initiation Protocol (SIP)' to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 8 Mar 2010 09:44:58 -0800 (PST)

The IESG has approved the following document:

- 'Updates to Asserted Identity in the Session Initiation Protocol (SIP) '
   <draft-ietf-sipping-update-pai-09.txt> as an Informational RFC

This document is the product of the Session Initiation Proposal Investigation Working Group. 

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-update-pai-09.txt

Technical Summary

SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header
field. This header field is specified for use in requests using a
number of SIP methods, in particular the INVITE method. However,
RFC 3325 does not specify the insertion of this header field by a
trusted UAC, does not specify the use of P-Asserted-Identity and
P-Preferred-Identity header fields with certain SIP methods such
as UPDATE, REGISTER, MESSAGE and PUBLISH, and does not specify
how to handle an unexpected number of URIs or unexpected URI
schemes in these header fields. This document extends RFC 3325
to cover these situations.

Working Group Summary
The SIPPING WG supports the development and advancement of
this document.

Document Quality
This document has no normative protocol impacts.

The document has been thorughly reviewed in the SIPPING WG with
WG participants providing detailed reviews and comments for
the initial WG review, during each of the two WGLCs and
following the WGLCs to ensure the document was updated consistent 
with WG consensus. There has been extensive face to face meeting 
and WG mailing list discussions.

Personnel
Mary Barnes is the WG chair shepherd. 

RFC Editor Note

1. Author's email address:
OLD:
[email-masked]

NEW:
[email-masked]

2. Abstract:
OLD:
"SIP has a mechanism for conveying the asserted identity of the originator
of a request by means of the P-Asserted-Identity header field. This header
field is specified for use in requests using a number of SIP methods, in
particular the INVITE method. However, RFC 3325 does not specify the
insertion of this header field by a trusted UAC..."

NEW:
"The Session Initiation Protocol (SIP) has a mechanism for conveying the
identity of the originator of a request by means of the
P-Asserted-Identity and P-Preferred-Identity header fields. These header
fields are specified for use in requests using a number of SIP methods, in
particular the INVITE method. However, RFC 3325 does not specify the
insertion of the P-Asserted-Identity header field by a trusted User Agent
Client (UAC)..."

3. Abstract:
DELETE:
"This work is being discussed on the [email-masked] mailing list."

4. Section 2:
OLD:
"in particular the INVITE method."

NEW:
"in particular the INVITE method. In addition, the P-Preferred-Identity
header field can be used to indicate a preference for which identity
should be asserted when there is a choice."

5. Section 2:
OLD:
"RFC 3325 does not specify the insertion of the P-Asserted-Identity header
field by a UAC in the same Trust Domain as the first proxy"

NEW:
"RFC 3325 does not specify the insertion of the P-Asserted-Identity header
field by a User Agent Client (UAC) in the same Trust Domain as the first
proxy"

6. Section 2:
OLD:
"at most two URIs"

NEW:
"at most two Universal Resource Identifiers (URIs)"

7. Section 2:
OLD:
"to challenge a UAS"

NEW:
"to challenge a User Agent Server (UAS)"

8. Section 3.1:
OLD:
"PSTN gateways"

NEW:
"Public Switched Telephone Network (PSTN) gateways"

9. Section 3.1:
OLD:
"application servers (or B2BUAs)"

NEW:
"application servers (or Back-to-Back User Agents, B2BUAs)"

10. Section 3.2:
OLD:
"to the peer SIP UA"

NEW:
"to the peer SIP User Agent (UA)"

11. Section 3.2:
OLD:
"in requests with methods that are not provided for in RFC 3325"

NEW:
"in requests with methods for which there is no provision in RFC 3325"

12. Section 4:
OLD:
"and by allowing a P-Asserted-Identity or P-Preferred-Identity header
field to appear in any request"

NEW:
"and by allowing a P-Asserted-Identity or P-Preferred-Identity header
field to appear in any request except ACK or CANCEL"

13.Section 4.3:
OLD:
"If the node is within the Trust Domain"

NEW:
"If the node is within the Trust Domain (the node having been
authenticated by some means)"

14. Section 4.4:
OLD:
"and represents"

NEW:
"and is represented by"

15. Section 4.5:
Insert at start of first paragraph:
"An entity receiving a P-Asserted-Identity or P-Preferred-Identity header
field can expect the number of URIs and the combination of URI schemes in
the header field to be in accordance with RFC 3325, any updates to RFC
3325, or any Spec(T) that states otherwise. "

16. Section 6:
OLD:
"has no standardised SIP means to authenticate the node"

NEW:
"has no standardised SIP means to authenticate the source of the response"

17. Section 6:
Delete the paragraph:
"When receiving a REGISTER request containing a P-Asserted-Identity header
field, a proxy will trust the asserted identity only if received over a
secure connection from a proxy within the Trust Domain."

Consider the following and make them at the RFC Editors discretion

  - Behaviour -> Behavior (i.e., American spelling)

  - ToC page 2: Acknowledgements -> Acknowledgments

  - 1 page 3: the right place to introduce common abbrevs: UAC, UAS,
URI...

  - 2 page 3: UAC and URI abbrevs should be introduced

  - 2 page 4: same for UAS

  - 2 page 4: standardised -> standardized

  - 3.1 page 4: same for PSTN (I suggest in "o  PSTN gateways;")

  - 3.2 page 6: poor wording:
    "with methods that are not provided for in RFC 3325 or any other RFC."

  - 6 page 10: standardised -> standardized

  - 7 page 10 (title): Acknowledgements	-> Acknowledgments