rfc9796v1.txt		rfc9796.txt
	skipping to change at line 69 ¶		skipping to change at line 69 ¶
	2. Terminology		2. Terminology
	3. Overview		3. Overview
	4. A Call-Info Framework for Carrying Rich Call Data		4. A Call-Info Framework for Carrying Rich Call Data
	5. "jcard" Call-Info 'purpose' Token		5. "jcard" Call-Info 'purpose' Token
	6. 'call-reason' Call-Info Parameter		6. 'call-reason' Call-Info Parameter
	7. 'verified' Call-Info Parameter		7. 'verified' Call-Info Parameter
	8. 'integrity' Call-Info Parameter		8. 'integrity' Call-Info Parameter
	9. Usage and an Example of Call-Info for RCD		9. Usage and an Example of Call-Info for RCD
	10. Usage of jCard and Property-Specific Usage		10. Usage of jCard and Property-Specific Usage
	10.1. Usage of URIs in jCard		10.1. Usage of URIs in jCard
	10.2. Usage of Multimedia Data in jCard or with Icon		10.2. Usage of Multimedia Data in jCard or with the “icon”
			Call-Info ‘purpose’ Token
	10.3. Cardinality		10.3. Cardinality
	10.4. Identification Properties		10.4. Identification Properties
	10.4.1. "fn" Property		10.4.1. "fn" Property
	10.4.2. "n" Property		10.4.2. "n" Property
	10.4.3. "nickname" Property		10.4.3. "nickname" Property
	10.4.4. "photo" Property		10.4.4. "photo" Property
	10.5. Delivery Addressing Properties		10.5. Delivery Addressing Properties
	10.5.1. "adr" Property		10.5.1. "adr" Property
	10.6. Communications Properties		10.6. Communications Properties
	10.6.1. "tel" Property		10.6.1. "tel" Property
	skipping to change at line 99 ¶		skipping to change at line 100 ¶
	10.8.4. "org" Property		10.8.4. "org" Property
	10.9. Explanatory Properties		10.9. Explanatory Properties
	10.9.1. "categories" Property		10.9.1. "categories" Property
	10.9.2. "note" Property		10.9.2. "note" Property
	10.9.3. "sound" Property		10.9.3. "sound" Property
	10.9.4. "uid" Property		10.9.4. "uid" Property
	10.9.5. "url" Property		10.9.5. "url" Property
	10.9.6. "version" Property		10.9.6. "version" Property
	11. Extension of jCard		11. Extension of jCard
	12. IANA Considerations		12. IANA Considerations
	12.1. 'jcard' Purpose Parameter Value		12.1. "jcard" Purpose Parameter Value
	12.2. SIP Call-Info Header Field 'call-reason' Parameter		12.2. SIP Call-Info Header Field 'call-reason' Parameter
	12.3. SIP Call-Info Header Field 'verified' Parameter		12.3. SIP Call-Info Header Field 'verified' Parameter
	12.4. SIP Call-Info Header Field 'integrity' Parameter		12.4. SIP Call-Info Header Field 'integrity' Parameter
	13. Security Considerations		13. Security Considerations
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	14.2. Informative References		14.2. Informative References
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	skipping to change at line 127 ¶		skipping to change at line 128 ¶
	can carry a 'display-name' in the From header field value from the		can carry a 'display-name' in the From header field value from the
	originating to terminating side, though it is a field that is not		originating to terminating side, though it is a field that is not
	commonly trusted and is often replaced or ignored. The same can be		commonly trusted and is often replaced or ignored. The same can be
	considered true of information in the Call-Info header field in SIP.		considered true of information in the Call-Info header field in SIP.
	This document defines usage of the SIP Call-Info header field		This document defines usage of the SIP Call-Info header field
	[RFC3261] that allows called parties to receive a more comprehensive		[RFC3261] that allows called parties to receive a more comprehensive
	and extensible set of Rich Call Data (RCD) for incoming calls. It		and extensible set of Rich Call Data (RCD) for incoming calls. It
	defines specific usage of the Call-Info header field, a new parameter		defines specific usage of the Call-Info header field, a new parameter
	('call-reason'), and a new token ("jcard") for the 'purpose'		('call-reason'), and a new token ("jcard") for the 'purpose'
	parameter of the Call-Info header field. For this document and		parameter of the Call-Info header field. Depending on the policies
	depending on the policies of the communications system, a calling		of the communications system, a calling party could be either the end
	party could be either the end user device (e.g., a SIP user agent		user device (e.g., a SIP user agent (UA)) or a network service as
	(UA)) or a network service as part of a telephone service provider.		part of a telephone service provider. Similarly, a called party
	Similarly, a called party could be an end user device or the network		could be an end user device or the network telephone service provider
	telephone service provider acting on behalf of the recipient of the		acting on behalf of the recipient of the call.
	call.
	In order to properly protect and communicate some of the		In order to properly protect and communicate some of the
	authenticated and trusted properties of "rcd" claims defined in		authenticated and trusted properties of "rcd" claims defined in
	[RFC9795], this document defines two additional new parameters,		[RFC9795], this document defines two additional new parameters,
	'verified' and 'integrity'. These parameters help protect RCD		'verified' and 'integrity'. These parameters help protect RCD
	information that had been sent via a SIP network to, for example, a		information that had been sent via a SIP network to, for example, a
	SIP entity on the edge of the Network-Network Interface (NNI) that		SIP entity on the edge of the Network-Network Interface (NNI) that
	contains a verification service as defined in [RFC8224] and further		contains a verification service as defined in [RFC8224] and further
	defined specific to RCD information in [RFC9795]. The verification		defined specific to RCD information in [RFC9795]. The verification
	procedures include the successful verification of the "rcd" claims		procedures include the successful verification of the "rcd" claims
	skipping to change at line 172 ¶		skipping to change at line 172 ¶
	authenticated, network-to-device, trusted signaling where a device		authenticated, network-to-device, trusted signaling where a device
	may not have the ability to verify the "rcd" PASSporT, but it can		may not have the ability to verify the "rcd" PASSporT, but it can
	receive the RCD information from the Call-Info header field as		receive the RCD information from the Call-Info header field as
	defined in this specification.		defined in this specification.
	This specification provides an approach for the delivery of jCard		This specification provides an approach for the delivery of jCard
	data that utilizes the same mechanism as [RFC7852] which defined a		data that utilizes the same mechanism as [RFC7852] which defined a
	means of carrying additional data about callers for the purposes of		means of carrying additional data about callers for the purposes of
	emergency services (especially Section 4.4 (Owner/Subscriber		emergency services (especially Section 4.4 (Owner/Subscriber
	Information) of [RFC7852]). This document defines a 'purpose'		Information) of [RFC7852]). This document defines a 'purpose'
	parameter value 'jcard' for the more generic delivery of information		parameter value "jcard" for the more generic delivery of information
	via jCard [RFC7095]. This document borrows from [RFC7852] the		via jCard [RFC7095]. This document borrows from [RFC7852] the
	capability to carry a data structure as a body, through the use of		capability to carry a data structure as a body, through the use of
	the "cid" URI scheme [RFC2392].		the "cid" URI scheme [RFC2392].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at line 241 ¶		skipping to change at line 241 ¶
	information and identities over untrusted networks, which wasn't		information and identities over untrusted networks, which wasn't
	addressed in the core SIP specifications. [RFC3261], Section 20.9		addressed in the core SIP specifications. [RFC3261], Section 20.9
	defines the Call-Info header field as the mechanism for carrying		defines the Call-Info header field as the mechanism for carrying
	call- and caller-related information and also provides procedures for		call- and caller-related information and also provides procedures for
	defining new 'purpose' parameter tokens. This document discusses the		defining new 'purpose' parameter tokens. This document discusses the
	use of existing tokens and defines a new 'purpose' token to		use of existing tokens and defines a new 'purpose' token to
	correspond to the RCD framework.		correspond to the RCD framework.
	There are a number of RCD information types that can be transmitted		There are a number of RCD information types that can be transmitted
	in the Call-Info header field of a SIP request. The STIR RCD		in the Call-Info header field of a SIP request. The STIR RCD
	specification [RFC9795] defines calling name, a logo or icon		specification [RFC9795] defines the following primary RCD elements: a
	associated with the caller, and a call reason string. It also		calling name, a logo or icon associated with the caller, and a call
	discusses an extensible way to carry caller information using jCard		reason string. It also discusses an extensible way to carry caller
	[RFC7095].		information using jCard [RFC7095].
	The RCD framework defined both in this document as well as in		The RCD framework defined both in this document as well as in
	[RFC9795] carries call-specific information. The insertion of RCD is		[RFC9795] carries call-specific information. The insertion of RCD is
	intended to be singular in that the receiving party should not be		intended to be singular in that the receiving party should not be
	required to make any call-specific decisions based on redundant,		required to make any call-specific decisions based on redundant,
	duplicate, or conflicting RCD. The RCD information is either		duplicate, or conflicting RCD. The RCD information is either
	intended to be added by a party that is authoritative over that		intended to be added by a party that is authoritative over that
	information or to have been translated from a verified STIR RCD		information or to have been translated from a verified STIR RCD
	PASSporT and unmodified once in a trusted domain. Any additional		PASSporT and unmodified once in a trusted domain. Any additional
	parties involved in the call path MUST NOT modify the Call-Info		parties involved in the call path MUST NOT modify the Call-Info
	skipping to change at line 278 ¶		skipping to change at line 278 ¶
	Asserted-ID header field [RFC3325]. While this is out of scope for		Asserted-ID header field [RFC3325]. While this is out of scope for
	the Call-Info header field in terms of the representation of the		the Call-Info header field in terms of the representation of the
	display-name value, this document does discuss the representation of		display-name value, this document does discuss the representation of
	the verification of this value using the 'verified' parameter.		the verification of this value using the 'verified' parameter.
	For logos or icons that can represent the calling party, the		For logos or icons that can represent the calling party, the
	'purpose' token "icon" [RFC3261] is used to indicate a URI for an		'purpose' token "icon" [RFC3261] is used to indicate a URI for an
	image resource that can be displayed to the user receiving the SIP		image resource that can be displayed to the user receiving the SIP
	request. For the purpose of this document and the transmission of		request. For the purpose of this document and the transmission of
	RCD, the "icon" 'purpose' token should be used as defined.		RCD, the "icon" 'purpose' token should be used as defined.
	Section 8.2 provides high-level guidance on image formatting and		Section 8.2 of [RFC9795] provides high-level guidance on image
	related information.		formatting and related information.
	This document defines 'call-reason' as a new parameter for the Call-		This document defines 'call-reason' as a new parameter for the Call-
	Info header field. This parameter carries a string indicating the		Info header field. This parameter carries a string indicating the
	reason for the call.		reason for the call.
	jCard is a comprehensive and extensible mechanism utilized as part of		jCard is a comprehensive and extensible mechanism utilized as part of
	the STIR RCD framework. While [RFC3261] specifies a "card" 'purpose'		the STIR RCD framework. While [RFC3261] specifies a "card" 'purpose'
	token, the intent of defining a new "jcard" 'purpose' token is to use		token, the intent of defining a new "jcard" 'purpose' token is to use
	the JSON jCard format [RFC7095] and to provide guidance for the use		the JSON jCard format [RFC7095] and to provide guidance for the use
	and non-use of jCard attributes to describe the calling party in a		and non-use of jCard attributes to describe the calling party in a
	skipping to change at line 316 ¶		skipping to change at line 316 ¶
	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 Call-		field via the "cid" URI scheme [RFC2392]. Alternatively, the Call-
	Info header field URI MUST use a transport that can validate the		Info header field URI MUST use a transport that can validate the
	integrity of the source of the resource (e.g., HTTPS tied to a		integrity of the source of the resource (e.g., HTTPS tied to a
	specific validated domain). If, in the specific deployment		specific validated domain). If, in the specific deployment
	environment of SIP, the source or integrity of the RCD information		environment of SIP, the source or integrity of the RCD information
	cannot be trusted, then the use of the STIR RCD framework defined in		cannot be trusted, then the use of the STIR RCD framework defined in
	[RFC9795] should be considered.		[RFC9795] should be considered.
	Because the use and purpose of this specification is to provide a		Because the use and purpose of this specification is to provide a
	single presentation of rich call data information, a call and its		single presentation of RCD information, a call and its corresponding
	corresponding single RCD-related Call-Info header field MUST only		single RCD-related Call-Info header field MUST only contain a single
	contain a single jCard object represented by an array with two		jCard object represented by an array with two elements. The array
	elements. The array MUST only include a single first element with		MUST only include a single first element with the string "vcard", and
	the string "vcard", and the second element is an array of jCard		the second element is an array of jCard properties corresponding to
	properties corresponding to the single entity jCard object.		the single entity jCard object.
	The fields like "fn", "photo", or "logo" if used with the use of		jCard has multiple fields that may convey similar information, for
	"icon" or calling name in From or P-Asserted-ID header field or		example, "fn", “n”, or “nickname” are strings that represent names in
	purpose token, as described in the previous section, MUST match if		different ways, or "photo" or "logo" represent a picture. Users of
	present to allow the called party to clearly determine the intended		this specification should make sure there is consistency for the
	calling name or icon.		calling name string corresponding to the single name in the SIP From
			or P-Asserted-ID header field or a “logo” or “photo” corresponds to
			the RCD “icon” as described in the previous section. As described in
			[RFC8224] and [RFC9795] verification procedures, the values
			represented in the RCD MUST match the corresponding information in
			the SIP message to enable proper verification of calling name or icon
			consistently.
	An example of a Call-Info header field is:		An example of a Call-Info header field is:
	Call-Info: <https://example.com/qbranch.json>;purpose=jcard		Call-Info: <https://example.com/qbranch.json>;purpose=jcard
	An example of the contents of a URL-linked jCard JSON file is shown		An example of the contents of a URL-linked jCard JSON file is shown
	as follows:		as follows:
	["vcard",		["vcard",
	[		[
	skipping to change at line 446 ¶		skipping to change at line 452 ¶
	SIP implementations and its specification describes its potential use		SIP implementations and its specification describes its potential use
	in filtering, it seemed prudent to define a new means of carrying a		in filtering, it seemed prudent to define a new means of carrying a
	call-reason indication.		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>;purpose=jcard;		Call-Info: <https://example.com/jbond.json>;purpose=jcard;
	call-reason="For your ears only"		call-reason="For your ears only"
	In the case that there is only a 'call-reason' or 'verified'		For ‘call-reason’ or ‘verified’ parameters defined in this document
	parameter or any future parameters that may be defined and no need		that do not require an associated URI, or for future parameters do
	for a purpose parameter with no associated URI the null data URI,		not require an associated URI, the Call-Info header field URI should
	"data:" is used as the URI. The purpose parameter "jcard", defined		be set to the null data URI, “data:”. The purpose parameter "jcard",
	in this document, is used to avoid any conflicts or confusion with		defined in this document, is used to avoid any conflicts or confusion
	existing implementations and previously defined purpose parameters.		with existing implementations and previously defined purpose
	As an example:		parameters. As an example:
	Call-Info: <data:>;purpose=jcard;		Call-Info: <data:>;purpose=jcard;
	call-reason="For your ears only"		call-reason="For your ears only"
	7. 'verified' Call-Info Parameter		7. 'verified' Call-Info Parameter
	The 'verified' parameter extends and complements the content conveyed		The 'verified' parameter extends and complements the content conveyed
	by the RCD-related Call-Info header field. This parameter indicates		by the RCD-related Call-Info header field. This parameter indicates
	to the recipient that the information contained in the Call-Info		to the recipient that the information contained in the Call-Info
	header field has been verified by verification procedures for claims		header field has been verified by verification procedures for claims
	skipping to change at line 478 ¶		skipping to change at line 484 ¶
	recipient should assume that information was not received and		recipient should assume that information was not received and
	verified corresponding to the verification procedures defined in		verified corresponding to the verification procedures defined in
	Section 8 of [RFC9795].		Section 8 of [RFC9795].
	There is a single valid value associated with the 'verified'		There is a single valid value associated with the 'verified'
	parameter of 'true'. The value 'true' indicates to the recipient		parameter of 'true'. The value 'true' indicates to the recipient
	that the party that included the Call-Info header field performed a		that the party that included the Call-Info header field performed a
	successful verification of the information represented. As a general		successful verification of the information represented. As a general
	principle of Call-Info header field information, the recipients'		principle of Call-Info header field information, the recipients'
	ability to trust the 'verified' parameter is based on the trusted		ability to trust the 'verified' parameter is based on the trusted
	relationship of whom they are receiving the SIP request.		relationship with the party from whom they are receiving the SIP
			request.
	The following is an example where the parameter verified="true" is		The following is an example where the parameter verified="true" is
	used to represent that a verification procedure has been performed		used to represent that a verification procedure has been performed
	within a trusted domain to indicate the 'icon' URL has been		within a trusted domain to indicate the "icon" URL has been
	successfully verified:		successfully verified:
	Call-Info: <https://example.com/jbond.png>;purpose=icon;		Call-Info: <https://example.com/jbond.png>;purpose=icon;
	verified="true"		verified="true"
	In addition to the use of the indication of successful verification		In addition to the use of the indication of successful verification
	of RCD information, an important usage of the 'verified' parameter is		of RCD information, an important usage of the 'verified' parameter is
	to indicate verification of display-name information, sometimes		to indicate verification of display-name information, sometimes
	referred to as calling name or CNAM.		referred to as calling name or CNAM.
	skipping to change at line 519 ¶		skipping to change at line 526 ¶
	}		}
	The terminating provider receives a SIP INVITE with an identity		The terminating provider receives a SIP INVITE with an identity
	header containing the STIR RCD PASSporT that is verified through a		header containing the STIR RCD PASSporT that is verified through a
	verification service. The provider then wants to deliver the call to		verification service. The provider then wants to deliver the call to
	an end device in the trusted and authenticated UNI network. The		an end device in the trusted and authenticated UNI network. The
	provider uses local policies to determine the information to present		provider uses local policies to determine the information to present
	to the end device. The following example SIP INVITE could be used to		to the end device. The following example SIP INVITE could be used to
	represent the RCD information using two Call-Info header fields.		represent the RCD information using two Call-Info header fields.
	Because both the icon and calling name have passed verification, a		Because both the icon and calling name have passed verification, a
	Call-Info header for the 'icon' is added with a verified="true"		Call-Info header for the "icon" is added with a verified="true"
	parameter, and the use of Call-Info with a null data URI is used, as		parameter, and the use of Call-Info with a null data URI is used, as
	discussed in the "call-reason" section above. This document defines		discussed in the "call-reason" section above. This document defines
	the convention that when a Call-Info header field with a null data		that the display-name information in either the From and/or P-
	URI, "data:", a default purpose of "jcard" and adding a		Asserted-ID header field has been verified via RCD PASSporT
	verified="true" indicates that the display-name information in either		verification procedures when the following is present: a ‘purpose’
	the From and/or P-Asserted-ID header field has been verified via RCD		parameter tokens of “jcard”, a Call-Info header field with a null
	verification procedures.		data URI “data:”, and a verified parameter equal to “true”.
	Example SIP INVITE described above:		Example SIP INVITE described above:
	INVITE sip:qbranch@example.com SIP/2.0		INVITE sip:qbranch@example.com SIP/2.0
	Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8		Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
	To: "QBranch" <sip:qbranch@example.com>		To: "QBranch" <sip:qbranch@example.com>
	From: "James Bond" <sip:12155551000@example.com;user=phone>;		From: "James Bond" <sip:12155551000@example.com;user=phone>;
	tag=1928>		tag=1928>
	Call-ID: a84b4c76e66710		Call-ID: a84b4c76e66710
	Call-Info: <https://example.com/jbond.png>;purpose=icon;		Call-Info: <https://example.com/jbond.png>;purpose=icon;
	skipping to change at line 571 ¶		skipping to change at line 578 ¶
	describes the procedures for the creation of the digest value		describes the procedures for the creation of the digest value
	including the hash algorithm indicator a '-' separator and the hash		including the hash algorithm indicator a '-' separator and the hash
	value as a string. The JSON pointer object container described as		value as a string. The JSON pointer object container described as
	the container of the 'rcdi' hashes is not necessary because each hash		the container of the 'rcdi' hashes is not necessary because each hash
	value should only correspond to a single URI. Corresponding to		value should only correspond to a single URI. Corresponding to
	guidance defined in Section 6 of [RFC9795], implementations of this		guidance defined in Section 6 of [RFC9795], implementations of this
	specification MUST support the hash algorithms SHA-256, SHA-384, and		specification MUST support the hash algorithms SHA-256, SHA-384, and
	SHA-512. These hash algorithms are identified by "sha256", "sha384",		SHA-512. These hash algorithms are identified by "sha256", "sha384",
	and "sha512", respectively.		and "sha512", respectively.
	Typically, this hash value, assuming the URI and the resource pointed		Assuming the URI and the resource pointing to the URI don't change
	to the URI don't change between the STIR RCD PASSporT and the Call-		between the STIR RCD PASSporT and the Call- Info URI value, the
	Info URI value, the integrity value can be directly used as the same		integrity value can typically be used as the same corresponding
	corresponding string in both the "rcdi" claim and the 'integrity'		string in both the "rcdi" claim and the 'integrity' parameter.
	parameter string value.
	Note: The inclusion of both the 'verified' and 'integrity' when an		| Note: When the ‘rcdi’ claim is part of the successfully
	"rcdi" claim is included and the identity header field and included		| verified RCD PASSporT, the Call-Info Header Field should
	PASSporT is verified successfully is the suggested outcome. Creation		| include both the ‘verified’ and ‘integrity’ parameters.
	of a Call-Info header field based on an identity header field that		| Creation of a Call-Info header field based on an identity
	carries Rich Call Data claims that does not pass verification		| header field that carries RCD claims that does not pass
	procedures is not suggested (i.e., the inclusion of an 'integrity'		| verification procedures is not suggested (i.e., the inclusion
	parameter without a properly included 'verified' parameter)		| of an 'integrity' parameter without a properly included
			| 'verified' parameter).
	Example STIR RCD PASSporT:		Example STIR RCD PASSporT:
	Protected Header		Protected Header
	{		{
	"alg":"ES256",		"alg":"ES256",
	"typ":"passport",		"typ":"passport",
	"ppt":"rcd",		"ppt":"rcd",
	"x5u":"https://cert.example.org/passport.pem"		"x5u":"https://cert.example.org/passport.pem"
	}		}
	skipping to change at line 642 ¶		skipping to change at line 649 ¶
	s=Session SDP		s=Session SDP
	c=IN IP4 pc33.atlanta.example.com		c=IN IP4 pc33.atlanta.example.com
	t=0 0		t=0 0
	m=audio 49172 RTP/AVP 0		m=audio 49172 RTP/AVP 0
	a=rtpmap:0 PCMU/8000		a=rtpmap:0 PCMU/8000
	9. Usage and an Example of Call-Info for RCD		9. Usage and an Example of Call-Info for RCD
	The procedures for the usage of URIs and 'purpose' parameter tokens		The procedures for the usage of URIs and 'purpose' parameter tokens
	should follow the procedures defined in [RFC3261]. The general		should follow the procedures defined in [RFC3261]. The general
	management and provisioning of Rich Call Data for an initiating party		management and provisioning of RCD for an initiating party requires a
	requires a lot of validation of information regarding that specific		lot of validation of information regarding that specific initiating
	initiating party, which is out of scope of this document. Because		party, which is out of scope of this document. Since the ‘rcd’ Call-
	the 'rcd' Call-Info header field is inserted as part of the receiving		Info header field is verified during the transition from the Network-
	part of the transition from NNI to UNI, the information populated in		to-Network Interface (NNI) to the User-to-Network Interface (UNI), a
	a received STIR 'rcd' PASSporT that is verified is a general		common approach is to extract and translate the verified information
	anticipated process for translating information into the 'rcd' Call-		from a received STIR ‘rcd’ PASSporT into this header field. This
	Info header field to transport the rich call data into the UNI toward		allows the RCD to be delivered to the end user device through the
	the end-user device.		UNI.
	The following example provides both the STIR RCD PASSporT and the		The following example provides both the STIR RCD PASSporT and the
	corresponding set of Call-Info header fields showing the use of		corresponding set of Call-Info header fields showing the use of
	multiple 'purpose' parameters to indicate a jCard and an icon and		multiple Call-Info 'purpose' tokens to indicate "jCard" and "icon"
	also a 'call-reason' parameter:		and also a 'call-reason' Call-Info parameter:
	Example STIR RCD PASSporT:		Example STIR RCD PASSporT:
	Protected Header		Protected Header
	{		{
	"alg":"ES256",		"alg":"ES256",
	"typ":"passport",		"typ":"passport",
	"ppt":"rcd",		"ppt":"rcd",
	"x5u":"https://cert.example.org/passport.pem"		"x5u":"https://cert.example.org/passport.pem"
	}		}
	skipping to change at line 712 ¶		skipping to change at line 719 ¶
	as well as applications, and also includes requirements specific to		as well as applications, and also includes requirements specific to
	textual and graphics-capable displays.		textual and graphics-capable displays.
	10.1. Usage of URIs in jCard		10.1. Usage of URIs in jCard
	When one or more URIs are used in a jCard, it is important to note		When one or more URIs are used in a jCard, it is important to note
	that any URI-referenced data, with the exception of the top-level		that any URI-referenced data, with the exception of the top-level
	usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI		usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI
	references. In other words, the jCard can have URI references as		references. In other words, the jCard can have URI references as
	defined in the jCard specification and this document, but the content		defined in the jCard specification and this document, but the content
	referenced by those URIs MUST NOT have any URIs, and therefore MUST		referenced by those URIs MUST NOT have any URIs; therefore, the
	be enforced by the client to not follow those URI references or not		client MUST ensure that those URI references are not followed, and
	render that content to the user if any URI are present in that		any URIs that are present in that specific URI-linked content are not
	specific URI linked content. The purpose of this is to control the		rendered. The purpose of this is to control the security and more
	security and more specifically to align with the content-integrity		specifically to align with the content-integrity mechanism defined in
	mechanism defined in [RFC9795]. There is not anticipated to be need		[RFC9795]. There is not anticipated to be need for which deeper URI
	for which deeper URI references would be required or even supported		references would be required or even supported by the typical use of
	by the typical use of current jCard properties. However, because		current jCard properties. However, because jCard is extensible, this
	jCard is extensible, this rule is set to restrict further extension		rule is set to restrict further extension without the proper
	without the proper consideration of security and integrity properties		consideration of security and integrity properties of both Call-Info
	of both Call-Info usage as well as the RCD and STIR signing of the		usage as well as the RCD and STIR signing of the data [RFC9795]
	data [RFC9795] [RFC8224].		[RFC8224].
	10.2. Usage of Multimedia Data in jCard or with Icon		10.2. Usage of Multimedia Data in jCard or with the “icon” Call-Info
			‘purpose’ Token
	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 (Section 4 of [RFC4648]), this document		directly via Base64 encoding (Section 4 of [RFC4648]), this document
	provides guidance at the time of writing that can be adopted to		provides guidance at the time of writing that can be adopted to
	facilitate the successful decoding and rendering of these images and		facilitate the successful decoding and rendering of these images and
	media formats. Note that media formats are likely something		media formats. Note that media formats are likely something
	implementers need to consider for their specific application.		implementers need to consider for their specific application.
	For images, such as for the "photo" and "logo" properties, the		For images, such as for the "photo" and "logo" properties, the
	skipping to change at line 924 ¶		skipping to change at line 932 ¶
	10.6.1. "tel" Property		10.6.1. "tel" Property
	The "tel" property provides the telephone number for the object the		The "tel" property provides the telephone number for the object the
	jCard represents. Reference: [RFC6350], Section 6.4.1.		jCard represents. Reference: [RFC6350], Section 6.4.1.
	Relative to the SIP From header field value, this information may		Relative to the SIP From header field value, this information may
	provide an alternate telephone number or other related telephone		provide an alternate telephone number or other related telephone
	numbers for other uses.		numbers for other uses.
	It is important to note that any of the potential instances of the		It is important to note that any of the instances of the "tel"
	"tel" property should not be considered part of the authentication or		property should not be considered part of the authentication or
	verification part of STIR [RFC8224] or required to match the "orig"		verification part of STIR [RFC8224] or required to match the "orig"
	claim in the PASSporT [RFC8225]. These telephone numbers can be for		claim in the PASSporT [RFC8225]. These telephone numbers can be for
	contact, fax, or other purposes aligned with the general usage of		contact, fax, or other purposes aligned with the general usage of
	jCard and vCard, but the potential confusion of the callee when		jCard and vCard, but the potential confusion of the callee when
	provided with multiple telephone numbers instead of the actual,		provided with multiple telephone numbers instead of the actual,
	verified telephone number should be considered from a general policy		verified telephone number should be considered from a general policy
	point of view.		point of view.
	Value type: By default, it is a single free-form text value (for		Value type: By default, it is a single free-form text value (for
	backward compatibility with vCard 3), but it SHOULD be reset to a		backward compatibility with vCard 3), but it SHOULD be reset to a
	skipping to change at line 981 ¶		skipping to change at line 989 ¶
	10.7. Geographical Properties		10.7. Geographical Properties
	These properties provide geographical information associated with the		These properties provide geographical information associated with the
	object the jCard represents.		object the jCard represents.
	10.7.1. "tz" Property		10.7.1. "tz" Property
	The "tz" property provides the time zone of the object the jCard		The "tz" property provides the time zone of the object the jCard
	represents. Reference: [RFC6350], Section 6.5.1.		represents. Reference: [RFC6350], Section 6.5.1.
	Note: The reference for time-zone names is <https://www.iana.org/		| Note: The reference for time-zone names is
	time-zones>.		| <https://www.iana.org/time-zones>.
	Value type: The default is a single text value. It can also be		Value type: The default is a single text value. It can also be
	reset to a single URI or a UTC-offset value.		reset to a single URI or a UTC-offset value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["tz", {}, "text", "America/New_York"]		["tz", {}, "text", "America/New_York"]
	10.7.2. "geo" Property		10.7.2. "geo" Property
	skipping to change at line 1010 ¶		skipping to change at line 1018 ¶
	["geo", {}, "uri", "geo:37.386013,-122.082932"]		["geo", {}, "uri", "geo:37.386013,-122.082932"]
	10.8. Organizational Properties		10.8. Organizational Properties
	These properties are concerned with information associated with		These properties are concerned with information associated with
	characteristics of the organization or organizational units of the		characteristics of the organization or organizational units of the
	object that the jCard represents.		object that the jCard represents.
	10.8.1. "title" Property		10.8.1. "title" Property
	The "title" property has the intent of providing the position or job		The "title" property provides the position or job of the object the
	of the object the jCard represents. Reference [RFC6350],		jCard represents. Reference [RFC6350], Section 6.6.1.
	Section 6.6.1.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["title", {}, "text", "Research Scientist"]		["title", {}, "text", "Research Scientist"]
	10.8.2. "role" Property		10.8.2. "role" Property
	The "role" property has the intent of providing the position or job		The "role" property provides the position or job of the object the
	of the object the jCard represents. Reference [RFC6350],		jCard represents. Reference [RFC6350], Section 6.6.2.
	Section 6.6.2.
	Value type: A single text value.		Value type: A single text value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["role", {}, "text", "Project Leader"]		["role", {}, "text", "Project Leader"]
	10.8.3. "logo" Property		10.8.3. "logo" Property
	The "logo" property has the intent of specifying a graphic image of a		The "logo" property specifies a graphic image of a logo associated
	logo associated with the object the jCard represents. Reference		with the object the jCard represents. Reference [RFC6350],
	[RFC6350], Section 6.6.3.		Section 6.6.3.
	Value type: A single URI.		Value type: A single URI.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]		["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]
	["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC		["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
	AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm		AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
	ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0		ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
	<...the remainder of base64-encoded data...>"]		<...the remainder of base64-encoded data...>"]
	10.8.4. "org" Property		10.8.4. "org" Property
	The "org" property has the intent of specifying the organizational		The "org" property specifies the organizational name and units of the
	name and units of the object the jCard represents. Reference		object the jCard represents. Reference [RFC6350], Section 6.6.4.
	[RFC6350], Section 6.6.4.
	Value type: A single structured text value consisting of components		Value type: A single structured text value consisting of components
	separated by the SEMICOLON character (U+003B).		separated by the SEMICOLON character (U+003B).
	Cardinality: *		Cardinality: *
	Example:		Example:
	["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]		["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]
	10.9. Explanatory Properties		10.9. Explanatory Properties
	skipping to change at line 1135 ¶		skipping to change at line 1140 ¶
	Example:		Example:
	["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]		["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]
	10.9.5. "url" Property		10.9.5. "url" Property
	The "url" property specifies a uniform resource locator associated		The "url" property specifies a uniform resource locator associated
	with the object the jCard represents. Reference: [RFC6350],		with the object the jCard represents. Reference: [RFC6350],
	Section 6.7.8.		Section 6.7.8.
	There are potential security and privacy implications of providing		There are potential security and privacy implications of providing
	URLs with telephone calls. The end client receiving a jCard with a		URLs with telephone calls.
	"url" property MUST only display the URL and not automatically follow
	the URL or provide an automatic preview of the URL, and generally		The end client receiving a jCard with a "url" property MUST only
	provide good practices in making it clear to the user it is their		display the URL and not automatically follow the URL or provide an
	choice to follow the URL in a browser context consistent with all of		automatic preview of the URL. In addition, it MUST generally adhere
			to good practice to make it clear to the user that it is their choice
			whether to follow the URL in a browser context consistent with all of
	the common browser security and privacy practices available on most		the common browser security and privacy practices available on most
	consumer OS environments.		consumer OS environments.
	Value type: A single uri value.		Value type: A single uri value.
	Cardinality: *		Cardinality: *
	Example:		Example:
	["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]		["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]
	10.9.6. "version" Property		10.9.6. "version" Property
	skipping to change at line 1172 ¶		skipping to change at line 1179 ¶
	Part of the intent of using jCard is to leverage its extensibility to		Part of the intent of using jCard is to leverage its extensibility to
	define new properties to relay new information related to a caller.		define new properties to relay new information related to a caller.
	This capability is inherently supported as part of standard		This capability is inherently supported as part of standard
	extensibility. However, usage of those new properties should be		extensibility. However, usage of those new properties should be
	published and registered following [RFC7095], Section 3.6 or as		published and registered following [RFC7095], Section 3.6 or as
	defined in future specifications.		defined in future specifications.
	12. IANA Considerations		12. IANA Considerations
	12.1. 'jcard' Purpose Parameter Value		12.1. "jcard" Purpose Parameter Value
	This document defines the 'jcard' value for the 'purpose' parameter		This document defines the "jcard" value for the 'purpose' parameter
	of the Call-Info header field [RFC3261]. IANA has added this		of the Call-Info header field [RFC3261]. IANA has added this
	document to the list of references for the 'purpose' value of Call-		document to the list of references for the 'purpose' value of Call-
	Info in the "Header Field Parameters and Parameter Values" registry		Info in the "Header Field Parameters and Parameter Values" registry
	within the "Session Initiation Protocol (SIP) Parameters" registry		within the "Session Initiation Protocol (SIP) Parameters" registry
	group.		group.
	12.2. SIP Call-Info Header Field 'call-reason' Parameter		12.2. SIP Call-Info Header Field 'call-reason' Parameter
	This document defines the 'call-reason' generic parameter for use in		This document defines the 'call-reason' generic parameter for use in
	the Call-Info header field in the "Header Field Parameters and		the Call-Info header field in the "Header Field Parameters and
	skipping to change at line 1238 ¶		skipping to change at line 1245 ¶
	13. Security Considerations		13. Security Considerations
	Revealing information such as the name, location, and affiliation of		Revealing information such as the name, location, and affiliation of
	a person necessarily entails certain privacy risks. The SIP Call-		a person necessarily entails certain privacy risks. The SIP Call-
	Info header field has no particular confidentiality requirement, as		Info header field has no particular confidentiality requirement, as
	the information sent in SIP is in the clear anyway. Transport-level		the information sent in SIP is in the clear anyway. Transport-level
	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.
	The use of the Call-Info header for transporting Rich Call Data		The use of the Call-Info header for transporting RCD ('rcd') is
	('rcd') is intended primarily for providing verified information at		intended primarily for providing verified information at the
	the termination of a call, where a verification service has a trusted		termination of a call, where a verification service has a trusted UNI
	UNI relationship with the user agent. To ensure the integrity and		relationship with the user agent. To ensure the integrity and
	authenticity of this data, the security framework established by		authenticity of this data, the security framework established by
	STIR, including the use of the 'rcd'PASSporT as defined in [RFC9795],		STIR, including the use of the 'rcd'PASSporT as defined in [RFC9795],
	should be followed. This framework enables digital signatures to		should be followed. This framework enables digital signatures to
	verify the issuer of assertions related to the calling party's		verify the issuer of assertions related to the calling party's
	identity, distinguishing persistent identity attributes from		identity, distinguishing persistent identity attributes from
	transient, per-call details. Implementers should also consider		transient, per-call details. Implementers should also consider
	certificate-based constraints to ensure proper binding between caller		certificate-based constraints to ensure proper binding between caller
	identity assertions and call-specific metadata while maintaining the		identity assertions and call-specific metadata while maintaining the
	integrity of the information throughout transmission. Since Call-		integrity of the information throughout transmission. Since Call-
	Info serves as a means to convey verified caller information to the		Info serves as a means to convey verified caller information to the
	end user, mechanisms should be in place to validate the authenticity		end user, mechanisms should be in place to validate the authenticity
	of the assertion, enforce appropriate certificate associations, and		of the assertion, enforce appropriate certificate associations, and
	preserve the trustworthiness of Rich Call Data from origination to		preserve the trustworthiness of RCD from origination to termination.
	termination.
	The SIP framework, defined in [RFC3261] and the various extensions to		The SIP framework, defined in [RFC3261] and the various extensions to
	SIP which includes STIR [RFC8224] and rich call data [RFC9795], since		SIP which includes STIR [RFC8224] and RCD [RFC9795], has always
	its existence has provided mechanisms to assert information about the		provided mechanisms to assert information about the person or entity
	person or entity behind the call. This feature that can be a benefit		behind the call. This feature that can be a benefit to the SIP
	to the SIP network that allows users to help identify the calling		network that allows users to help identify the calling party behind
	party behind an abstract telephone number. It can also enable the		an abstract telephone number. It can also enable the ability for
	ability for actors to impersonate a calling party they are not		actors to impersonate a calling party they are not authorized to
	authorized to represent. The core security consideration that has		represent. The core security consideration that has either
	either explicitly or implicitly been acknowledged with any of the SIP		explicitly or implicitly been acknowledged with any of the SIP and
	and STIR specifications is that there be a management and policy		STIR specifications is that there be a management and policy layer
	layer that validates the participants in the ecosystem and their use		that validates the participants in the ecosystem and their use of a
	of a SIP network with telephone number identifiers and identity-		SIP network with telephone number identifiers and identity-related
	related information. The use of this specification should weigh this		information. Users should assess this risk and make the appropriate
	responsibility and make the appropriate considerations to validate		adjustments to validate proper participation while following these
	the proper participation and use of these tools following these		tools following these larger security, impersonation prevention, and
	larger security, impersonation prevention, and privacy		privacy considerations.
	considerations.
	The use of this specification with the insertion of metadata related		The use of this specification with the insertion of metadata related
	to a caller or the purpose of the call should recognize the risk that		to a caller or the purpose of the call should recognize the risk that
	this information can be viewed by those network elements and		this information can be viewed by those network elements and
	participants in the delivery of the SIP call. The insertion of media		participants in the delivery of the SIP call. The insertion of media
	directly or via Base64 encoding or using a remote URI that query		directly or via Base64 encoding or using a remote URI that query
	network resources should be considered as a potential threat vector		network resources should be considered as a potential threat vector
	to the user or user agent that could potentially allow the parsing of		to the user or user agent that could potentially allow the parsing of
	documents crafted to trigger a bug or install a virus. Remote access		documents crafted to trigger a bug or install a virus. Remote access
	to URI content should additionally be considered as potentially		to URI content should additionally be considered as potentially
	exposing information about that user or user agent. Some sensitive		exposing information about that user or user agent. Some sensitive
	users may desire the ability to control or disable these mechanisms		users may desire the ability to control or disable these mechanisms
	entirely, and methods to restrict or disable the potential exposure		entirely, and methods to restrict or disable the potential exposure
	should be considered to mitigate these concerns. Largely, any		should be considered to mitigate these concerns. Largely, any
	information that is included in rich call data should be considered		information that is included in RCD should be considered public, and
	public, and this specification does not define any mechanism to		this specification does not define any mechanism to protect this
	protect this information beyond the security and privacy associated		information beyond the security and privacy associated with the SIP
	with the SIP signalling itself. This is a property that is		signalling itself. This is a property that is consistent with SIP
	consistent with SIP more generally, and this specification follows a		more generally, and this specification follows a similar pattern for
	similar pattern for its use.		its use.
	This specification contains the ability to include media resources		This specification contains the ability to include media resources
	and URI and URL resource references to media resources that could		and URI and URL resource references to media resources that could
	pose a threat when referencing or decoding the content of these media		pose a threat when referencing or decoding the content of these media
	resources, which is similar to threats that web browsers and other		resources, which is similar to threats that web browsers and other
	media decoding applications must be concerned about. A network-		media decoding applications must be concerned about. Network
	specific set of policies or best practices for the use and hosting of		administrators should consider a network-specific set of policies or
	media content that is agreed to contain validated media resources		best practices for the use and hosting of media content that is
	that have been evaluated to not pose a security threat to the		agreed to contain validated media resources that have been evaluated
	participants or the devices supported in the ecosystem should be		to not pose a security threat to the participants or the devices
	considered.		supported in the ecosystem.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[ISOPNG] ISO/IEC, "Information technology -- Computer graphics and		[ISOPNG] ISO/IEC, "Information technology -- Computer graphics and
	image processing -- Portable Network Graphics (PNG),		image processing -- Portable Network Graphics (PNG),
	Functional specification", ISO/IEC 15948:2004, March 2004,		Functional specification", ISO/IEC 15948:2004, March 2004,
	<https://www.iso.org/standard/29581.html>.		<https://www.iso.org/standard/29581.html>.
	skipping to change at line 1397 ¶		skipping to change at line 1402 ¶
	Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,		Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
	<https://www.rfc-editor.org/info/rfc8225>.		<https://www.rfc-editor.org/info/rfc8225>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token		[RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT) Extension for Rich Call Data", RFC 9795,		(PASSporT) Extension for Rich Call Data", RFC 9795,
	DOI 10.17487/RFC9795, May 2025,		DOI 10.17487/RFC9795, June 2025,
	<https://www.rfc-editor.org/info/rfc9795>.		<https://www.rfc-editor.org/info/rfc9795>.
	[W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.		[W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.
	Weinberger, Ed., "Subresource Integrity", W3C		Weinberger, Ed., "Subresource Integrity", W3C
	Recommendation, 23 June 2016,		Recommendation, 23 June 2016,
	<https://www.w3.org/TR/2016/REC-SRI-20160623/>.		<https://www.w3.org/TR/2016/REC-SRI-20160623/>.
	[W3C-SVGTiny1.2]		[W3C-SVGTiny1.2]
	Anderssone, O., Ed., Berjon, R., Ed., Dahlström, E., Ed.,		Anderssone, O., Ed., Berjon, R., Ed., Dahlström, E., Ed.,
	Emmons, A., Ed., Ferraiolo, J., Ed., Grasso, A., Ed.,		Emmons, A., Ed., Ferraiolo, J., Ed., Grasso, A., Ed.,
End of changes. 34 change blocks.
	136 lines changed or deleted		141 lines changed or added
This html diff was produced by rfcdiff 1.48.