rfc9796v2.txt		rfc9796.txt
	skipping to change at line 256 ¶		skipping to change at line 256 ¶
	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
	header field or add additional Call-Info header fields related to		header field or add additional Call-Info header fields related to
	RCD. The insertion of the RCD Call-Info header field should be		RCD. The trusted and verified caller RCD information inserted in the
	considered a trusted action based on trusted information, and the		RCD Call-Info header field MUST NOT be modified or altered. The user
	information MUST NOT be considered modifiable representing the best		should be able to trust that the RCD information accurately
	practice of determining the final representation of the caller RCD to		represents the verified information. This specification acknowledges
	the user. This specification acknowledges that without the use of		that without the use of STIR or other mechanisms, detection of any
	STIR or other mechanisms, detection of any modifications is not		modifications is not possible, so guidance for the use of this
	possible, so guidance for the use of this specification in a trusted		specification in a trusted UNI part of the network is important.
	UNI part of the network is important.
	As discussed in [RFC9795], the calling name uses the display-name		As discussed in [RFC9795], the calling name uses the display-name
	value of the From header field [RFC3261] of the request.		value of the From header field [RFC3261] of the request.
	Alternatively, for some calls, the calling name may come from the P-		Alternatively, for some calls, the calling name may come from the P-
	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
End of changes. 1 change blocks.
	8 lines changed or deleted		7 lines changed or added
This html diff was produced by rfcdiff 1.48.