RFC 6993

Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)

πŸ“… published July 2013, from ietf

Hiii bestie πŸŽ€βœ¨ this is RFC 6993, and it's titled Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) πŸ’–. It was written by Peter Saint-Andre of Cisco Systems, Inc. πŸ’… It's Informational (not a Standards Track spec 🌸), dated July 2013, with ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates πŸ¦‹.

Abstract πŸ’œ

okay so this doc defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in SIP 🧚. that's the whole vibe ✨

Status of This Memo 🌈

this one is NOT an Internet Standards Track spec, it's just published for info πŸ’…. it's still an IETF product that reflects the consensus of the IETF community, got public review, and was approved by the IESG 🫢. not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious πŸ™ˆ

info about the current status, errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6993 πŸ“

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. πŸ’œ

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date πŸ“œ. read them carefully, bestie, they're your rights and restrictions πŸ’…. any Code Components pulled out of this doc have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license πŸ”₯

Table of Contents 🌸

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Security Considerations . . . . . . . . . . . . . . . . . . .   2
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   3
  4.1.  Normative References  . . . . . . . . . . . . . . . . . .   3
  4.2.  Informative References  . . . . . . . . . . . . . . . . .   3
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4

1. Introduction ✨

okay so some real-time communication endpoints use SIP [RFC3261] and XMPP [RFC6120] together πŸ“žπŸ’¬. to make interop better among these "CUSAX" endpoints [CUSAX], it can help to advertise each endpoint's SIP address over XMPP and its XMPP address over SIP πŸ¦‹. that gives hints about what the endpoints can do, which is iconic πŸ‘‘. the XMPP side is handled by an extension called Reachability Addresses [XEP-0152] πŸ’…. for the SIP side, the SIP folks decided it's best to use the Call-Info header field [RFC3261] with the value "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter 🧚. here's an example:

Call-Info: <xmpp:juliet@example.com> ;purpose=impp

and while CUSAX endpoints are the main use case for "impp", a URI [RFC3986] for an instant messaging and presence protocol other than XMPP could also go in the Call-Info header field 🌈

2. Security Considerations πŸ”₯

bestie, read this part carefully 😭

advertising an endpoint's XMPP address over SIP could tell malicious entities about another attack vector πŸ’€. the "purpose" header field parameter could be spoofed, so the receiving endpoint ought to check the value against an authoritative source, like a user directory πŸ™ˆ. clients can integrity protect and encrypt this header field end-to-end with S/MIME, or hop-by-hop with Transport Layer Security (TLS) πŸ”

this spec also gives a new way to link identifiers that might otherwise be unconnected πŸ•΅οΈβ€β™€οΈ. since those correlations can be privacy sensitive, user agents ought to give users a way to control whether or not these values get sent 🫢

3. IANA Considerations 🧚

this doc defines and registers a new predefined value "impp" for the "purpose" header field parameter of the Call-Info header field πŸ¦‹. IANA finished this by adding this RFC as a reference on the line for the "Call-Info" header field and the "purpose" parameter name in the "Header Field Parameters and Parameter Values" section of the "Session Initiation Protocol (SIP) Parameters" registry πŸ’–:

  Header Field: Call-Info
  Parameter Name: purpose
  Predefined Values: Yes
  Reference: [RFC3261][RFC5367][RFC6910][RFC6993]

4. References πŸ“š

4.1. Normative References

  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.

4.2. Informative References

  • [CUSAX] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, June 2013.
  • [XEP-0152] Saint-Andre, P. and J. Hildebrand, "Reachability Addresses", XSF XEP 0152, February 2013.

5. Acknowledgements 🫢

thanks to Gonzalo Camarillo, Keith Drage, Saul Ibarra, Emil Ivov, Cullen Jennings, Olle Johanssen, Paul Kyzivat, Gonzalo Salgueiro, Dean Willis, and Dale Worley for their input πŸ’œ. Elwyn Davies, Salvatore Loreto, Glen Zorn, and Mehmet Ersue did reviews for the General Area Review Team, Applications Area Directorate, Security Directorate, and Operations and Management Directorate, respectively πŸ‘‘. Stephen Farrell and Pete Resnick gave substantive feedback during IESG review πŸ”₯. and a big thank you to Yana Stamcheva for her helpful comments and for shepherding the document 🌸

Author's Address πŸ¦‹

Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA

Phone: +1-303-308-3282 EMail: psaintan@cisco.com

πŸ“¦ where this page comes from