draft-ietf-sipcore-callinfo-rcd-09.txt   draft-ietf-sipcore-callinfo-rcd-10.txt 
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Somos Inc. Internet-Draft Somos Inc.
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: 3 September 2024 Neustar Inc. Expires: 27 September 2024 Neustar Inc.
2 March 2024 26 March 2024
SIP Call-Info Parameters for Rich Call Data SIP Call-Info Parameters for Rich Call Data
draft-ietf-sipcore-callinfo-rcd-09 draft-ietf-sipcore-callinfo-rcd-10
Abstract Abstract
This document describes a usage of the SIP Call-Info header field This document describes a usage of the SIP Call-Info header field
that incorporates Rich Call Data (RCD) associated with the identity that incorporates Rich Call Data (RCD) associated with the identity
of the calling party in order to provide to the called party a of the calling party in order to provide to the called party a
description of the caller or details about the reason for the call. description of the caller or details about the reason for the call.
RCD includes information about the caller beyond the telephone number RCD includes information about the caller beyond the telephone number
such as a calling name, or a logo, photo, or jCard object such as a calling name, or a logo, photo, or jCard object
representing the caller, which can help the called party decide representing the caller, which can help the called party decide
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 3 September 2024. This Internet-Draft will expire on 27 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 25 skipping to change at page 2, line 25
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. A Call-Info Framework for Carrying Rich Call Data . . . . . . 5 4. A Call-Info Framework for Carrying Rich Call Data . . . . . . 5
5. "rcd-jcard" Call-Info 'purpose' Token . . . . . . . . . . . . 7 5. "rcd-jcard" Call-Info 'purpose' Token . . . . . . . . . . . . 6
6. 'call-reason' Call-Info Parameter . . . . . . . . . . . . . . 9 6. 'call-reason' Call-Info Parameter . . . . . . . . . . . . . . 9
7. Usage and an Example of Call-Info for RCD . . . . . . . . . . 10 7. Usage and an Example of Call-Info for RCD . . . . . . . . . . 10
8. Usage of jCard and Property-Specific Usage . . . . . . . . . 11 8. Usage of jCard and Property-Specific Usage . . . . . . . . . 11
8.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 11 8.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 11
8.2. Usage of Multimedia Data in jCard or with Icon . . . . . 11 8.2. Usage of Multimedia Data in jCard or with Icon . . . . . 11
8.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Identification Properties . . . . . . . . . . . . . . . . 13 8.4. Identification Properties . . . . . . . . . . . . . . . . 13
8.4.1. "fn" Property . . . . . . . . . . . . . . . . . . . . 13 8.4.1. "fn" Property . . . . . . . . . . . . . . . . . . . . 13
8.4.2. "n" Property . . . . . . . . . . . . . . . . . . . . 14 8.4.2. "n" Property . . . . . . . . . . . . . . . . . . . . 13
8.4.3. "nickname" Property . . . . . . . . . . . . . . . . . 14 8.4.3. "nickname" Property . . . . . . . . . . . . . . . . . 14
8.4.4. "photo" Property . . . . . . . . . . . . . . . . . . 14 8.4.4. "photo" Property . . . . . . . . . . . . . . . . . . 14
8.5. Delivery Addressing Properties . . . . . . . . . . . . . 15 8.5. Delivery Addressing Properties . . . . . . . . . . . . . 14
8.5.1. "adr" Property . . . . . . . . . . . . . . . . . . . 15 8.5.1. "adr" Property . . . . . . . . . . . . . . . . . . . 15
8.6. Communications Properties . . . . . . . . . . . . . . . . 15 8.6. Communications Properties . . . . . . . . . . . . . . . . 15
8.6.1. "tel" Property . . . . . . . . . . . . . . . . . . . 15 8.6.1. "tel" Property . . . . . . . . . . . . . . . . . . . 15
8.6.2. "email" Property . . . . . . . . . . . . . . . . . . 16 8.6.2. "email" Property . . . . . . . . . . . . . . . . . . 16
8.6.3. "lang" Property . . . . . . . . . . . . . . . . . . . 16 8.6.3. "lang" Property . . . . . . . . . . . . . . . . . . . 16
8.7. Geographical Properties . . . . . . . . . . . . . . . . . 16 8.7. Geographical Properties . . . . . . . . . . . . . . . . . 16
8.7.1. "tz" Property . . . . . . . . . . . . . . . . . . . . 16 8.7.1. "tz" Property . . . . . . . . . . . . . . . . . . . . 16
8.7.2. "geo" Property . . . . . . . . . . . . . . . . . . . 17 8.7.2. "geo" Property . . . . . . . . . . . . . . . . . . . 17
8.8. Organizational Properties . . . . . . . . . . . . . . . . 17 8.8. Organizational Properties . . . . . . . . . . . . . . . . 17
8.8.1. "title" Property . . . . . . . . . . . . . . . . . . 17 8.8.1. "title" Property . . . . . . . . . . . . . . . . . . 17
8.8.2. "role" Property . . . . . . . . . . . . . . . . . . . 17 8.8.2. "role" Property . . . . . . . . . . . . . . . . . . . 17
8.8.3. "logo" Property . . . . . . . . . . . . . . . . . . . 18 8.8.3. "logo" Property . . . . . . . . . . . . . . . . . . . 18
8.8.4. "org" Property . . . . . . . . . . . . . . . . . . . 18 8.8.4. "org" Property . . . . . . . . . . . . . . . . . . . 18
8.9. Explanatory Properties . . . . . . . . . . . . . . . . . 18 8.9. Explanatory Properties . . . . . . . . . . . . . . . . . 18
8.9.1. "categories" Property . . . . . . . . . . . . . . . . 18 8.9.1. "categories" Property . . . . . . . . . . . . . . . . 18
8.9.2. "note" Property . . . . . . . . . . . . . . . . . . . 19 8.9.2. "note" Property . . . . . . . . . . . . . . . . . . . 19
8.9.3. "sound" Property . . . . . . . . . . . . . . . . . . 19 8.9.3. "sound" Property . . . . . . . . . . . . . . . . . . 19
8.9.4. "uid" Property . . . . . . . . . . . . . . . . . . . 19 8.9.4. "uid" Property . . . . . . . . . . . . . . . . . . . 19
8.9.5. "url" Property . . . . . . . . . . . . . . . . . . . 20 8.9.5. "url" Property . . . . . . . . . . . . . . . . . . . 20
8.9.6. "version" Property . . . . . . . . . . . . . . . . . 20 8.9.6. "version" Property . . . . . . . . . . . . . . . . . 20
9. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 21 9. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. SIP Call-Info Header Field 'purpose' Parameter Token . . 21 10.1. SIP Call-Info Header Field 'purpose' Parameter Token . . 21
10.2. SIP Call-Info Header Field 'call-reason' Parameter . . . 21 10.2. SIP Call-Info Header Field 'call-reason' Parameter . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Signaling protocols in telephone networks have long supported the Signaling protocols in telephone networks have long supported the
delivery of a 'calling name' from the originating side to the delivery of a 'calling name' from the originating side to the
terminating side, though in practice, the terminating side is often terminating side, though in practice, the terminating side is often
left to derive a name from the calling-party number by consulting a left to derive a name from the calling-party number by consulting a
local address book or an external database. SIP [RFC3261] similarly local address book or an external database. SIP [RFC3261] similarly
skipping to change at page 7, line 24 skipping to change at page 7, line 8
5. "rcd-jcard" Call-Info 'purpose' Token 5. "rcd-jcard" Call-Info 'purpose' Token
The Call-Info 'purpose' token "rcd-jcard" indicates support of RCD The Call-Info 'purpose' token "rcd-jcard" indicates support of RCD
associated with the identity of a calling party in a SIP call associated with the identity of a calling party in a SIP call
[RFC3261], Section 20.9. The format of a Call-Info header field when [RFC3261], Section 20.9. The format of a Call-Info header field when
using the "rcd-jcard" token is as follows. using the "rcd-jcard" token is as follows.
The Call-Info header field is defined to include a URI that points to The Call-Info header field is defined to include a URI that points to
a resource that is a jCard JSON object [RFC7095]. The media type for a resource that is a jCard JSON object [RFC7095]. The media type for
the JSON text MUST be set as application/json with a default encoding the JSON text MUST be set as application/json with a default encoding
of UTF-8 [RFC4627]. This MAY be carried directly in the Call-Info of UTF-8 [RFC8259]. This MAY be carried directly in the Call-Info
header field URI using the "data" URI scheme. A jCard also MAY be header field URI using the "data" URI scheme. A jCard also MAY be
carried in the body of the SIP request bearing this Call-Info header carried in the body of the SIP request bearing this Call-Info header
field via the "cid" URI scheme [RFC2392]. Alternatively, the URI field via the "cid" URI scheme [RFC2392]. Alternatively, the URI
MUST define the use HTTPS or a transport that can validate the MUST define the use HTTPS or a transport that can validate the
integrity of the source of the resource as well as the transport integrity of the source of the resource as well as the transport
channel through which the resource is retrieved. If, in the specific channel through which the resource is retrieved. If, in the specific
deployment environment of SIP, the source or integrity of the RCD deployment environment of SIP, the source or integrity of the RCD
information cannot be trusted, then the use of the STIR RCD framework information cannot be trusted, then the use of the STIR RCD framework
defined in [I-D.ietf-stir-passport-rcd] should be considered. defined in [I-D.ietf-stir-passport-rcd] should be considered.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
8.2. Usage of Multimedia Data in jCard or with Icon 8.2. Usage of Multimedia Data in jCard or with Icon
For the use of the 'purpose' token "icon" or for the cases where the For the use of the 'purpose' token "icon" or for the cases where the
jCard either incorporates URIs or includes digital images and sounds jCard either incorporates URIs or includes digital images and sounds
directly via Base64 encoding, we provide recommendations to directly via Base64 encoding, we provide recommendations to
facilitate the successful decoding and rendering of these images and facilitate the successful decoding and rendering of these images and
media formats. media formats.
For images, such as for the "photo" and "logo" properties, the For images, such as for the "photo" and "logo" properties, the
default image formats SHOULD be PNG or JPEG, as these files are default image formats SHOULD be PNG [ISOPNG] or JPEG [ITUJPEG], as
commonly used to support 24-bit RGB images. Supporting older these files are commonly used to support 24-bit RGB images.
telephone devices that only support bitmap (BMP) images with a lower Supporting older telephone devices that only support bitmap (BMP)
bit range (e.g., 16 bit, 8 bit, or 1 bit), or grayscale, or 1-bit images [RFC7903] with a lower bit range (e.g., 16 bit, 8 bit, or 1
black and white color displays, should be considered optional or even bit), or grayscale, or 1-bit black and white color displays, should
not recommended because, at the time of writing, they are becoming be considered optional or even not recommended because, at the time
increasingly rare (i.e., typically, devices either have color or of writing, they are becoming increasingly rare (i.e., typically,
color-aware graphical displays that support PNG or JPEG formats or devices either have color or color-aware graphical displays that
they are exclusively textual displays). support PNG or JPEG formats or they are exclusively textual
displays).
In addition, vector images are increasingly popular to use for icons In addition, vector images are increasingly popular to use for icons
because they support scalable images without having to send multiple because they support scalable images without having to send multiple
resolutions. The SVG format has gained wide support as of this resolutions. The SVG format has gained wide support as of this
writing as a common format for vector images. At a minimum, the SVG writing as a common format for vector images. At a minimum, the SVG
Tiny 1.2 specification [W3C-SVGTiny1.2] should be supported as an Tiny 1.2 specification [W3C-SVGTiny1.2] SHOULD be supported as an
additional default format for devices. additional default format for devices.
For the cases where image files are referenced by URIs as file For the cases where image files are referenced by URIs as file
resources, this document defines a character string that SHOULD be resources, this document defines a character string that SHOULD be
concatenated onto the end of a file name, but before the file concatenated onto the end of a file name, but before the file
extension, that signals the height and width of the image to the end extension, that signals the height and width of the image to the end
device for the convenience of determining the appropriate resolution device for the convenience of determining the appropriate resolution
to retrieve without the need to retrieve all the image files. It is to retrieve without the need to retrieve all the image files. It is
also recommended that images have a square aspect ratio with equal also recommended that images have a square aspect ratio with equal
height and width and with a power of two value for the number of height and width and with a power of two value for the number of
skipping to change at page 13, line 5 skipping to change at page 12, line 49
filename.jpg) or (e.g., filename-32x32.png, filename-64x64.png, filename.jpg) or (e.g., filename-32x32.png, filename-64x64.png,
filename.svg, filename-32x32.jpg, or filename-64x64.jpg). filename.svg, filename-32x32.jpg, or filename-64x64.jpg).
Because this is a complex and often debated topic that has evolved Because this is a complex and often debated topic that has evolved
over the many years of advances in image coding and display over the many years of advances in image coding and display
technologies, we suggest relying on either future specifications or technologies, we suggest relying on either future specifications or
industry forum specifications that might correspond to supporting industry forum specifications that might correspond to supporting
particular classes of devices to further define how URIs can particular classes of devices to further define how URIs can
reference appropriate image formats and files. reference appropriate image formats and files.
For audio files, the recommendation is to provide mp3, m4a, or wav For audio files, the recommendation is to provide mp3, m4a or mp4, or
files, although the usage of sound (for example, a special ring tone wav files [RFC2361], although the usage of sound (for example, a
for a particular caller) is not well defined in this specification. special ring tone for a particular caller) is not well defined in
Future documents should consider both usage and potential security this specification. Future documents should consider both usage and
risks of playing sounds that are not specifically authorized by a potential security risks of playing sounds that are not specifically
device user. authorized by a device user.
8.3. Cardinality 8.3. Cardinality
Property cardinalities are indicated, for convenience, using the Property cardinalities are indicated, for convenience, using the
following notation and follow the guidance of jCard [RFC7095] and following notation and follow the guidance of jCard [RFC7095] and
vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6): vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6):
+-------------+--------------------------------------------------+ +-------------+--------------------------------------------------+
| Cardinality | Meaning | | Cardinality | Meaning |
+-------------+--------------------------------------------------+ +-------------+--------------------------------------------------+
skipping to change at page 22, line 15 skipping to change at page 22, line 5
The security framework of signing and providing integrity to this The security framework of signing and providing integrity to this
data [I-D.ietf-stir-passport-rcd] should be followed, and the use of data [I-D.ietf-stir-passport-rcd] should be followed, and the use of
constraints and other certificate-based associations should be constraints and other certificate-based associations should be
considered. This includes considerations for information about the considered. This includes considerations for information about the
calling party, which is generally constant, versus per-call data, calling party, which is generally constant, versus per-call data,
which is more transient. This also includes the relationship that which is more transient. This also includes the relationship that
certificates with constraints presents to how they relate to each certificates with constraints presents to how they relate to each
other and how that information is managed, protected, and associated other and how that information is managed, protected, and associated
with the correct call corresponding to a calling party. with the correct call corresponding to a calling party.
12. Normative References 12. References
12.1. Normative References
[I-D.ietf-stir-passport-rcd] [I-D.ietf-stir-passport-rcd]
Wendt, C. and J. Peterson, "PASSporT Extension for Rich Wendt, C. and J. Peterson, "PASSporT Extension for Rich
Call Data", Work in Progress, Internet-Draft, draft-ietf- Call Data", Work in Progress, Internet-Draft, draft-ietf-
stir-passport-rcd-26, 5 June 2023, stir-passport-rcd-26, 5 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-stir- <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
passport-rcd-26>. passport-rcd-26>.
[ISOPNG] ISO/IEC, "Information technology -- Computer graphics and
image processing -- Portable Network Graphics (PNG),
Functional specification, ISO/IEC 15948:2004", March 2004.
[ITUJPEG] ITU-T, "Information technology - Digital compression and
coding of continuous-tone still images, JPEG File
Interchange Format (JFIF) ITU-T Recommendation T.871, ISO/
IEC 10918-5, 2013", May 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[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/rfc/rfc2392>. <https://www.rfc-editor.org/rfc/rfc2392>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>. <https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/rfc/rfc3325>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/rfc/rfc3966>. <https://www.rfc-editor.org/rfc/rfc3966>.
[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/rfc/rfc3968>. <https://www.rfc-editor.org/rfc/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/rfc/rfc4627>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>. <https://www.rfc-editor.org/rfc/rfc5234>.
[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/rfc/rfc6350>. <https://www.rfc-editor.org/rfc/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/rfc/rfc7095>. <https://www.rfc-editor.org/rfc/rfc7095>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/rfc/rfc7340>.
[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,
<https://www.rfc-editor.org/rfc/rfc7519>. <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/rfc/rfc7852>. <https://www.rfc-editor.org/rfc/rfc7852>.
[RFC7903] Leonard, S., "Windows Image Media Types", RFC 7903,
DOI 10.17487/RFC7903, September 2016,
<https://www.rfc-editor.org/rfc/rfc7903>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/rfc/rfc8224>. <https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/rfc/rfc8225>. <https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[W3C-SVGTiny1.2] [W3C-SVGTiny1.2]
W3C, "Scalable Vector Graphics (SVG) Tiny 1.2 W3C, "Scalable Vector Graphics (SVG) Tiny 1.2", 22
<https://www.w3.org/TR/SVGMobile/>", 22 December 2008. December 2008, <https://www.w3.org/TR/SVGMobile/>.
12.2. Informative References
[RFC2361] Fleischman, E., "WAVE and AVI Codec Registries", RFC 2361,
DOI 10.17487/RFC2361, June 1998,
<https://www.rfc-editor.org/rfc/rfc2361>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/rfc/rfc3325>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/rfc/rfc7340>.
Acknowledgements Acknowledgements
We would like to thank David Hancock, Alec Fenichel, and other We would like to thank David Hancock, Alec Fenichel, and other
members of the SIPCORE and STIR working groups for their helpful members of the SIPCORE and STIR working groups for their helpful
suggestions and comments during the creation of this document. suggestions and comments during the creation of this document.
Authors' Addresses Authors' Addresses
Chris Wendt Chris Wendt
 End of changes. 20 change blocks. 
45 lines changed or deleted 69 lines changed or added

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