draft-ietf-sipcore-callinfo-rcd-00.txt   draft-ietf-sipcore-callinfo-rcd-01.txt 
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: May 6, 2021 Neustar Inc. Expires: May 22, 2021 Neustar Inc.
November 02, 2020 November 18, 2020
SIP Call-Info Parameters for Rich Call Data SIP Call-Info Parameters for Rich Call Data
draft-ietf-sipcore-callinfo-rcd-00 draft-ietf-sipcore-callinfo-rcd-01
Abstract Abstract
This document describes a SIP Call-Info header field usage defined to This document describes a SIP Call-Info header field usage defined to
include rich data associated with the identity of the calling party include rich data associated with the identity of the calling party
that can be rendered to called party for providing more useful that can be rendered to called party for providing more useful
information about the caller or the specific reason for the call. information about the caller or the specific reason for the call.
This includes extended comprehensive information about the caller This includes extended comprehensive information about the caller
such as what a jCard object can represent for describing the calling such as what a jCard object can represent for describing the calling
party or other call specific information such as describing the party or other call specific information such as describing the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on May 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 49 skipping to change at page 4, line 49
context of the call and why they may want to answer the call. context of the call and why they may want to answer the call.
4. "jcard" Call-Info Token 4. "jcard" Call-Info Token
The use of the new Call-Info Token "jcard" is for the purpose of The use of the new Call-Info Token "jcard" is for the purpose of
supporting RCD associated with the identity of a calling party in a supporting RCD associated with the identity of a calling party in a
SIP call [RFC3261] Section 20.9. The format of a Call-Info header SIP call [RFC3261] Section 20.9. The format of a Call-Info header
field when using the "jcard" is as follows. field when using the "jcard" is as follows.
The Call-Info header should include a URI where the resource pointed The Call-Info header should include a URI where the resource pointed
to by the URI is a jCard JSON object defined in [RFC7095]. This MAY to by the URI is a jCard JSON object defined in [RFC7095]. The web
be carried in the body of the SIP request bearing this Call-Info via server serving this file MUST use the MIME media type for JSON text
the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST define as application/json with a default encoding of UTF-8 [RFC4627]. This
the use HTTPS or a transport that can validate the integrity of the also MAY be carried in the body of the SIP request bearing this Call-
source of the resource as well as the transport channel the resource Info via the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST
is retrieved. define the use HTTPS or a transport that can validate the integrity
of the source of the resource as well as the transport channel the
resource is retrieved.
An example of a Call-Info header field is: An example of a Call-Info header field is:
Call-Info: <https://example.com/jbond.json> Call-Info: <https://example.com/jbond.json>;purpose=jcard
An example jCard JSON file is shown as follows: An example contents of a URL linked jCard JSON file is shown as
follows:
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "James Bond"], ["fn", {}, "text", "James Bond"],
["n", {}, "text", ["Bond", "James", "", "", "Mr."]], ["n", {}, "text", ["Bond", "James", "", "", "Mr."]],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
"20008", "USA"] "20008", "USA"]
], ],
skipping to change at page 7, line 22 skipping to change at page 7, line 22
One alternative approach would be to use the baseline [RFC3261] One alternative approach would be to use the baseline [RFC3261]
Subject header field value to convey the reason for the call. Subject header field value to convey the reason for the call.
Because the Subject header has seen little historical use in SIP Because the Subject header has seen little historical use in SIP
implementations, however, and its specification describes its implementations, however, and its specification describes its
potential use in filtering, it seems more prudent to define a new potential use in filtering, it seems more prudent to define a new
means of carrying a call reason indication. means of carrying a call reason indication.
An example of a Call-Info header field value with the "call-reason" An example of a Call-Info header field value with the "call-reason"
parameter follows: parameter follows:
Call-Info: <https://example.com/jbond.json>; Call-Info: <https://example.com/jbond.json>;purpose=jcard;
call-reason="For your ears only" call-reason="For your ears only"
One can readily imagine a need for more structured call reason data One can readily imagine a need for more structured call reason data
that could be reliably processed automatically. Future versions of that could be reliably processed automatically. Future versions of
this specification may explore ways to provide a structured data this specification may explore ways to provide a structured data
object in place of a textual string to support things like object in place of a textual string to support things like
internationalization or categories of reason that can be parsed by internationalization or categories of reason that can be parsed by
machines. machines.
6. Usage of jCard and property specific usage 6. Usage of jCard and property specific usage
skipping to change at page 14, line 28 skipping to change at page 14, line 28
security can be used to hide information from eavesdroppers, and the security can be used to hide information from eavesdroppers, and the
same confidentiality mechanisms would protect any Call-Info or jCard same confidentiality mechanisms would protect any Call-Info or jCard
information carried or referred to in SIP. information carried or referred to in SIP.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-stir-passport-rcd] [I-D.ietf-stir-passport-rcd]
Peterson, J. and C. Wendt, "PASSporT Extension for Rich Peterson, J. and C. Wendt, "PASSporT Extension for Rich
Call Data", draft-ietf-stir-passport-rcd-06 (work in Call Data", draft-ietf-stir-passport-rcd-08 (work in
progress), March 2020. progress), November 2020.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, DOI 10.17487/RFC2426, September 1998, RFC 2426, DOI 10.17487/RFC2426, September 1998,
<https://www.rfc-editor.org/info/rfc2426>. <https://www.rfc-editor.org/info/rfc2426>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 15, line 11 skipping to change at page 15, line 11
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<https://www.rfc-editor.org/info/rfc3324>. <https://www.rfc-editor.org/info/rfc3324>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
DOI 10.17487/RFC3968, December 2004, DOI 10.17487/RFC3968, December 2004,
<https://www.rfc-editor.org/info/rfc3968>. <https://www.rfc-editor.org/info/rfc3968>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011, DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>. <https://www.rfc-editor.org/info/rfc6350>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014, DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>. <https://www.rfc-editor.org/info/rfc7095>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
 End of changes. 9 change blocks. 
15 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/