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: john.elwell@siemens.com NEW: john.elwell@siemens-enterprise.com 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 sipping@ietf.org 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
